メインコンテンツへスキップ
ランタンホーム

Splunk Lantern

OpenTelemetry による Postgres のモニタリング

  1. 最後の更新
  2. PDFとして保存

この記事では、オープンソースのリレーショナルデータベースの監視について説明します。 PostgreSQL 。PostgreSQL は、そのスケーラビリティ、拡張性、サポートにより、エンタープライズアプリケーションで広く使用されています。これにより、内部サーバのアクティビティに関する広範な統計情報が得られます。 統計コレクター 。このガイドでは、以下を使用してこれらの統計情報を活用しています。 OpenTelemetry コレクター のデータベースとインフラストラクチャの監視に焦点を当てています Splunk Observability Cloud 。さらに、データベースのパフォーマンスがアプリケーションのパフォーマンスデータにどのように関連しているかも調べています。

ステップ 1: 重要な指標を特定する

データベースメトリクスの監視は、パフォーマンスの問題の特定、クエリの最適化、およびデータベースの信頼性の確保に不可欠です。PostgreSQL は大量のメトリクスを生成するため、次のような運用上の主要なメトリクスに焦点を当てることが重要です。

  • クエリのパフォーマンス: クエリのスループット/レイテンシー、ロック、クエリエラー、インデックスヒット率。
  • リソース使用率: 接続、CPU、メモリ、ディスク容量、テーブル/インデックスサイズ、ディスク I/O、キャッシュヒット。
  • データベースヘルス: レプリケーションラグ、デッドロック、ロールバック、自動バキュームのパフォーマンス。

クエリのパフォーマンス

低速でリソースを大量に消費するクエリや高スループットのクエリは、アプリケーションの応答時間を短縮し、ユーザーエクスペリエンスを低下させる可能性があります。ページの読み込み時間が遅くなるなどの問題を防ぐには、合計応答時間、1 秒あたりのインデックススキャン数、データベース待ち時間など、クエリ時間に関連する指標に焦点を当てる必要があります。これらのメトリクスは、データベースに正しいインデックスがあるか間違っているか、インデックスがないか、テーブルが断片化されているか、ロックが多すぎるかなどの問題を示します。

リソース使用率

リソースの閾値を超えると、アプリケーションの動作が完全に停止する可能性があります。アクティブな接続の総数が多すぎると、リソースが使い果たされ、ユーザーがアプリケーションをまったく操作できなくなる可能性があります。CPU、メモリ、テーブル/インデックスのサイズなどのリソース使用量を監視することで、データベースを稼働させ続けることができると同時に、正確なキャパシティプランニングと最適なユーザーエクスペリエンスを実現できます。

データベースヘルス

ロールバックからコミットまでの頻度が高いなどの状況は、ユーザーエクスペリエンスに問題がある可能性があります。たとえば、ユーザーが E コマースサイトで商品のチェックアウトを完了できない場合があります。デッドローの数が増えると、クエリのパフォーマンスが低下したり、リソースが枯渇したりして、同様の影響が生じる可能性があります。これらの指標を積極的に監視することで、非効率性を特定し、ボトルネックを解消し、データベースの肥大化を抑え、最終的にはユーザーエクスペリエンスを向上させることができます。

ステップ 2: OpenTelemetry コレクターを使用して PostgreSQL メトリクスを収集する

PostgreSQL メトリクスを収集してエクスポートするには、次の手順に従います。

OpenTelemetry コレクターをインストールします。

  1. をダウンロードしてインストールします。 [テレメトリコレクター] を開きます。 。
  2. の場合 Splunk Distribution of the OpenTelemetry Collector 、以下に従ってください。 ガイド付きインストール手順 。
  3. 使用 ドッカー・コンポーズ PostgreSQL と OpenTelemetry Collector をデプロイするため。

clipboard_eec458e20cb745aff88b6d474c5a396a4.png

OpenTelemetry コレクターの設定

  1. 既存の設定で以下の設定を行います。 テレメトリコレクター設定ファイルを開きます。 または、空のファイルを作成してください otel-collector-config.yaml まだ持っていない場合はファイル。
    1. を追加 ポスグレ SQL レシーバー その下に receivers ブロック。
    2. データを送信するエクスポーターの定義 Splunk Observability Cloud 。
    3. 受取人と輸出者がサービスパイプラインに含まれていることを確認してください。

clipboard_ef352de311913a138239c34d6fca65a9c.png

一般に、データベースとマイクロサービスはネットワークと API のセキュリティレイヤーの背後に配置されるため、データベースとサービスは暗号化されずに相互に通信します。これが、この例ではそのためです。 tls はに設定されています。 insecure: true 。データベースで認証された接続が必要な場合は、以下に示されているような証明書を提供する必要があります。 設定例 。

最後に、サービスをビルド、起動、または再起動します (以下を使用できます)。 docker compose up --build そのためには、データベースのメトリクスが流れ込むのを観察してください Splunk Observability Cloud 。

