Percona Server for MySQL 9.7.1-1でOpenTelemetryを検証 ― PMMがあるのに使う意味は？

2026年9月16日

はじめに

MySQL 9.7.0 でTelemetry機能がCommunity Editionでも利用可能になりました。
MySQL 9.7.0 リリースノート

Telemetry機能とは、OpenTelemetryを利用してDBの状態や処理状況を情報収集し、外部のObservability基盤へ連携する仕組みです。
2026年8月5日にリリースされた Percona Server 9.7.1-1 でも、この機能が利用できます。
Percona Server 9.7.1-1 リリースノート

ただし、監視製品としてPMM（Percona Monitoring and Management）があるため、単純にMetricが取れるだけでは「OpenTelemetryを追加する意味はあるのだろうか？」と疑問が出てきます。
本稿では、次の観点でTelemetry機能を使ったOpenTelemetryとPMMを比較しました。

DB処理が遅いとき、どちらで何が分かるか
アプリケーション処理が遅く、DBが正常なとき、どちらで何が分かるか

先に結論を述べると、OpenTelemetryはPMMの代替ではなく、アプリケーションからDBまでの横断的な切り分けを補う仕組みとして価値があります。

名前が似ている3つの監視機能を整理する

まず、Percona Server 周辺には、Telemetryという名称を含む仕組みが複数あります。目的が異なるため、先に区別しておきます。

Percona Telemetry

匿名化されたデプロイメントや使用状況のメトリクスをPerconaに報告することで、Perconaが修正や機能開発の優先順位を決定するための仕組みです。
したがって、「自分たちのシステムを観測するためのOpenTelemetry」ではありません。
Percona Server: Telemetry and data collection

MySQL Telemetry

OpenTelemetryの形式でTrace、Metric、Logを外部のObservability基盤へ連携するための機能です。
つまり、「自分たちのシステムを観測するためのOpenTelemetry」であり、今回検証する機能です。
MySQL 9.7 Telemetry

送信される情報は以下の通りです。

情報	主な内容	主な用途
Trace	HTTPリクエストからMySQL statementまでの処理経路、各spanの実行時間、エラー情報など	個別リクエストについて、遅延・エラーがどこで発生したかを切り分ける
Log	エラーログ、スロークエリログ、一般ログのログイベント	エラー・警告・遅いSQLなどのイベントを起点に調査する
Metric	MySQL / InnoDBの状態値	DBの状態や負荷傾向を時系列で監視する

Percona Monitoring and Management

DB中心の監視・性能分析基盤です。
DB全体のパフォーマンスを可視化し、一定期間に「どのSQLがどれだけ実行され、どれだけ時間やリソースを使ったか」を把握、DB側の原因を深掘りするのに適しています。
Percona Monitoring and Management

Percona Server 9.7.1-1 で OpenTelemetry を使ってみる

検証環境について

今回の検証環境は、Oracle Linux 8で以下のDocker環境を構築しました。
(各アプリケーション名の下にイメージバージョンを記載しています。)

クエリ実行から監視までの流れは以下の通りです。

FastAPIで作成したサンプルAPIから Percona Server へSQLを実行します。
Percona ServerからテレメトリーをOTel Collectorへ送信し、TraceはJaeger、LogはLoki、MetricはPrometheusで取得し、Grafanaで監視します。
PMM ClientでMetricを取得し、PMM Serverで監視を行います。

Percona ServerでOpenTelemetryを有効化する

Telemetry機能はcomponent_telemetry というコンポーネントによって提供され、以下のコマンドでロードします。

mysql&gt; INSTALL COMPONENT 'file://component_telemetry';

				1

						mysql&gt; INSTALL COMPONENT 'file://component_telemetry';

続いて、テレメトリー変数の設定ですが my.cnf に以下の設定を追加し、Percona Serverを再起動します。
今回、その他テレメトリ変数についてはデフォルト値としています。詳細は公式ドキュメントを参照してください。
https://dev.mysql.com/doc/refman/9.7/en/telemetry-system-variables.html

[mysqld]

# Traceの有効化
telemetry.trace_enabled=ON
telemetry.otel_exporter_otlp_traces_endpoint=http://otel-collector:4318/v1/traces

