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

OpenTelemetry(OTel)へのメトリクスの送信

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

OTel のエクスポートは追加的であり、デフォルトで無効になっています 。 Ops Manager に提供されるメトリクスは変更されません。すべてのシグナルは既存の Ops Manager パスで変更されずに転送され続けます。エンドポイントに到達できないなど、OTel エクスポート パス上の障害は分離され、Ops Manager へのレポート作成は中断されません。

この機能を有効にすると、 MongoDB Agent は TLS/ HTTP経由で構成可能なケイデンス(デフォルトは 30 秒)の構成済みエンドポイントにメトリクスをプッシュします。各サイクルは、監視対象プロセスごとに 1 つの TLPリクエストに加えて、エージェント自体の正常性ごとに 1 つのリクエストを送信するため、バックエンドは大規模なバッチする1 件ではなく、間隔ごとに複数の小さなリクエストを受信します。エンドポイントは、次のいずれかになります。

  • メトリクスを処理し、それを複数の宛先にルーティングすることができる OpenTelemetry コレクター 。

  • TLP をネイティブに受け入れる観察プラットフォーム(、 Datadog、

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

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

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

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

オートメーション構成 を通じて OTel エクスポートを構成します。すべての設定は、モニタリングotelConfig モジュールの の下の単一のadditionalParams キーで行われます。この構成は、「 カスタム設定 」で説明されている、Ops Manager インターフェースの既存のカスタム構成フローを介して適用できます。この構成は、パブリック Automation Configuration APIを通じて適用することもできます。

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

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

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

重要

誤って構成された otelConfig は、暗黙で無視されるのではなく、大多数で失敗します。構成が無効な場合、 MongoDB Agent は監視モジュールの起動を防止します。 MongoDB Agent は有効な構成を受信するまで、30 秒ごとに構成を再試行します。したがって、無効な otelConfig は、OTel パスだけでなく、モニタリング全体に影響します。エージェントはこの障害を Otel: プレフィックスで記録し、Ops Manager に報告されるエージェントのステータスに表示します。

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

警告

http:// エンドポイントを構成すると、 MongoDB Agent は暗号化されていない接続を介してメトリクスを送信します。 Ops Manager はエンドポイントが本番環境の宛先であるかどうかを検出できないため、本番環境への安全なエクスポートを防ぐために保護されています。本番環境には https:// エンドポイントを使用します。

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

この機能は、次の表のメトリクス グループを TLP 経由でエクスポートします。メトリクス名、型、単位は、一貫した mongodb.* 命名パターンを使用して、 MongoDBの OpenTelemetry セマンティック規則 に従います。

メトリクス グループ
ソース
適用範囲

Server status

serverStatus

操作カウンター(複製、操作レイテンシ、接続、メモリ、ネットワーク、カーソル、挿入、更新、削除、返されたドキュメント、 WiredTigerキャッシュ統計、チケットとキューの深さ、ロック取得、待機、デッドロック カウント、アクティブな読み取りと書込み、アサート、フロー制御、クエリ ターゲティング、Time-to-Live(TTL)削除、ページ フォールト、アップタイム、ヘルス。

データベース統計

dbStats

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

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

top

操作ごとの集計時間。

複製

replSetGetStatus とoplog

oplog サイズとウィンドウ、レプリケーションラグ、 ノードのヘルス。

シャーディング

Config metadata

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

エージェントの自己整合性

エージェントの実行時間

MongoDB Agent のアップタイム、メモリ、ゴルーチンは専用の mongodb.mms.*名前空間で公開されます。

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

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

  • MongoDB Agent がエクスポートするのは、mongodb.health などのポイントインタイム系列であり、古い値を保持する代わりに、到達不能なプロセスはサイレントになります。

  • MongoDB Agent は 20 分後に新しいサンプルなしでシリーズを削除し、そのシリーズはバックエンドから消えます。欠落データに基づいてアラートを構築する場合は、この動作を考慮する必要があります。

エクスポートされたメトリクスに対して、ターゲット 可視性プラットフォームに新しいダッシュボードを作成する必要があります。 Ops Manager は事前に構築されたダッシュボードを出荷せず、Prometheus 統合、Ops Manager インターフェース、または別のサードパーティのMongoDB統合用に作成された既存のダッシュボードを再利用することはできません。

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

  • 既存のダッシュボードをポートする代わりに、新しいダッシュボードを作成します。 TLPmongodb.* 経由で出力されるメトリクス名は、Prometheus エクスポート元の名前および MongoDB Ops Manager の内部メトリクス識別子とは異なる、 の命名規則に従います。

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

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

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

  • 配置ごとに 1 つのバックエンド。この機能は 1 つの TTLバックエンドのみをサポートします。複数のバックエンドを構成するとハード エラーが発生します。メトリクスを多数の宛先に展開するには、OpenTelemetry コレクターをエクスポート ターゲットとして設定し、そのパイプライン構成を通じてさらに多くのバックエンドにルーティングします。

  • メトリクスのみ。この機能は、TLP 経由でメトリクスのみをエクスポートします。 OTel エクスポート パスには、次のシグナルは含まれておらず、変更されずに Ops Manager に残ります。

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

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

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

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

  • 到達不能な宛先のバッファリングはありません。 MongoDB Agent は、エクスポート元の ポリシー に従って、失敗したエクスポートを再試行または削除します。この機能では、保存して転送キューが存在しません。 Ops Manager への配信は、すべての場合に影響を受けません。