AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

メトリクスをOpenTelemetry (OTel) に送信する

MongoDB Ops Managerは、MongoDB Agentによって収集された配置メトリクスをOpenTelemetry (OTel) 形式でサードパーティの可観測性バックエンドに出力できます。その間も、MongoDB Ops Managerはこれらのメトリクスを受信し続けます。この機能により、MongoDBの配置を既存の可観測性スタックや、OpenTelemetry プロトコル (OTLP) を受け入れるその他のプラットフォームに統合できます。カスタムパイプライン、サイドカープロセス、追加のコレクションエージェントは必要ありません。

OTel エクスポートは追加型であり、デフォルトでは無効にされています。MongoDB Ops Manager へのメトリクス配信はまったく変更されません。すべてのシグナルは変更されず、既存の MongoDB Ops Manager パス上で引き続き運ばれます。OTel エクスポート パス上の接続できないエンドポイントとなる接続されたデバイスなどのあらゆる障害は分離されるため、MongoDB Ops Manager へのレポート作成が中断されることはありません。

この機能を有効にすると、MongoDB Agent は設定可能な間隔(デフォルトは 30 秒)で、設定されたエンドポイントとなる接続されたデバイスに OTLP/HTTP 経由でメトリクスをプッシュします。各サイクルでは、モニターされたプロセスごとに 1 つの OTLP リクエストと、エージェント自身の自己正常性に関する 1 つのリクエストが送信されるため、バックエンドは 1 つの大きなバッチするではなく、間隔ごとにいくつかの小さなリクエストを受け取ります。エンドポイントとなる接続されたデバイスは、次のいずれかになります。

  • OpenTelemetry Collector。メトリクスを処理し、複数の宛先にルーティングできます。

  • OTLPをネイティブで受け入れるオブザーバビリティプラットフォーム(例:DataDog、Grafana、Dynatrace)。

この機能は、オートメーション構成 を介して設定します。MongoDB Agent は、既存のコレクションサイクルでエクスポートされたメトリクスを収集するため、この機能はモニター対象の MongoDB プロセスに余計な負荷をかけません。

OTelエクスポートパスは、既存のPrometheus統合のドロップイン置換ではありません。Prometheus統合はプルベースであり、MongoDB AgentはPrometheusサーバーがスクレイピングする/metricsエンドポイントとなる接続されたデバイスを公開します。OTelパスはプッシュベースであり、MongoDB Agentはタイマーで構成されたOTLPエンドポイントとなる接続されたデバイスにメトリクスを送信します。

OTelメトリクスは、MongoDBのOpenTelemetryセマンティック規則に従う異なる名前、型、単位も使用するため、既存のPrometheusダッシュボードを再利用することはできません。エクスポートされたメトリクスに対して、ターゲットの可観測性プラットフォームで新しいダッシュボード、アラート、クエリを作成する必要があります。

OTelエクスポートを構成する前に、以下の要件を満たしていることを確認してください。

  • OTel エクスポートを構成する前に、配置のモニタリングを有効にする必要があります。OTel エクスポートは、MongoDB Agent がモニタリング用にすでに収集しているサンプルを再利用します。MongoDB Agent のインストール方法とモニタリングの有効化について学ぶには、MongoDB Agent をインストールして配置をモニターまたはバックアップする。 を参照してください。

  • MongoDB Agentが実行されるすべてのホストする場所からOTLPエンドポイントとなる接続されたデバイスに到達できることを確認してください。MongoDB Agentは、メトリクスをエンドポイントとなる接続されたデバイスに直接プッシュします。この機能を有効にする前に、ファイアウォールルールとエグレスポリシーを確認してください。

  • Project Automation AdminOps Manager API を介してオートメーション構成を更新するための アクセスを持っていることを確認します。プロジェクト ロールについて詳しく学ぶには、MongoDB Ops Manager ロール を参照してください。オートメーション構成 API について学ぶには、オートメーション構成リソース を参照してください。

  • OTLPエンドポイントとなる接続されたデバイスが、レシーバープロトコルとしてOTLP/HTTPをサポートしていることを確認してください。OTLP/HTTPレシーバーの設定方法について学ぶには、OpenTelemetry プロトコル仕様を参照してください。

OTel export は、オートメーション構成 を使用して構成します。すべての設定は、モニタリング モジュールの additionalParams の下の 1 つの otelConfig キーに保存されます。MongoDB Ops Manager インターフェース内の既存のカスタム設定フローを使用して、この設定を適用できます。詳細は、カスタム設定に記述されています。この構成は、公開のオートメーション構成APIを介して適用することもできます。

次の例は、OTel エクスポートを有効にする additionalParams エントリを示しています。

"additionalParams": { "otelConfig": "{\"enabled\":true,\"metricsExportIntervalSec\":30,\"backends\":[{\"endpoint\":\"https://collector.example.com:4318\",\"headers\":\"Authorization=Bearer <token>\",\"caCertPath\":\"/etc/ssl/ca.pem\"}]}"}

otelConfig フィールドの全リストについては、「OpenTelemetry (OTel) エクスポート設定」を参照してください。

重要

otelConfig の設定が正しくないと、警告なしに無視されるのではなく、明確なエラーが発生します。設定が無効な場合、MongoDB Agentはモニタリングモジュールの起動を阻止します。MongoDB Agentは、有効な設定を受信するまで30秒ごとに設定を再試行します。したがって、無効なotelConfigはOTelパスだけでなく、モニタリング全体に影響します。エージェントは、この障害をOtel:プレフィックスでログに記録し、MongoDB Ops Managerへのエージェントのステータスレポート作成に表示します。

構成の変更は、次回モニタリングモジュールが再起動したときに有効になります。関連するオートメーション構成のプロパティを変更すると、MongoDB Ops Managerは自動的にこの再起動をトリガーします。