# Metricの有効化
telemetry.metrics_enabled=ON
telemetry.otel_exporter_otlp_metrics_endpoint=http://otel-collector:4318/v1/metrics

# Logの有効化
telemetry.log_enabled=ON
telemetry.otel_exporter_otlp_logs_endpoint=http://otel-collector:4318/v1/logs

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13

						[mysqld]
 
# Traceの有効化
telemetry.trace_enabled=ON
telemetry.otel_exporter_otlp_traces_endpoint=http://otel-collector:4318/v1/traces
 
# Metricの有効化
telemetry.metrics_enabled=ON
telemetry.otel_exporter_otlp_metrics_endpoint=http://otel-collector:4318/v1/metrics
 
# Logの有効化
telemetry.log_enabled=ON
telemetry.otel_exporter_otlp_logs_endpoint=http://otel-collector:4318/v1/logs

					

			

telemetry.otel_exporter_otlp_xxx_endpoint が各情報のターゲットURLで、本環境では OTel Collector を指定しています。

また、Percona Server 9.7.1-1 の OTLPトランスポートプロトコルのデフォルト値はhttp/protobufです。
そのため、今回は OTel Collector の OTLP/HTTPエンドポイント（http://otel-collector:4318/v1/xxx）をターゲットURLに指定しています。
エンドポイントの設定詳細は OpenTelemetryのドキュメントをご確認ください。
https://opentelemetry.io/ja/docs/languages/sdk-configuration/otlp-exporter/

また、実際にOpenTelemetryで監視する場合、上記 Percona Serverの設定に加え、FastAPI側のOpenTelemetry計装、アプリケーションからMySQLへのTrace Context伝播、およびOTel Collectorの受信・転送設定が必要です。

検証：同じ問題をOpenTelemetryとPMMはどう見るか

ここからは、実際に遅延とエラーを発生させ、OpenTelemetryとPMMで何が見えるかを比較します。
具体的には、①DBが遅いケース、②アプリケーションが遅いケース、③クエリがエラーになるケースを確認します。

最初に押さえるべき点は「両者は同じ情報を別の画面で表示する仕組みではない」点です。
Jaegerで見るTraceは、個別リクエストを単位にした記録です。
一方、PMM QAN(Query Analytics) は正規化したSQL単位に一定期間の実行結果を集計して表示します。

観点	OpenTelemetry / Jaeger	PMM / QAN
主な観測単位	個別のHTTPリクエストとTrace	正規化SQLの集計
得意な問い	このリクエストは、どこで時間を使い、どこで失敗したか	どのSQLが、どれだけDB負荷を生んだか
DB以外の遅延	DB以外で時間を使っていることを確認できる	直接の原因特定はできない
DB内部の分析	個別実行のspan属性を確認できる	Query Time、Rows Examinedなどを集計して確認できる

①DBが遅いケース

アプリケーションから重いSELECTを実行する/slow-db APIを実行します。
本APIのクエリは、テーブルの70万行にアクセスし、 GROUP BY による集計と ORDER BY によるソートを行います。

@app.get("/slow-db")
def slow_db():
    conn = get_connection()
    cursor = conn.cursor()

    # 重いクエリを実行し、DB処理で遅延を発生させる
    cursor.execute("""
        SELECT
            category,
            COUNT(*) AS cnt,
            SUM(value1) AS total_value,
            AVG(value2) AS avg_value
        FROM otel_lab.slow_test
        WHERE id &lt;= 700000
          AND category BETWEEN 10 AND 90
        GROUP BY category
        ORDER BY total_value DESC
    """)

    rows = cursor.fetchall()

    cursor.close()
    conn.close()

    return {
        "status": "ok",
        "result_rows": len(rows),
    }

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

						@app.get("/slow-db")
def slow_db():
    conn = get_connection()
    cursor = conn.cursor()
 
    # 重いクエリを実行し、DB処理で遅延を発生させる
    cursor.execute("""
        SELECT
            category,
            COUNT(*) AS cnt,
            SUM(value1) AS total_value,
            AVG(value2) AS avg_value
        FROM otel_lab.slow_test
        WHERE id &lt;= 700000
          AND category BETWEEN 10 AND 90
        GROUP BY category
        ORDER BY total_value DESC
    """)
 
    rows = cursor.fetchall()
 
    cursor.close()
    conn.close()
 
    return {
        "status": "ok",
        "result_rows": len(rows),
    }

					

			

