MySQL 監視の新時代: Prometheus と OpenTelemetry メトリクス

現代のアプリケーション開発において、可観測性はもはや任意のものではありません。安定した運用、迅速なトラブルシューティング、そしてシステムの挙動をよりよく理解するための中核的な要件です。

データベースは特に重要です。多くの場合、アプリケーション性能の中心に位置しているためです。データベースが遅くなったり、過負荷になったり、利用できなくなったりすると、その影響は通常、アプリケーションスタック全体に及びます。そのため、MySQLのメトリクスを正確かつタイムリーに可視化することは、DBA、SRE、アプリケーションチームにとって不可欠です。

MySQL Telemetry を使うと、OpenTelemetry Protocol（OTLP）を使用して MySQL サーバーメトリクスをエクスポートできます。これにより、MySQLのメトリクスを Prometheus のような OpenTelemetry 対応バックエンドへ送信できるようになります。

構築するもの

この例では、MySQL が OpenTelemetry メトリクスを Prometheus に直接エクスポートします。

**図1:** MySQL OpenTelemetry メトリクスが Prometheus OTLP レシーバーへ流れる構成

Prometheus は HTTP 経由での OTLP 取り込みをサポートしています。Prometheus の OTLP レシーバーはデフォルトでは無効であり、--web.enable-otlp-receiver フラグで有効化する必要があります。有効化すると、Prometheus は /api/v1/otlp/v1/metrics エンドポイントで OTLP メトリクスを受信します。

Prometheus で MySQL OpenTelemetry メトリクスを使う 2 つのアーキテクチャ選択肢

Prometheus で MySQL OpenTelemetry メトリクスを使う一般的な方法は 2 つあります。

オプション 1: Prometheus へ直接エクスポートする

最もシンプルなアーキテクチャは、MySQL から Prometheus OTLP レシーバーへ OTLP メトリクスを直接送信する方法です。

この記事で使うのはこのアプローチです。構成要素が少なく、MySQL Telemetry と Prometheus をすばやく試し始めるのに適しています。

このモデルでは、MySQL が Prometheus エンドポイントへメトリクスを直接エクスポートします。Prometheus は OTLP レシーバー経由でメトリクスを受信し、PromQL クエリ、ダッシュボード、アラートで利用できるようにします。

オプション 2: OpenTelemetry Collector 経由でエクスポートする

2 つ目の選択肢は、MySQL と Prometheus の間に OpenTelemetry Collector を配置する方法です。

このアーキテクチャはやや複雑ですが、追加の柔軟性があります。OpenTelemetry Collector は、テレメトリデータを受信、処理、エクスポートするためのベンダー非依存の方法を提供します。最終的なバックエンドへデータが到達する前に、テレメトリパイプラインをカスタマイズするために使用できます。

Collector を使うと、チームはテレメトリの流れをカスタマイズできます。たとえば、メトリクスのフィルタリング、属性の付加、データのバッチ化、メトリクス名やラベルの変換、複数バックエンドへのテレメトリのルーティング、多数のシステムにまたがるテレメトリ処理の一元化などが可能です。

この記事では、基本的な統合を示す最も簡単な方法として、MySQL から Prometheus へ直接送信するアプローチ、つまりオプション 1 に焦点を当てます。本番環境では、追加のカスタマイズ、ルーティング、または一元的なテレメトリ管理が必要な場合、OpenTelemetry Collector が好まれることがあります。

1. MySQL Telemetry を設定する

MySQL のテレメトリ設定には 2 つの層があります。

1. Exporter 設定
   – メトリクスを有効化する
   – OTLP プロトコルを設定する
   – OTLP エンドポイントを設定する必要に応じて
   – TLS、ヘッダー、圧縮、タイムアウトを設定する

2. Meter設定
   – meter グループを有効化または無効化する
   – meter frequency を設定する
   – MySQL が各グループをどの頻度で評価し、エクスポートするかを定義する

Exporter 設定は、メトリクスを「どこへ、どのように送るか」を定義します。Meter 設定は、「どのメトリクスグループを有効にし、どの頻度で評価するか」を定義します。

メトリクスを有効化し、OTLP エンドポイントを設定する

MySQL のテレメトリ設定は、サーバーシステム変数です。テレメトリメトリクス関連の変数はグローバルかつ動的変更不可のため、実用的な方法は SET PERSIST_ONLY で設定を永続化し、その後 MySQL を再起動して起動時に値を適用することです。MySQL のドキュメントでは、SET PERSIST_ONLY は現在の実行時値を変更せずに、変数設定を mysqld-auto.cnf に書き込むと説明されています。そのため、サーバー起動時に適用する必要がある変数に適しています。