ステップ 3: での PostgreSQL データのビジュアライゼーション Splunk Observability Cloud

メトリクスが収集されたら、で表示できます。 Splunk Observability Cloud :

データベースメトリクスの分析

  1. に移動します。 データストア のセクション Splunk Infrastructure Monitoring 。
  2. 選択 PostgreSQL データベース データベースレベルのメトリクスの場合、または PostgreSQL ホスト PostgreSQL データベースをホストしているインフラストラクチャーに関連するメトリクス用。

    clipboard_ebcb620aa4cbcce2a3483d46dc53e6e32.png

  3. を開きます PostgreSQL データベースナビゲーターです。 すべてのデータベースに関連するメトリクスを表示できます。

    clipboard_ea30205debde5ec24b2905a8fb9a930e5.png

  4. 合計操作数、1 秒あたりのインデックススキャン数、ロールバックなどの主要な指標を確認します。総操作数が多い場合は、データベースリソースが現在のワークロード強度を処理できるかどうかが一目でわかります。1 秒あたりのインデックススキャン数が減少した場合は、インデックスを効率的に使用していない可能性があります。ロールバックの回数が多いデータベースでは、トランザクションの失敗やデッドロックが増加する可能性があります。これらすべての問題により、ユーザーのパフォーマンスが低下したり、信頼性が低下したりする可能性があります。

    clipboard_ee709bfe34e74bc1296e9a40da711bdfe.png

  5. データベースをクリックすると、データベース固有のメトリックが表示されます。インデックスのサイズを監視することで、リソースを効率的に最適化し、インデックスのサイズを適切に設定できます。デッドローの監視により、効率的なバキュームが可能になり、テーブルの肥大化が抑えられ、パフォーマンスが向上します。1 秒あたりの合計操作数は 18 で、1 秒あたりのインデックススキャンは 0 回というメトリクスが表示される場合は、インデックスを作成しておらず、クエリのパフォーマンスがいくらか非効率になっている可能性があります。

    clipboard_e4fc4bafbe9428f374ecf52677ea28abb.png

  6. システムが現在のワークロードを処理し、一貫したパフォーマンスを維持できるようにするには、以下をクリックしてください PostgreSQL ホストナビゲーター 1 秒あたりの操作数の変化、トランザクション、ディスク使用量などのメトリックを表示します。

    clipboard_e5939f928350690566e847e2f063ceded.png clipboard_e4d014a4c1005ffbfa41efe318be03aee.png

  7. また、特定のホストをクリックして、成功、失敗、ロールバックされたトランザクションの数、キャッシュヒット数とディスクヒット数などの個々のホストメトリクスを表示することもできます。これらはすべて全体的なパフォーマンスに影響します。

    clipboard_e0e39f10d33aa16a8f29cfa6aa1db057f.png

ステップ 4: APM のクエリパフォーマンスを調査する

データベース監視の取り組みは、ほとんどの場合、サービスレベルから、またはそれをサポートするアプリケーションから始まります。そこで、クエリのパフォーマンスと、それがアプリケーション全体のパフォーマンスに与える影響を確認する方法を見てみましょう。クエリのパフォーマンスを分析するには:

  1. から PostgreSQL ホストナビゲーターです。 で、ホストを選択します。
  2. ログを表示または 関連コンテンツ に Splunk Application Performance Monitoring 現在選択されているホストに依存しているサービスを表示できます。

    clipboard_e07ae401040105d8343ea968e58c92ca1.png

  3. に移動 データベースクエリのパフォーマンス クエリ時間、レイテンシー、エラーを表示および分析して、どの領域が応答時間とユーザーエクスペリエンスに影響を与えているかを確認し、クエリパフォーマンスを最適化できる領域を特定します。

    clipboard_e5d3a1f240ef1a4d2ff9c7adff43f39e3.png

  4. に移動します サービスマップ 特定のエラー、トレース、または関連ログを調査するため。

    clipboard_ec983dd9dfba98b281727960b96d22017.png clipboard_e90d67dfb329280d4924d62c735b07973.png

この例では、から移動しました Splunk Infrastructure Monitoring へ Splunk Application Performance Monitoring ただし、サービスマップから始めて、そこからデータベースクエリパフォーマンス、データベースリクエスト/エラー、またはトレースを使用してデータベースパフォーマンスの問題のトラブルシューティングを開始するのも同じくらい簡単でした。

次のステップ

アプリケーションを動かすデータベースの主要メトリクスを監視することは、ユーザーが信頼するパフォーマンスと信頼性にとって重要です。PostgreSQL テレメトリデータを受信し、そのデータをバックエンドのオブザーバビリティプラットフォームにエクスポートするように OpenTelemetry Collector を設定するのは簡単なプロセスで、サービスを支えるデータベースを非常に可視化できます。

以下のリソースは、このガイダンスの理解と実装に役立つ場合があります。