DB遅延時のJaeger Trace

Jaegerでは、1HTTPリクエストにおけるGET /slow-dbの所要時間は約2.21秒でした。そのほぼ全体である2.2秒をMySQLのSELECTに対応するstatement spanが占めていることがわかります。

よって、HTTPリクエストが遅い原因は、少なくともこの実行ではアプリケーションのHTTP処理ではなく、MySQLでのSQL実行にあると判断できます。

また、このstatement spanにはSQLの digest_textに加え、rows_examined、no_index_used、created_tmp_disk_tablesなどの属性も出力されています。
（例えばrows_examinedにより約70万行にアクセスしていることが分かります）

したがって、Trace上でも「どのSQLが遅かったか」、「SQLがどの程度の行を読むか」、「インデックスを使用せずにテーブルスキャンを実行したか」といった個別実行におけるDB実行情報を把握することができます。

Traceに記録されるステートメント関連の属性は33種あり、詳細は公式ドキュメントをご参照ください。
MySQL 9.7 Reference Manual 35.3.2 Trace Format

DB遅延時のPMM QAN

次に、PMM QANで確認します。QANでは、クエリは正規化され集計されるため、参照するSQLも正規化されたクエリとなる点に注意が必要です。

今回、対象SQLは全体で5回実行されており、平均 Query Time は2.39秒、1回あたりの Rows Examined は約70万行であることが分かります。

QANでは単にクエリが遅いだけでなく、どのような処理特性を持つかといった34種のメトリックを継続的な集計として確認できます。
QANで確認できるメトリックについて、以下の弊社ブログでも紹介しているのでご参照ください。
Percona Monitoring and ManagementのQuery Analytics機能紹介①

PMMだけでも遅いSQLの存在は把握できます。しかし、アプリケーションから見えている遅いリクエストと、そのSQL実行を同じ処理経路で確認できることは、Traceならではの利点ではないでしょうか。

②アプリケーションが遅いケース

次に、DB処理が軽く、アプリケーション側で待機する/slow-appAPIを実行します。
本APIはSELECT NOW()を実行した後、time.sleep(3)で3秒間待機（遅延発生）させます。

@app.get("/slow-app")
def slow_app():
    conn = get_connection()
    cursor = conn.cursor()
    
    cursor.execute("SELECT NOW()")
    row = cursor.fetchone()

    cursor.close()
    conn.close()

    # DB処理ではなく、アプリケーション側で意図的に遅延させる
    time.sleep(3)

    return {
        "status": "ok",
        "database_time": str(row[0]),
    }

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

						@app.get("/slow-app")
def slow_app():
    conn = get_connection()
    cursor = conn.cursor()
    
    cursor.execute("SELECT NOW()")
    row = cursor.fetchone()
 
    cursor.close()
    conn.close()
 
    # DB処理ではなく、アプリケーション側で意図的に遅延させる
    time.sleep(3)
 
    return {
        "status": "ok",
        "database_time": str(row[0]),
    }

					

			

アプリケーション遅延時のJaeger Trace

Jaegerでは、1HTTPリクエストにおけるGET /slow-appの所要時間は約3.01秒でした。一方、SELECT NOW()に対応するstatement spanは48マイクロ秒です。

つまり、リクエストは遅いがDB処理が遅延の原因ではないことを同じTraceの中で判断できます。

また、今回は検証のため time.sleep(3)そのものを表す独自spanは作成していません。
そのため、Traceから確認できるのは「DB以外で約3秒を消費している」ということまでであり、アプリケーション内のどの関数が遅いかまでは特定できません。
アプリケーション内部の処理まで追跡したい場合は、処理に独自spanを追加する必要があります。

アプリケーション遅延時のPMM QAN

PMM QANでも、SELECT NOW()の平均Query Timeは84.70µsであり、本クエリが遅くないことを確認できます。

したがってPMMだけでも「少なくともこのSQLは遅くない」と判断する材料は得られます。
ただし、HTTPリクエスト全体が約3秒かかっていることや、そのうちDB外で時間を使っていることはQANだけからは分かりません。

③クエリがエラーになるケース

最後にSQLエラーが発生する/db-errorAPIを実行します。