グローバルシステム変数を永続化する権限を持つアカウントで MySQL セッションから次を実行します。

SET PERSIST_ONLY telemetry.metrics_enabled = ON;

SET PERSIST_ONLY telemetry.otel_exporter_otlp_metrics_protocol = 'http/protobuf';

SET PERSIST_ONLY telemetry.otel_exporter_otlp_metrics_endpoint =
  '&lt;prometheus_host&gt;:9090/api/v1/otlp/v1/metrics';

SET PERSIST_ONLY telemetry.metrics_reader_frequency_1 = 10;
SET PERSIST_ONLY telemetry.metrics_reader_frequency_2 = 60;
SET PERSIST_ONLY telemetry.metrics_reader_frequency_3 = 300

<PROMETHEUS_HOST> は、Prometheus サーバーのホスト名または IP アドレスに置き換えてください。

telemetry.metrics_enabled 変数は、テレメトリメトリクスを収集するかどうかを制御します。デフォルト値は OFF です。MySQL は OTLP メトリクスプロトコルとして http/protobuf と http/json をサポートしており、デフォルトは http/protobuf です。MySQL ドキュメントでは、このメトリクスエクスポート設定では gRPC はサポートされないことも示されています。

注: この設定例では、エンドポイント値に http:// を含めないでください。プロトコル接頭辞を含めると、次のような無効なエンドポイントになる可能性があります。

http://http://...

設定を永続化したら、MySQL を再起動します。

sudo systemctl restart mysqld

次に、有効なテレメトリ設定を確認します。

SHOW VARIABLES LIKE 'telemetry%';

メトリクス関連の設定に絞ることもできます。

SHOW VARIABLES LIKE 'telemetry.metrics%';

SHOW VARIABLES LIKE 'telemetry.otel_exporter_otlp_metrics%';

期待される値には、次のような項目が含まれます。

telemetry.metrics_enabled                         ON
telemetry.metrics_reader_frequency_1              10
telemetry.metrics_reader_frequency_2              60
telemetry.metrics_reader_frequency_3              300
telemetry.otel_exporter_otlp_metrics_protocol     http/protobuf
telemetry.otel_exporter_otlp_metrics_endpoint     <prometheus_host>:9090/api/v1/otlp/v1/metrics</prometheus_host>

SHOW VARIABLES を実行すると、次のような結果が表示されます。

MySQL の Meter グループを理解する

MySQL は、サーバーメトリクスを meter と呼ばれるグループに整理します。利用可能な meter グループは performance_schema.setup_meters から確認できます。このテーブルには、各 meter 名、頻度、有効状態、説明が含まれます。

SELECT NAME, FREQUENCY, ENABLED, DESCRIPTION
FROM performance_schema.setup_meters;

meter グループは、MySQL サーバーの挙動に関連する領域を表します。

Meter グループ	提供する内容
mysql.inno	一般的な InnoDBのメトリクス。InnoDBストレージ・エンジンでのレベルの活動を対象とし、ストレージ・エンジンの挙動理解に役立ちます。
mysql.inno.buffer_pool	InnoDB バッファプール・メトリクス。バッファプールの使用状況と効率の監視に役立ちます。
mysql.inno.data	InnoDB データ・メトリクス。InnoDB データファイルと I/O 関連活動の理解に役立ちます。
mysql.x	MySQL X Plugin メトリクス。X Protocol の活動を可視化します。
mysql.x.stmt	MySQL X Plugin のステートメント統計。X Protocol のステートメント活動の監視に役立ちます。
mysql.stats	コア MySQL サーバーメトリクス。一般的なサーバーレベルの状態や活動指標を含みます。
mysql.stats.com	MySQL コマンド統計。ステートメント実行活動などのコマンドカウンターに対応します。
mysql.stats.connection	MySQL 接続統計。接続活動や接続関連の挙動の監視に役立ちます。
mysql.stats.handler	MySQL ハンドラー統計。ストレージエンジンが使用する低レベルのハンドラー操作に関する情報を提供します。
mysql.stats.ssl	TLS 関連統計。SSL/TLS の使用状況や関連活動の監視に役立ちます。
mysql.myisam	MyISAM ストレージエンジン統計。MyISAM テーブルをまだ使用している環境に関連します。
mysql.perf_schema	Performance Schema の lost-instrument メトリクス。Performance Schema が一部の instrumentation データを取得できなかったケースの把握に役立ちます。
mysql.mle	MySQL MLE コンポーネントメトリクス。MySQL MLE コンポーネントの活動を可視化します。