警告

http:// エンドポイントとなる接続されたデバイスを構成した場合、MongoDB Agent は暗号化されていない接続経由でメトリクスを送信します。MongoDB Ops Manager は、エンドポイントとなる接続されたデバイスが本番環境の宛先であるかどうかを検出できないため、本番環境での安全でないエクスポートを防ぐガードレールはありません。本番環境の配置には https:// エンドポイントとなる接続されたデバイスを使用してください。

MongoDB Controllers for Kubernetes (MCK)によってマネージドされる配置の場合、OTelエクスポートは同じオートメーション構成メカニズムを使用します。演算子はオートメーション構成を維持します。演算子は、カスタムリソースの更新を通じて、OTel設定をエージェントホストに書き込み (write)ます。Kubernetes固有の構成は別途必要ありません。

この機能は、次の表のメトリクスグループをOTLP経由でエクスポートします。メトリクスの名前、タイプ、および単位は、MongoDBのOpenTelemetryセマンティック規則に従い、コンシステントmongodb.*命名パスワードなしを使用します。

メトリクスグループ
ソース
カバレッジ

Server status

serverStatus

操作カウンター(レプリケートされたものを含む)、操作レイテンシ、接続、メモリ、ネットワーク、カーソル、挿入、更新、削除する、返されたドキュメント、WiredTigerキャッシュ統計、チケットとキューの深さ、ロックの取得、待機、デッドロックの数、アクティブな読み取りと書き込み (write)、アサート、フロー制御、クエリのターゲット設定、Time-to-Live (TTL) 削除する、ページフォールト、稼働時間、および正常性。

データベース統計

dbStats

データベースごとのストレージ、データサイズ、オブジェクト、インデックス、およびビューの統計。

コレクションのアクティビティ

top

操作ごとの集計時間。

複製

replSetGetStatus およびoplog

oplogのサイズとウィンドウ、レプリケーションラグ、ノードの健全性。

シャーディング

Config metadata

シャード間のチャンク数とデータ分散。

エージェントの自己健全性

エージェントランタイム

MongoDB Agentの稼働時間、メモリ、goroutine。専用のmongodb.mms.*名前空間で公開されます。

この機能は、カウンターメトリクスを累積値としてエクスポートします。開始タイムスタンプはmongodのアップタイムから取得されます。mongodの再起動は標準的なカウンターリセットとして表示されるため、再起動後もレート計算は正確に維持されます。

  • MongoDB Agentは、プロセスが一時的に到達不能な間、カウンターシリーズをそのまま再エクスポートするため、コレクションのギャップがカウンターのリセットとして誤読されることはありません。

  • MongoDB Agentは、mongodb.healthなどの時系列データを最新の状態である場合にのみエクスポートします。そのため、到達不能なプロセスは古い値を保持するのではなく、サイレント状態になります。

  • MongoDB Agentは、新しいサンプルがないまま20分が経過するとシリーズを削除し、そのシリーズはバックエンドから消去されます。データ欠落に基づいてアラートをビルドする際は、この動作を考慮してください。

エクスポートされたメトリクスに対して、ターゲットのオブザーバビリティプラットフォームで新しいダッシュボードを作成する必要があります。MongoDB Ops Managerには事前にビルドされたダッシュボードは付属していません。また、Prometheus統合、MongoDB Ops Managerインターフェース、またはその他のサードパーティ製MongoDB統合用に作成された既存のダッシュボードを再利用することもできません。

ダッシュボードを設定する際は、このガイダンスを考慮してください。

  • 既存のダッシュボードを移行するのではなく、新しいダッシュボードを作成してください。OTLP経由で出力されるメトリクス名は、Prometheusエクスポーターの名前やMongoDB Ops Managerの内部メトリクス識別子とは異なるmongodb.*命名規則に従います。

  • リソース属性を使用して、フィルターやグループ化を行います。すべてのメトリクスには、モニター対象のプロセスとプロジェクトを識別するリソース属性が含まれています。これらの属性を、ダッシュボードパネル、アラート、グループ化のプライマリディメンションとして使用します。

  • カウンターメトリクスにレート関数を適用します。カウンターは累積的です。rate() や increase() などの関数、またはプラットフォーム上の同等の関数をカウンタータイプのメトリクスに適用します。

  • アラートを再作成します。OTelエクスポートでは、Prometheus、MongoDB Ops Manager、またはその他のサードパーティ統合で定義された既存のアラートルールは引き継がれません。OTelメトリクス名とリソース属性に対して、ターゲットプラットフォームで新しいアラートルールを定義します。

  • 配置ごとに1つのバックエンド。この機能は、正確に1つのOTLPバックエンドをサポートします。複数のバックエンドを構成すると、ハードエラーが発生します。メトリクスを複数の送信先に展開するには、OpenTelemetry Collectorをエクスポートターゲットとして構成し、そのパイプライン構成を通じてより多くのバックエンドにルーティングします。

  • メトリクスのみ。この機能は、OTLP経由でメトリクスのみをエクスポートします。OTelエクスポートパスには、MongoDB Ops Managerに引き続き変更なしで送信される以下のシグナルは含まれません。

    • ログ(プロファイラーエントリ、ホストログ、エージェントログ)とトレース

    • MongoDB Search プロセス メトリクス

    • ホストレベルのシステムメトリクス(CPU、メモリ、ディスク、ネットワーク)

    • コレクションごとのレイテンシ ヒストグラム

  • 到達不可能な宛先に対するバッファリングはありません。MongoDB Agentは、エクスポーターのポリシーに従って、失敗したエクスポートを再試行または削除します。この機能には、ストアアンドフォワードキューはありません。MongoDB Ops Managerへの配信は、すべての場合において影響を受けません。