本APIはSELECT NOW()を実行した後、存在しないテーブルnonexistent_tableにSELECTを実行しエラーを発生させます。

@app.get("/db-error")
def db_error():
    conn = get_connection()
    cursor = conn.cursor()

    try:
        # 正常に成功するクエリ
        cursor.execute("SELECT NOW()")
        rows = cursor.fetchall()
  
        # 存在しないテーブルを参照し、クエリがエラーになる
        cursor.execute("SELECT * FROM nonexistent_table")
        rows = cursor.fetchall()

        return {
            "status": "ok",
            "rows": len(rows),
        }

    except mysql.connector.Error as e:
        return {
            "status": "error",
            "mysql_errno": e.errno,
            "sqlstate": e.sqlstate,
            "message": str(e),
        }

    finally:
        cursor.close()
        conn.close()

				
					
				1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

						@app.get("/db-error")
def db_error():
    conn = get_connection()
    cursor = conn.cursor()
 
    try:
        # 正常に成功するクエリ
        cursor.execute("SELECT NOW()")
        rows = cursor.fetchall()
  
        # 存在しないテーブルを参照し、クエリがエラーになる
        cursor.execute("SELECT * FROM nonexistent_table")
        rows = cursor.fetchall()
 
        return {
            "status": "ok",
            "rows": len(rows),
        }
 
    except mysql.connector.Error as e:
        return {
            "status": "error",
            "mysql_errno": e.errno,
            "sqlstate": e.sqlstate,
            "message": str(e),
        }
 
    finally:
        cursor.close()
        conn.close()

					

			

クエリーエラー時のJaeger Trace

Jaeger では、HTTPリクエストGET /db-errorの配下にMySQLのstatement spanがエラーとして記録されます。

エラーになったクエリのspanには次の属性値が記録され、この結果から「HTTPリクエストの途中で、どのSQLがMySQLエラーになったか」を確認できます

属性	値
mysql.digest_text	SELECT * FROM nonexistent_table
mysql.error_count	1
mysql.message_text	Table ‘otel_lab.nonexistent_table’ doesn’t exist

またTraceから、このHTTPリクエストではSELECT NOW()は成功し、次の処理の"SELECT * FROM nonexistent_table" でエラーが発生したことも分かります。

もっとも、アプリケーションがMySQLエラーをそのまま利用者やアプリケーションログへ返す実装であれば、Traceを見なくても初動で原因候補まで分かる場合があります。そのような単純なケースでは、Traceは必須ではありません。

Traceの価値が高くなるのは、例えば次のような場面だと言えます。

アプリケーションがDBエラーを共通のHTTP 500や独自エラーコードに置き換える
1リクエスト内で複数のSQLや外部APIを実行しており、どこで失敗したか分からない
MySQLログに該当のSQLエラーが残らない

この例では、MySQLエラーログには残らない種類のエラーであっても、Trace側にSQLとエラー内容が記録されています。

OpenTelemetryでは、アプリケーションの失敗を起点にDBでの失敗箇所まで追跡する経路を追加できると言えます。

クエリーエラー時のPMM QAN

PMM QANでも、エラーとなったクエリのエラーメッセージを確認することができます。

ただし、HTTPリクエスト内のどのクエリまでは成功していて、どのクエリがエラーになったのかはQANだけからは分かりませんし、確認したいクエリを事前に特定しておくといった必要もあります。

トレース連携：ログを調査の入口にできるか

Grafanaの設定で、Loki と Jaeger のTrace IDを連携することができます。
今回確認できたログイベントでは、GrafanaのLoki上で表示したログ(エラーログ、スロークエリログ)の Trace ID から、Jaegerパネルを直接開き Trace 情報の詳細を確認することができました。

この連携により、エラーログやスロークエリログを起点にして、単一のログ行だけでは把握しにくいSQL実行の情報を確認できます。

例えば、ログから「いつ、どの種類のイベントが起きたか」を見つけ、Traceから「関連するSQLは何か」「どの程度時間を使ったか」を追跡する、といった使い方ができます。

Telemetry機能の注意点：一部Metricが正しく出力されない

今回、Percona Server 9.7.1-1で検証したところ、一部の mysql.stats Metricで、対応する SHOW GLOBAL STATUSの値が増加しているにもかかわらず、OpenTelemetryでexportされた値が0となる挙動を確認しました。