重要なのは、MySQL Telemetry が単一のメトリクスストリームではないという点です。meter グループとして整理されており、監視要件に応じて、それらのグループを有効化、無効化、調整できます。

**図3:** `performance_schema.setup_meters` に設定された MySQL meter グループ

Metrics Reader Frequency を設定する

MySQL は、meter グループをどの頻度で評価しエクスポートするかを定義する metrics reader frequency 変数を提供します。

telemetry.metrics_reader_frequency_1
telemetry.metrics_reader_frequency_2
telemetry.metrics_reader_frequency_3

これらの値は秒単位で定義されます。telemetry.metrics_reader_frequency_1 は必須で、その値以下の FREQUENCY を持つ meter に適用されます。telemetry.metrics_reader_frequency_2 は任意で、frequency 1 より大きく frequency 2 以下の FREQUENCY を持つ meter に適用されます。telemetry.metrics_reader_frequency_3 も任意で、frequency 2 より大きい FREQUENCY を持つ meter に適用されます。ドキュメント上のデフォルト値は、それぞれ 10 秒です。

例:

SET PERSIST_ONLY telemetry.metrics_reader_frequency_1 = 10;
SET PERSIST_ONLY telemetry.metrics_reader_frequency_2 = 60;
SET PERSIST_ONLY telemetry.metrics_reader_frequency_3 = 300;

この設定では、次のようになります。

FREQUENCY <= 10 の meter は 10 秒ごとに評価されます。
FREQUENCY > 10 かつ <= 60 の meter は 60 秒ごとに評価されます。
FREQUENCY > 60 の meter は 300 秒ごとに評価されます。

これにより、接続やコアサーバー活動のように変化の速い運用メトリクスはより高頻度でエクスポートし、変化の遅いメトリクスは低頻度でエクスポートできます。

個別の Meter グループを調整する

meter グループの FREQUENCY と ENABLED の値は、performance_schema.setup_meters で編集できます。MySQL は、サーバー起動時または設定ファイルで、--performance-schema-meter='meterName=frequency:integer,enabled:ON|OFF' 構文を使って meter を設定することもサポートしています。

例:

UPDATE performance_schema.setup_meters
SET FREQUENCY = 10, ENABLED = 'YES'
WHERE NAME = 'mysql.stats.connection';

UPDATE performance_schema.setup_meters
SET FREQUENCY = 60, ENABLED = 'YES'
WHERE NAME = 'mysql.inno.buffer_pool';

UPDATE performance_schema.setup_meters
SET FREQUENCY = 300, ENABLED = 'YES'
WHERE NAME = 'mysql.mle';

または、起動時に meter を設定します。

--performance-schema-meter='mysql.stats.connection=frequency:10,enabled:ON'

実務上のポイントは次のとおりです。

performance_schema.setup_meters は、どのメトリクスグループを有効にするか、そして頻度によってどう分類するかを制御します。telemetry.metrics_reader_frequency_* は、それらのグループをどの頻度で評価し、OTLP 経由でエクスポートするかを制御します。

2. Prometheus を設定する

Prometheus は、OTLP レシーバーを有効にした状態で起動する必要があります。

起動オプション:

--web.enable-otlp-receiver

systemd 設定例:

ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.listen-address=0.0.0.0:9090 \
  --web.enable-otlp-receiver

Prometheus を再起動すると、OTLP メトリクスエンドポイントは次で利用可能になります。

/api/v1/otlp/v1/metrics

Prometheus のドキュメントでは、OTLP レシーバーはデフォルトで無効であると説明されています。Prometheus は認証なしで動作することがあるため、OTLP トラフィックの受け入れは明示的な設定判断であるべきだからです。

エンドポイントが存在することは、次で確認できます:

curl http://localhost:9090/api/v1/otlp/v1/metrics

GET リクエストに対して 405 Method Not Allowed が返るのは想定どおりです。OTLP メトリクスエンドポイントは POST でメトリクスを受信するためです。

3. Prometheus でメトリクスを確認する

Prometheus UI を開き、次のような PromQL クエリを実行します。

threads_connected

または:

max_used_connections

次に、MySQL のステータス変数と値を比較します:

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Prometheus で値が表示され、MySQL のステータス出力と一致していれば、設定は正しく動作しています。

**図5:** Prometheus UI で確認した MySQL 接続数（`threads_connected`）

**図6:** Prometheus UI のグラフとして表示した MySQL 接続数（`threads_connected`）

