MySQL のデータベースモニタリングセットアップのトラブルシューティング

このページでは、MySQL による Database Monitoring のセットアップおよび使用に関する一般的な問題と、その解決方法について詳しく説明します。Datadog では、Agent のバージョンリリースにより内容が変更となる可能性があるため、最新の安定した Agent バージョンを使用し、最新のセットアップドキュメントに従っていただくことをお勧めします。

一般的な問題の診断

Database Monitoring を構成してもデータが表示されない

セットアップ手順に従って Agent を構成してもデータが表示されない場合は、Agent の構成または API キーに問題がある可能性があります。トラブルシューティングガイドに従って、Agent からデータを受信していることを確認してください。

システムメトリクスなどの他のデータは受信しているが、Database Monitoring のデータ (クエリメトリクスやクエリサンプルなど) を受信していない場合、Agent またはデータベースの構成に問題がある可能性があります。Agent の構成がセットアップ手順の例と同様であることを確認し、コンフィギュレーションファイルの場所を再確認してください。

デバッグを行うには、まずAgent のステータスコマンドを実行して、収集されたデータや Datadog に送信されたデータのデバッグ情報を収集します。

Config Errors セクションをチェックして、コンフィギュレーションファイルが有効であることを確認してください。例えば、次のような場合は、インスタンス構成が存在しないか、ファイルが無効であることを示しています。

  Config Errors
  ==============
    mysql
    -----
      Configuration file contains no valid instances

構成が有効であれば、次のように表示されます。

=========
Collector
=========

  Running Checks
  ==============

    mysql (5.0.4)
    -------------
      Instance ID: mysql:505a0dd620ccaa2a
      Configuration Source: file:/etc/datadog-agent/conf.d/mysql.d/conf.yaml
      Total Runs: 32,439
      Metric Samples: Last Run: 175, Total: 5,833,916
      Events: Last Run: 0, Total: 0
      Database Monitoring Query Metrics: Last Run: 2, Total: 51,074
      Database Monitoring Query Samples: Last Run: 1, Total: 74,451
      Service Checks: Last Run: 3, Total: 95,993
      Average Execution Time : 1.798s
      Last Execution Date : 2021-07-29 19:28:21 UTC (1627586901000)
      Last Successful Execution Date : 2021-07-29 19:28:21 UTC (1627586901000)
      metadata:
        flavor: MySQL
        version.build: unspecified
        version.major: 5
        version.minor: 7
        version.patch: 34
        version.raw: 5.7.34+unspecified
        version.scheme: semver

これらの行が出力され、値がゼロより大きいことを確認してください。

Database Monitoring Query Metrics: Last Run: 2, Total: 51,074
Database Monitoring Query Samples: Last Run: 1, Total: 74,451

Agent の構成が正しいことを確認したら、Agent のログでデータベースのインテグレーション実行時に警告やエラーが発生していないかをチェックします。

Datadog Agent で check CLI コマンドを実行し、出力にエラーがないかを検査することで、明示的にチェックを実行することもできます。

# Agent をセルフホストでインストールした場合
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check postgres -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check mysql -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true datadog-agent check sqlserver -t 2

# Agent をコンテナベースでインストールした場合
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check postgres -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check mysql -t 2
DD_LOG_LEVEL=debug DBM_THREADED_JOB_RUN_SYNC=true agent check sqlserver -t 2

クエリに実行計画が欠けている

一部またはすべてのクエリで計画が利用できない場合があります。これは、サポートされていないクエリコマンド、サポートされていないクライアントアプリケーションによって生成されたクエリ、Agent のバージョンが古い、またはデータベースのセットアップが不完全であることなどが原因です。以下は、実行計画が欠けている原因として考えられるものです。

イベントステートメントコンシューマーの欠落

実行計画をキャプチャするには、イベントステートメントのコンシューマーを有効にする必要があります。これを行うには、コンフィグレーションファイル (例: mysql.conf) に以下のオプションを追加します。

performance-schema-consumer-events-statements-current=ON

Datadog では、さらに以下を有効にすることを推奨しています。

performance-schema-consumer-events-statements-history-long=ON

このオプションは、すべてのスレッドにおいて、より多くの最近のクエリを追跡することができます。これをオンにすると、頻度の低いクエリの実行内容をキャプチャできる可能性が高くなります。

実行計画プロシージャの欠落

Agent は datadog.explain_statement(...) というプロシージャが datadog スキーマに存在することを必要とします。datadog スキーマの作成の詳細については、セットアップ手順を参照してください。

Agent が説明プランを収集できるようにするには、explain_statement プロシージャを作成します。

DELIMITER $$
CREATE PROCEDURE datadog.explain_statement(IN query TEXT)
    SQL SECURITY DEFINER
BEGIN
    SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
    PREPARE stmt FROM @explain;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;

完全修飾実行計画プロシージャの欠落

Agent は、プロシージャ explain_statement(...) が、Agent がサンプルを収集できるすべてのスキーマに存在することを必要とします。

実行計画を収集するすべてのスキーマでこのプロシージャを作成します。<YOUR_SCHEMA> をデータベーススキーマに置き換えます。

DELIMITER $$
CREATE PROCEDURE <YOUR_SCHEMA>.explain_statement(IN query TEXT)
    SQL SECURITY DEFINER
BEGIN
    SET @explain := CONCAT('EXPLAIN FORMAT=json ', query);
    PREPARE stmt FROM @explain;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE <YOUR_SCHEMA>.explain_statement TO datadog@'%';

Agent がサポートされていないバージョンで動作している

Agent のバージョンが 7.36.1 以上であることを確認してください。Datadog では、新機能、より良いパフォーマンス、およびセキュリティアップデートをご利用いただくために、定期的な Agent のアップデートをお勧めします。

クエリが切り捨てられる

クエリのサンプルテキストのサイズを大きくする方法については、切り捨てられたクエリサンプルのセクションを参照してください。

クエリを説明することができない

BEGIN、COMMIT、SHOW、USE、ALTER などの一部のクエリでは、データベースから有効な実行計画を得ることができません。SELECT、UPDATE、INSERT、DELETE、REPLACE の各クエリのみが実行計画をサポートしています。

クエリの実行頻度が比較的低い、または実行速度が速い。

このクエリはデータベースの総実行時間の中で大きな割合を占めていないため、選択のためにサンプリングされていない可能性があります。クエリをキャプチャするために、サンプリングレートを上げることを試してみてください。

クエリメトリクスが見つからない

クエリメトリクスデータの欠落を診断する手順を実行する前に、Agent が正常に動作しており、Agent データの欠落を診断する手順を実行していることを確認してください。クエリメトリクスが見つからない場合、以下のような原因が考えられます。

performance_schema が有効になっていない

Agent は、performance_schema オプションが有効になっていることを必要とします。これは、MySQL ではデフォルトで有効になっていますが、構成やクラウドプロバイダーによっては無効になっている場合があります。有効にするには、セットアップ手順に従ってください。

Google Cloud SQL の制限

このホストは Google Cloud SQL で管理されており、performance_schema をサポートしていません。Google Cloud SQL の制限により、Datadog Database Monitoring は16GB 以下の RAM を持つインスタンスではサポートされません

特定のクエリが見つからない

いくつかのクエリのデータはあるが、Database Monitoring で特定のクエリやクエリセットを確認したい場合は、以下のガイドに従ってください。

考えられる原因ソリューション
クエリが「トップクエリ」ではなく、そのクエリの実行時間の合計が、選択した期間のどの時点においても正規化された上位 200 のクエリに含まれていない。クエリが「Other Queries」の行にまとめられている場合があります。どのクエリが追跡されるかの詳細については、収集データを参照してください。追跡されるトップクエリの数を増やしたい場合は、Datadog サポートにお問い合わせください。
events_statements_summary_by_digest が満杯の可能性がある。performance_schema の MySQL テーブル events_statements_summary_by_digest には、保存対象となるダイジェスト (正規化されたクエリ) の数に上限があります。メンテナンスタスクでこのテーブルを定期的にデータを削除することで、すべてのクエリが長期にわたって追跡されるようになります。詳しくは高度な構成をご覧ください。
Agent が最後に再起動してから、クエリが一回実行された。クエリメトリクスは、Agent の再起動後、10 秒間隔で 2 回以上実行された後にのみ発行されます。

クエリサンプルが切り捨てられる

長いクエリの場合、データベースの構成上 SQL の全文が表示されないことがあります。お客様のワークロードに合わせて多少のチューニングが必要です。

Datadog Agent から見える MySQL の SQL テキストの長さは、以下のシステム変数によって決定されます。

max_digest_length=4096
performance_schema_max_digest_length=4096
performance_schema_max_sql_text_length=4096

クエリアクティビティがない

クエリアクティビティと待機イベントコレクションは、Flexible Server ホストでは利用できない MySQL 設定が必要なため、Flexible Server ではサポートされていません。

クエリアクティビティの欠落を診断する手順を実行する前に、Agent が正常に動作しており、Agent データの欠落を診断する手順を実行していることを確認してください。クエリアクティビティが見つからない場合、以下のような原因が考えられます。

performance-schema-consumer-events-waits-current が有効になっていない

Agent は performance-schema-consumer-events-waits-current オプションが有効であることを必要とします。このオプションは MySQL ではデフォルトで無効になっていますが、クラウドプロバイダーによって有効化されている場合があります。有効にするには、セットアップの説明に従ってください。また、データベースのバウンスを回避するために、ランタイムセットアップコンシューマーの設定を検討してください。以下のプロシージャを作成し、実行時に performance_schema.events_* コンシューマーを有効にする機能を Agent に与えます。

DELIMITER $$
CREATE PROCEDURE datadog.enable_events_statements_consumers()
    SQL SECURITY DEFINER
BEGIN
    UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name LIKE 'events_statements_%';
    UPDATE performance_schema.setup_consumers SET enabled='YES' WHERE name = 'events_waits_current';
END $$
DELIMITER ;
GRANT EXECUTE ON PROCEDURE datadog.enable_events_statements_consumers TO datadog@'%';

注: このオプションを使用するには、さらに performance_schema が有効であることが必要です。

MySQL Query Metrics & Samples でスキーマまたはデータベースが見つからない

schema タグ (別名 “database”) は、クエリを実行した接続にデフォルトデータベースが設定されている場合のみ MySQL Query Metrics and Samples に存在します。デフォルトデータベースは、データベース接続パラメーターで “schema” を指定するか、すでに存在する接続で USE Statement を実行することで、アプリケーションによって構成されます。

接続にデフォルトのデータベースが構成されていない場合、その接続で行われるクエリには schema タグは付きません。