調査の結果、この挙動はバグによるもので既にバグレポートも起票されており、今後のリリースで改善される可能性があります。
https://perconadev.atlassian.net/browse/PS-11538

実際に Metric を監視やアラート利用する場合、本バグの修正を待つか、修正されるまでは事前に元データと突合し正常に値が取得されているメトリックであるかを確認する必要があります。

結論：DB監視を増やすためではなく、調査の入口を広げるためにTelemetryを使う

Telemetry機能の Metricには、SHOW GLOBAL STATUSで取得できるメトリックをはじめ、DBの状態を把握するための様々な指標が含まれていますが、多くのメトリックは累積値です。
MySQL 9.7 Reference Manual 35.4.3 Server Metrics

例えば、Innodb_rows_read(InnoDBテーブルから読み取られた行数)は以下の値として取得されます。 (末尾の2.8e+07がメトリック値)

rows_read_total{instance="5da07d7786fd:1",job="mysql/mysqld",otel_scope_name="mysql.inno",otel_scope_schema_url="url",otel_scope_version="1.0"} 2.8e+07

				1

						rows_read_total{instance="5da07d7786fd:1",job="mysql/mysqld",otel_scope_name="mysql.inno",otel_scope_schema_url="url",otel_scope_version="1.0"} 2.8e+07

つまり、異なるタイミングで取得するとその時点での累積値が取得されます。

タイミング	Innodb_rows_readの値
取得タイミング1	28,000,000
取得タイミング2	42,000,000

そのため、DBAが負荷を直感的に判断するには、レート計算、時系列グラフ、アラートを別途設計する必要があります。
例えば、直近1分間における1秒あたりの Innodb_rows_readをグラフ化するには、メトリックごとに以下のような PromQL を作成しグラフ化する必要があります。

rate(rows_read_total{otel_scope_name="mysql.inno"}[1m])

				1

						rate(rows_read_total{otel_scope_name="mysql.inno"}[1m])

一方でPMMには、DB監視でよく確認するMetricのダッシュボードと、SQLを集計して分析するQANがあらかじめ用意されています。DB単体のリソース監視や遅いSQLの把握をすぐに始めたいなら、PMMの方が扱いやすいです。

OpenTelemetryを追加する意味は、DB MetricをPMMの代わりに取得することではなく、アプリケーション、MySQL、ログをTraceの文脈で結び、次のような調査の入口を作れることにあります。

遅い・失敗したリクエストまたはLog(MySQLログ)を確認する
Traceで、どの処理が遅い・失敗したかを確認する
DBが疑わしい場合は、PMMなどのツールでSQLとDB負荷を掘り下げる

したがって、OpenTelemetryはPMMの代替ではなく、既存のObservability基盤にPercona Serverを加えるための仕組みとして考えるのが適切と言えそうです。

まとめ

今回の検証結果から、OpenTelemetry基盤を新規構築してまでDB Metricだけを取得する目的であればPMMを優先する方がよいと考えます。 PMMにはDB運用で必要となる監視項目のダッシュボードがあらかじめ用意されており、Metricの生の累積値を監視に適した形へ加工する作業を省けるためです。

反対に、次のような環境ではOpenTelemetryを利用する価値があります。

すでに組織全体でOpenTelemetryベースのObservability基盤を運用している
アプリケーションからDBまで含めて、遅延・障害を同じ調査導線で扱いたい
まずDBが原因かどうかをリクエスト単位で切り分けたい
MySQLログをTraceと関連付け、ログだけでは見えないSQL実行やリクエスト文脈を確認したい

ただし、OpenTelemetryを導入すべきかどうかは、既存Observability基盤、アプリケーションとの境界をまたぐ調査の必要性、運用コストを踏まえて導入を判断してください。

既にOpenTelemetry基盤がある場合は、まず検証環境でTraceのみを有効化し、取得情報、性能影響、SQL本文の扱いを確認してみてください。

本記事が皆様の参考になれば幸いです。

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがPerconaに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

パソナデータ&デザインのPerconaサポートについて

Perconaに関するお問合せはこちら

よかったらシェアしてね！

URLをコピーしました！

MySQL InnoDB Buffer Pool の最適値はこう決める：メトリクスとベンチマークで検証する実践チューニング