**図7:** 負荷テスト中に Grafana で可視化した MySQL 接続数

Telemetry のプッシュモデルが重要な理由

上記の設定は、Prometheus へメトリクスを送信する新しい方法を示しているだけではありません。監視モデルそのものも変えます。

従来の MySQL 監視では、一般的に pull ベースのアプローチが使われます。外部の exporter または collector が、専用の監視ユーザーで MySQL に接続し、ステータス変数や Performance Schema を問い合わせ、そのメトリクスを Prometheus が scrape できる形で公開します。

MySQL Telemetry は push ベースのモデルを使います。MySQL が、Prometheus OTLP レシーバーのような OTLP エンドポイント・へメトリクスを直接エクスポートします。

基本的なメトリクス収集では、これにより、専用の MySQL 監視ユーザーを作成する必要、外部 exporter にデータベース認証情報を保存する必要、さらに MySQL への追加のインバウンド監視接続を許可する必要を減らせます。

これは、いくつかの点でセキュリティモデルを改善します。

基本的なメトリクスエクスポートに専用の MySQL 監視ユーザーが不要
メトリクスは MySQL から直接エクスポートされるため、監視のためだけに別個のデータベースアカウントを作成する必要が少なくなります。
外部 exporter にデータベース認証情報を保存する必要がない
従来の exporter は MySQL に接続するための認証情報を必要とします。telemetry push では、この基本的なメトリクス経路において認証情報が不要になり、認証情報の露出と運用リスクを減らせます。
MySQL へのインバウンドアクセスを減らせる
pull ベースモデルでは、exporter または collector が MySQL に接続できる必要があります。push ベースモデルでは、MySQL が設定されたエンドポイントへテレメトリを送信するため、ネットワークアクセスパターンを単純化できます。
Telemetry 経路を独立して保護できる
OTLP エンドポイントは、ネットワーク制御、ファイアウォールルール、該当する場合は TLS、可観測性プラットフォームに適したアクセス制御によって保護できます。
認証情報管理が簡素化される
データベースアカウントや外部に保存されるシークレットが少なくなれば、ローテーション、監査、保護が必要な認証情報も少なくなります。

これは、セキュリティ制御が不要になるという意味ではありません。Prometheus または OpenTelemetry エンドポイントは、引き続き適切に保護する必要があります。ただし、外部監視プロセスが MySQL に認証する必要をなくすことで、認証情報管理のリスクを減らし、監視アーキテクチャを単純化できます。

MySQL Telemetry を Prometheus と使う利点

MySQL Telemetry を Prometheus と採用することで、チームは監視アーキテクチャを単純化し、MySQL の可観測性を OpenTelemetry ベースのワークフローと整合させることができます。

シンプルな Prometheus 統合

OTLP レシーバーを有効にすると、Prometheus は OTLP メトリクスを直接受信できます。これにより、MySQL メトリクスを PromQL で問い合わせ、Prometheus 互換のダッシュボードで可視化できます。

ベンダー非依存の Telemetry

OpenTelemetry は、テレメトリデータのベンダー非依存モデルを提供します。これにより、チームはメトリクスを別のバックエンドへルーティングしたり、要件が変わった場合に後から OpenTelemetry Collector を追加したりする柔軟性を得られます。

統合された可観測性

MySQL メトリクスを、アプリケーションメトリクス、トレース、ログを含むより広範な可観測性戦略の一部にできます。これにより、チームはデータベースを単独で見るのではなく、アプリケーションスタック全体にまたがって性能問題を調査できます。

よりシンプルなアーキテクチャ

多くのユースケースでは、別個の MySQL exporter プロセスを必要とせず、MySQL がメトリクスを直接エクスポートできます。これにより、インストール、設定、保護、保守が必要な構成要素を減らせます。

柔軟な本番アーキテクチャ

チームは、シンプルな構成として MySQL から Prometheus への直接エクスポートから始められます。要件が増えたら、OpenTelemetry Collector を導入して、テレメトリデータのカスタマイズ、処理、ルーティングを行えます。

調整可能なメトリクス収集

MySQL の meter グループと metrics reader frequency 設定により、チームはどのカテゴリのメトリクスを有効にし、どの頻度で評価およびエクスポートするかを制御できます。

`mysqld_exporter` を引き続き使うべき場合

MySQL Telemetry は大きな前進ですが、既存の監視ツールを常に完全に置き換えられるわけではありません。

mysqld_exporter のような従来型ツールは、次のような場合には今でも適していることがあります。

