MongoDB Ops Manager を構成すると、アラート通知を Webhook エンドポイントとなる接続されたデバイスに HTTP 書き込みリクエストとして送信し、プログラムによるプロセシングを行うことができます。Webhooks により、MongoDB Ops Manager のアラートをカスタムモニタリングシステム、インシデントマネジメントプラットフォーム、またはオートメーションワークフローと統合することができます。
必要なアクセス権
MongoDB Ops Manager を Webhook と統合するには、プロジェクトの Project Monitoring Admin アクセス権が必要です。
Webhook リクエストの認証
Webhookリクエストは、以下の方法で認証できます。
Webhook secret: MongoDB Ops Managerは、このシークレットを使用して
X-MMS-Signatureヘッダーを生成します。MongoDB Ops Managerは、シークレット自体を認証ヘッダーやBearer tokenとして送信しません。署名の検証方法を学ぶには、Webhookリクエストの検証を参照してください。OAuth 2.0 クライアント認証情報: MongoDB Ops Manager は、OAuth 2.0 トークンエンドポイントとなる接続されたデバイスからベアラーアクセストークンを取得し、それを
Authorizationヘッダーで送信します。このメソッドを構成するには、Webhook 統合の構成を参照してください。
いずれか一方、両方、またはどちらも使用しないことができます。両方を構成した場合、MongoDB Ops Manager は同じリクエストに Authorization ヘッダーと X-MMS-Signature ヘッダーの両方を含めます。
MongoDB Ops ManagerはOAuth 2.0アクセストークンをキャッシュし、トークンの有効期限が切れると更新します。Webhookエンドポイントとなる接続されたデバイスが401レスポンスを返した場合、MongoDB Ops Managerはトークンを更新し、リクエストを1回再試行します。
カスタムヘッダーテンプレートの動作
カスタムヘッダーテンプレートを設定すると、リクエスト内のデフォルトヘッダーが置き換えられます。MongoDB Ops Managerは、X-MMS-SignatureまたはAuthorizationヘッダーを自動的に追加しません。いずれかのヘッダーを含めるには、テンプレートに追加します。
"X-MMS-Signature": "${signature}""Authorization": "Bearer ${oauthToken}"
Webhook テンプレートの詳細については、「Webhook テンプレートの構成」を参照してください。
その他の認証方法
WebhookシークレットやOAuth 2.0クライアントの認証情報が要件を満たさない場合は、以下のいずれかの方法で認証を取り扱うことができます。
クエリパラメータ: Webhook URLにクエリパラメータとして認証情報を含めます。例:
https://example.com/webhook?token=your-auth-tokenIP アクセス リスト: Webhook エンドポイントとなる接続されたデバイスが、MongoDB Ops Manager インスタンスの IP アドレスからのリクエストのみを受け入れるように設定します。
リバースプロキシまたはAPIゲートウェイ: リクエストを webhook エンドポイントとなる接続されたデバイスに転送する前に、認証を取り扱うリバースプロキシまたはAPIゲートウェイを使用します。
Webhook リクエストの確認
webhookリクエストがMongoDB Ops Managerから送信されたことを確認するには、X-MMS-Signatureヘッダーを検証します。
Webhook 統合の構成
認証を構成します。
以下の認証オプションのうち、少なくとも1つを入力してください。
Webhook Secretシークレットキーを入力します。MongoDB Ops Managerは、このシークレットを使用して、リクエスト検証用の
X-MMS-Signatureヘッダーを生成します。OAuth2 Token URL、OAuth2 Client ID、およびOAuth2 Client Secret：MongoDB Ops Managerがアクセストークンを取得するために呼び出すトークンエンドポイントとなる接続されたデバイスと、OAuth 2.0 プロバイダーに登録したアプリケーションの認証情報を入力します。3つの値をすべて設定するか、3つすべてを空のままにします。
両方のオプションを一緒に使用できます。詳細を学ぶには、「Webhookリクエストの認証」を参照してください。
アラートをWebhookに送信するには、アラート通知を構成します。詳細については、「Ops Manager でアラート設定を構成する」を参照してください。
リクエストヘッダー
Ops Manager は各 Webhook リクエストに以下の HTTP ヘッダーを含めます。
MongoDB Ops Manager は、さまざまなアラート状態を区別するためにX-MMS-Eventというリクエスト ヘッダーを追加します。 このヘッダーに指定できる値は次のとおりです。
| アラートは先ほど開かれています。 |
| アラートは解決されました。 |
| 以前に開かれたアラートはまだ開いています。 |
| アラートは確認されました。 |
| アラートは無効になり、キャンセルされました。 |
| 「プライマリ選択」など、特定の時点のイベントである情報アラートを表します。 |
「Webhook Secret」フィールドにキーを指定した場合、MongoDB Ops Manager は X-MMS-Signature リクエストヘッダーを追加します。このヘッダーには、リクエスト本文の Base64 エンコードされた HMAC-SHA-1 署名が含まれています。MongoDB Ops Manager は提供されたシークレットを用いて署名を生成します。
OAuth 2.0 クライアント認証情報を設定すると、MongoDB Ops Manager は Authorization リクエストヘッダーを追加します。このヘッダーには、MongoDB Ops Manager が OAuth 2.0 エンドポイントとなる接続されたデバイスから取得するベアラーアクセストークンが含まれています。
リクエスト本文
リクエスト ボディには、MongoDB Ops Manager API アラート リソース と同じ形式を使用する JSON ドキュメントが含まれています。ペイロードには、次のようなキーフィールドが含まれています。
id: アラートの一意の識別子です。eventTypeName: アラートをトリガーするイベントの種類。created: アラートが作成されたタイムスタンプ。status: アラートの現在のステータス（例:OPEN、CLOSED）。humanReadable: アラートの人間が判読可能な説明。
フィールドの完全なリストについては、Get One アラート エンドポイントとなる接続されたデバイスのドキュメントを参照してください。
例 Webhook ペイロード
次の例は、メトリクスしきい値アラートのサンプルWebhookペイロードを示しています。
{ "id": "5d1b6f8e8c2e4e2d3c4a5b6c", "groupId": "5d1b6f8e8c2e4e2d3c4a5b6d", "eventTypeName": "OUTSIDE_METRIC_THRESHOLD", "status": "OPEN", "created": "2024-01-15T10:30:00Z", "updated": "2024-01-15T10:30:00Z", "lastNotified": "2024-01-15T10:30:00Z", "humanReadable": "Disk space used on data partition is 95.2%.", "metricName": "DISK_PARTITION_SPACE_USED_DATA", "currentValue": { "number": 95.2, "units": "RAW" }}Webhookテンプレートのカスタマイズ
FreeMarker テンプレートを使用して、リクエストヘッダーと本文の内容をカスタマイズできます。使用可能なテンプレート変数、正規表現ヘルパー、例など、Webhook テンプレートの詳細については、Webhook テンプレートの構成 を参照してください。
制限
ウェブフック統合を使用する場合は、次の制約事項を考慮してください。
アラートの重要度は含まれません
Webhookペイロードには、MongoDB Ops Managerで構成したアラートの重大度レベルは含まれません。構成された重大度を検索するには、WebhookペイロードのalertConfigIdを使用して、Get One アラート Configurationエンドポイントとなる接続されたデバイスを呼び出します。
手動テストアラートなし
MongoDB Ops Managerには、テストアラートを手動でtriggerする方法はありません。Webhookエンドポイントとなる接続されたデバイスをテストするには、次のように、triggerできる条件を持つアラートを一時的に設定します。
テスト配置におけるディスク容量不足のしきい値。
複数の接続を開くことで trigger できる接続数のスレッショル。
テストレプリカセットにおけるレプリケーションラグのしきい値。
ウェブフックがアラートを正しく受信していることを確認した後、テスト アラート構成を削除できます。
ファイアウォール構成
Ops Manager はセルフホスト型であるため、ネットワークで Ops Manager サーバーから Webhook エンドポイントとなる接続されたデバイスへのアウトバウンド HTTP リクエストを許可していることを確認します。Webhook エンドポイントとなる接続されたデバイスがファイアウォールの背後にある場合は、MongoDB Ops Manager サーバーの IP アドレスをエンドポイントとなる接続されたデバイスの IP アクセス リストに追加します。
Webhook配信の問題のトラブルシューティング
ウェブフックがアラートを受信しない場合: