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

一般的な問題の診断

データベースモニタリングを構成してもデータが表示されない

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

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

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

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

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

コンフィギュレーションが有効であれば、次のように表示されます。

=========
Collector
=========
  Running Checks
  ==============
    postgres (8.0.5)
    ----------------
      Instance ID: postgres:d3dceb9fd36fd57e [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/postgres.d/conf.yaml
      Total Runs: 16,538
      Metric Samples: Last Run: 186, Total: 2,844,362
      Events: Last Run: 0, Total: 0
      Database Monitoring Query Metrics: Last Run: 2, Total: 24,274
      Database Monitoring Query Samples: Last Run: 1, Total: 17,921
      Service Checks: Last Run: 1, Total: 16,538
      Average Execution Time : 1.765s
      Last Execution Date : 2021-07-26 19:16:58 UTC (1627327018000)
      Last Successful Execution Date : 2021-07-26 19:16:58 UTC (1627327018000)
      metadata:
        version.major: 10
        version.minor: 17
        version.patch: 0
        version.raw: 10.17
        version.scheme: semver

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

Database Monitoring Query Metrics: Last Run: 2, Total: 24,274
Database Monitoring Query Samples: Last Run: 1, Total: 17,921

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

pg_stat_statements 拡張機能がロードされていない

pg_stat_statements 拡張機能がロードされていません。この拡張機能は、Postgres の構成にある shared_preload_libraries によってロードする必要があります (注: この変数を変更した後、有効にするにはサーバーの再起動が必要です)。拡張機能のロード方法に関する詳細は、設定方法を参照してください。

pg_stat_statements 拡張機能がデータベースに作成されていない

pg_stat_statements 拡張機能が正しいデータベースにインストールされていません。Agent が接続するすべてのデータベースで CREATE EXTENSION pg_stat_statements を実行する必要があります。デフォルトでは、Agent は postgres データベースに接続します。この変数の設定に関する詳細は、設定方法を参照してください。

pg_stat_statements がインストールされており、datadog ユーザーがアクセスできることを確認するために、postgres データベースに接続して datadog ユーザーとしてクエリを試行します。少なくとも 1 つの行が正常に返されるはずです。例えば、以下のようになります。

psql -h localhost -U datadog -d postgres -c "select * from pg_stat_statements LIMIT 1;"

Agent のコンフィギュレーションでデフォルト postgres 以外の dbname を指定した場合は、そのデータベースで CREATE EXTENSION pg_stat_statements を実行する必要があります。

ターゲットデータベースで拡張機能を作成してもこの警告が表示される場合は、拡張機能が datadog ユーザーがアクセスできないスキーマで作成された可能性があります。これを確認するには、このコマンドを実行して pg_stat_statements がどのスキーマで作成されたかを確認します。

psql -h localhost -U datadog -d postgres -c "select nspname from pg_extension, pg_namespace where extname = 'pg_stat_statements' and pg_extension.extnamespace = pg_namespace.oid;"

次に、このコマンドを実行して、datadog ユーザーがどのスキーマを見ることができるかを確認します。

psql -h localhost -U datadog -d <your_database> -c "show search_path;"

もし、pg_stat_statements スキーマが datadog ユーザーの search_path にない場合は、datadog ユーザーに追加する必要があります。例:

ALTER ROLE datadog SET search_path = "$user",public,schema_with_pg_stat_statements;

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

いくつかのクエリからデータを取得したが、Database Monitoring で特定のクエリまたはクエリのセットが表示されない場合は、次のガイドに従ってください。

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

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

Postgres の設定 track_activity_query_size は、Postgres が保存し、Agent に対して表示する SQL 文の最大サイズを示します。デフォルトでは、この値は 1024 バイトです。この値を 4096 まで上げると、ほとんどのワークロードのクエリをキャプチャすることができます。しかし、クエリが複雑であったり、長い配列を使用する場合はより高い値が適切となる可能性があります。

例えば、以下のような項目数の多い配列を持つクエリは、データベースでは切り捨てられます。

SELECT DISTINCT address FROM customers WHERE id = ANY(ARRAY[11, 12, 13, ... , 9999, 10000 ]) LIMIT 5

正規化されたクエリは、アプリ内で次のように表示されます。

SELECT DISTINCT address FROM customers WHERE id = ANY(ARRAY[ ?

これを避けるために、クエリの予想される最大のテキストサイズに対応できるよう、track_activity_query_size の設定値を大きくしてください。詳細は、ランタイム統計についての Postgres ドキュメントを参照してください。

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

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

実行関数の欠落

問題: Agent が、データベースの datadog スキーマで必要な関数を実行できない。

解決方法: Agent は、datadog.explain_statement(...) 関数が、Agent がクエリを収集できるすべてのデータベースに存在することを必要とします。

Agent が実行計画を収集できるように、すべてのデータベースに関数を作成します。

CREATE OR REPLACE FUNCTION datadog.explain_statement(
   l_query TEXT,
   OUT explain JSON
)
RETURNS SETOF JSON AS
$$
DECLARE
curs REFCURSOR;
plan JSON;

BEGIN
   OPEN curs FOR EXECUTE pg_catalog.concat('EXPLAIN (FORMAT JSON) ', l_query);
   FETCH curs INTO plan;
   CLOSE curs;
   RETURN QUERY SELECT plan;
END;
$$
LANGUAGE 'plpgsql'
RETURNS NULL ON NULL INPUT
SECURITY DEFINER;

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

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

クエリが切り捨てられる。

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

Postgres 拡張クエリプロトコル

クライアントが Postgres 拡張クエリプロトコルまたはプリペアドステートメントを使用している場合、パースされたクエリと生のバインドパラメーターが分離されているため、Datadog Agent は説明プランを収集することができません。以下は、この問題に対処するためのいくつかの選択肢です。

Postgres バージョン 12 以降の場合、Postgres インテグレーション構成で以下のベータ機能を有効にします。

query_samples:
  explain_parameterized_queries: true
  ...

Postgres 12 より前のバージョンでは、この機能はサポートされていません。ただし、クライアントがシンプルクエリプロトコルを強制的に使用するオプションを提供している場合、Datadog Agent は実行プランを収集することが可能です。

クエリが Agent インスタンスの構成で無視されるデータベースにある

Agent インスタンスの構成 ignore_databases が無視するデータベース内にクエリが存在します。rdsadmin や azure_maintenance データベースなどのデフォルトのデータベースは、ignore_databases 設定では無視されます。これらのデータベースのクエリにはサンプルや実行計画がありません。インスタンス構成での設定値と、サンプルコンフィギュレーションファイルのデフォルト値を確認してください。

注: Agent バージョン <7.41.0 では、postgres データベースもデフォルトで無視されます。

クエリが実行されない

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

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

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

アプリケーションは、どのスキーマに問い合わせるかを指定するために、検索パスに依存している

Postgres は、pg_stat_activity で現在の検索パスを公開しないため、Datadog Agent は、アクティブな Postgres プロセスで使用されている検索パスを確認することができません。この制限を回避するには、Postgres インテグレーションで定義されたユーザーの検索パスを変更して、スキーマを含めるようにします。

ALTER ROLE datadog SET search_path = "$user",public,schema1,schema2,etc;

create extension pg_stat_statements のセットアップの失敗

create extension pg_stat_statements からの出力エラー例:

create extension pg_stat_statements;
ERROR:  could not open extension control file "<path>/share/postgresql/extension/pg_stat_statements.control": No such file or directory
SQL State: 58P01

このエラーは、pg_stat_statements 拡張機能を含む postgresql-contrib パッケージがない場合に発生します。不足パッケージのインストール方法は、ホストの分布および Postgres のバージョンにより異なります。一例として、Ubuntu で Postgres 10 の contrib パッケージをインストールするには、以下を実行します。

sudo apt-get install postgresql-contrib-10

詳細については、Postgres contrib ドキュメントの適切なバージョンを参照してください。

Agent からのクエリが遅い、またはデータベースへの影響が大きい

データベースモニタリングのデフォルトの Agent コンフィギュレーションは保守的ですが、収集間隔やクエリのサンプリングレートなどの設定を調整することで、よりニーズに合ったものにすることができます。ワークロードの大半において、Agent はデータベース上のクエリ実行時間の 1 % 未満、および CPU の 1 % 未満を占めています。Agent クエリがより多くのリソースを必要とする理由として、以下が考えられます。

pg_stat_statements.max の値が大きい

pg_stat_statements.max の推奨値は 10000 です。この構成を高い値に設定すると、収集クエリの実行に時間がかかり、クエリのタイムアウトやクエリメトリクスの収集のギャップにつながる可能性があります。Agent がこの警告を表示した場合は、データベースで pg_stat_statements.max が 10000 に設定されていることを確認します。