exporter のメトリクス名を前提に構築された既存の Prometheus ダッシュボードやアラートがある場合
レプリケーション固有の監視
より詳細な SQL または Performance Schema 分析
pull ベースの Prometheus scrape モデルを引き続き優先する環境

実務上、多くのチームはハイブリッドアプローチを選ぶ可能性があります。OpenTelemetry ベースの可観測性には MySQL Telemetry を使い、専門的な MySQL 運用メトリクスには mysqld_exporter を引き続き使う、という形です。

Conclusion

MySQL OpenTelemetry メトリクスは、MySQL の可観測性を Prometheus に取り込むための現代的な方法を提供します。

最もシンプルなアーキテクチャは、MySQL から Prometheus OTLP レシーバーへの直接エクスポートです。これにより、お客様は MySQL メトリクスエクスポートを設定し、Prometheus で結果を確認し、ダッシュボードやアラートの構築を始められます。

より高度なデプロイでは、MySQL と Prometheus の間に OpenTelemetry Collector を導入できます。これにより、フィルタリング、属性付加、バッチ化、ルーティング、変換、複数バックエンドへのエクスポートといった追加機能を利用できます。

このアプローチは、お客様に実践的な進め方を提供します。

MySQL から Prometheus への OTLP 直接エクスポートでシンプルに始める
より多くのカスタマイズが必要になったら OpenTelemetry Collector を追加する
SET PERSIST_ONLY を使って MySQL テレメトリ設定を起動時向けに永続化する
SHOW VARIABLES LIKE 'telemetry%'; でテレメトリ設定を確認する
監視ニーズに応じて MySQL meter グループと metrics reader frequency を調整する
基本的なメトリクス収集において、外部データベース認証情報への依存を減らす
OpenTelemetry ベースの、より統合された可観測性アーキテクチャへ進む

可観測性が進化し続ける中で、MySQL Telemetry は、MySQL にとって、よりシンプルで、より柔軟で、より安全な監視に向けた重要な一歩です。

MySQL 監視の新時代: Prometheus と OpenTelemetry メトリクス

構築するもの

Prometheus で MySQL OpenTelemetry メトリクスを使う 2 つのアーキテクチャ選択肢

オプション 1: Prometheus へ直接エクスポートする

オプション 2: OpenTelemetry Collector 経由でエクスポートする

1. MySQL Telemetry を設定する

メトリクスを有効化し、OTLP エンドポイントを設定する

MySQL の Meter グループを理解する

Metrics Reader Frequency を設定する

個別の Meter グループを調整する

2. Prometheus を設定する

3. Prometheus でメトリクスを確認する

Telemetry のプッシュモデルが重要な理由

MySQL Telemetry を Prometheus と使う利点

シンプルな Prometheus 統合

ベンダー非依存の Telemetry

統合された可観測性

よりシンプルなアーキテクチャ

柔軟な本番アーキテクチャ

調整可能なメトリクス収集

`mysqld_exporter` を引き続き使うべき場合

Conclusion

References

Machiko Ikoma

MySQL Principal Solution Engineer

AI が MySQL データベースセキュリティの水準を引き上げている

MySQLコミュニティ・アップデート: 第4回公開ディスカッション、設計提案、Contributor Summit

MySQL 監視の新時代: Prometheus と OpenTelemetry メトリクス

構築するもの

Prometheus で MySQL OpenTelemetry メトリクスを使う 2 つのアーキテクチャ選択肢

オプション 1: Prometheus へ直接エクスポートする

オプション 2: OpenTelemetry Collector 経由でエクスポートする

1. MySQL Telemetry を設定する

メトリクスを有効化し、OTLP エンドポイントを設定する

MySQL の Meter グループを理解する

Metrics Reader Frequency を設定する

個別の Meter グループを調整する

2. Prometheus を設定する

3. Prometheus でメトリクスを確認する

Telemetry のプッシュモデルが重要な理由

MySQL Telemetry を Prometheus と使う利点

シンプルな Prometheus 統合

ベンダー非依存の Telemetry

統合された可観測性

よりシンプルなアーキテクチャ

柔軟な本番アーキテクチャ

調整可能なメトリクス収集

mysqld_exporter を引き続き使うべき場合

Conclusion

References

Authors

Machiko Ikoma

MySQL Principal Solution Engineer

AI が MySQL データベースセキュリティの水準を引き上げている

MySQLコミュニティ・アップデート: 第4回公開ディスカッション、設計提案、Contributor Summit

`mysqld_exporter` を引き続き使うべき場合