カスタムHTTP配信

カスタム HTTP アラート配信メソッド (つまり、Webhook) を使用すると、HTTP GET または POST リクエストを介して外部システムにアラート通知データを送信できます。 カスタム電子メール アラート配信と同様に、これは、チケット発行システムにアラート通知を送信する場合に有利です。 カスタム HTTP アラート配信では、トークン (変数) を使用してアラート通知データの正確な形式を定義できるため、受信側システムで簡単に解析できます。

通常、カスタム HTTP 配信メソッドは HTTP POST を作成し、リクエスト ペイロードでアラート通知データを配信します。 ただし、場合によっては、リクエスト自体にフォーム データが URL に追加されているため、HTTP GET リクエストで十分な場合があります (たとえば、 https://www.example.com/api?param1=abc&m2=def)、ペイロードをポストする必要はありません。

カスタムアラート配信方法を定義するだけで、   その結果、通知はカスタム配信方法を介してルーティングされます。 カスタム配信方法は、受信者の連絡方法として含める必要があります エスカレーションチェーン、およびそのエスカレーションチェーンは、 アラートルール。 これらを構成する場合、ターゲット統合でアラート データが期待どおりにポストおよび更新されるようにするために、従うべきガイドラインがいくつかあります。 詳細については、「」を参照してください。 アラートルール.

カスタム HTTP 配信統合の追加

1. LogicMonitorで、次の場所に移動します 設定 > 統合。
2. 選択 統合の追加.
3. ノーザンダイバー社の 統合の追加 ページ、下 ワークフローの統合選択 カスタムHTTP配信.
   

4. 入力します 名前  & 説明 カスタム HTTP 配信統合の場合。
   　 名前  フィールドは必須であり、名前に入力した値は統合のリストに表示されます。
5. 現在地に最も近い アラート通知 必要なオプション:
   • 同じ URL とデータを使用してさまざまなアラート アクティビティを通知します – アラート アクティビティの HTTP リクエストを、新しいアラートの最初の HTTP リクエストが送信されたのと同じ URL に送信します。
   • さまざまなアラートアクティビティを通知するために、異なるURLまたはデータ形式を使用します – アラート アクティビティに基づいて、HTTP リクエストをさまざまな URL に送信します。
6. 次のいずれかを選択します アラートステータス 通知を送信したい内容。 デフォルトでは、リクエストは次のように送信されます。 新しいアラート.
   • 認められた: この状態は、以前に生成され、確認されたアラートを処理するための状態です。
   • クリアされた: この状態は、アラートをトリガーしたアラートしきい値を満たすアラートに対するものです。
   • エスカレーション/デエスカレーション: この状態は、アラートの重大度が増加または減少しているアクティブなアラートの状態です。 たとえば、警告からエラー、またはクリティカルからエラーに更新されるアラートでは、この定義が使用されます。 エスカレートされたステータスが選択され、メモがアラートに追加された場合、アラートがアクティブかクリアかに関係なく、更新リクエストが送信されます。 エスカレートされたステータスが選択されておらず、メモがアラートに追加されている場合、リクエストは送信されません。

7. 顧客ヘッダーを追加したい場合は、 カスタムヘッダーを使用する 切り替えて、次の操作を行います。
   1. 選択 レコードを追加 次に値を入力します キー & 値.
   2. 選択 申し込む.

8.  HTTPメソッド フィールドで、必要な方法を選択します。 選択できます HTTPポスト or HTTP 取得 方法。
9.  URL フィールドに、HTTP リクエストの URL を入力します。
10. 提供する   & パスワード  指定されたユーザー名に関連付けられています。
11. を使用して認証するには 基本認証、 入る   & パスワード 。 HTTP 基本認証は、ユーザー名とパスワードを HTTP ヘッダー内のフィールドとして渡します。
12. OAuth 2.0 を使用して認証するには、次を選択します。 OAuth 2.0、選択 交付金の種類 次の情報を希望し、提供します。
    • 選択した場合 助成金の種類 as client_credentials、次のフィールドに情報を入力します。
      • アクセストークンURL –  資格情報を検証し、clientId と clientSecret が有効な場合にアクセス トークンを返す認証サーバー エンドポイント。
      • クライアントID - OAuth アプリケーションのクライアント ID
      • クライアントシークレット – OAuth アプリケーションのクライアント シークレット
      • スコープ – アクセス要求の範囲
    • 選択した場合 助成金の種類 as password、次のフィールドに情報を入力します。
      • 顧客ID – OAuth アプリケーションのクライアント ID
      • クライアントシークレット – OAuth アプリケーションのクライアント シークレット
      • ユーザー名とパスワード – 指定されたユーザー名に関連付けられたユーザー名とパスワード
      • 対象領域 – アクセス要求の範囲。
13.  アラートデータ、キーと値のペアまたは生の形式を選択して、アラート メッセージをカスタマイズします。
    • 選択 キー/値 ペア選択 レコードを追加、キーを提供します 名前  & 値、次に選択 申し込む.
    • 選択 Raw選択 トークンの挿入、アラート メッセージに必要なトークンを含めます。 次のトークンが利用可能です。
      • ##ADMIN## – アラートがエスカレーションされたユーザー。
      • ##ADMIN.PHONE## – 管理者の電話番号。
      • ##ADMIN.EMAIL## – 管理者の電子メール ID。
      • ##ADMIN.PAGER## – 管理者のポケットベル番号。
      • ##ALERTTYPE## – アラートのタイプ (つまり、alert、eventAlert、batchJobAlert、hostClusterAlert、websiteAlert、agentDownAlert、agentFailoverAlert、agentFailBackAlert、alertThrottledAlert)。
      • ##ALERTSTATUS## – アラートのステータス。
      • ##MESSAGE## – 警告メッセージのレンダリングされたテキスト。 このトークンは、関連するすべての確認済み情報 (たとえば、アラートを確認したユーザー、確認済みのコメントなど) も渡します。
      • ##ALERTID## – アラートの ID。
      • ##EXTERNALTICKETID## – これは、統合によって作成されるチケットの外部システムの識別子をキャプチャし、LogicMonitor がそのチケットに対する今後のアクションでそれを参照できるようにします。
        詳細については、を参照してください。 LogicModuleアラートメッセージで使用可能なトークン.

14. トグル アラートステータスを更新するときに、HTTP応答で提供されるIDを含めます 新しいアラートに関連付けられた HTTP リクエストに応答して返された ID (チケット ID など) を LogicMonitor で検索する場合にスイッチします。 応答形式は、JSON、正規表現、または XML にすることができます。 LogicMonitor は、確認、クリア、エスカレーション/エスカレート解除されるアラートに対する後続のリクエストでこの ID を使用します。
15. 選択 アラート配信のテスト テスト アラートとメッセージを送信し、統合が正しく構成されているかどうかを確認します。
16. 選択 インポート 統合の詳細を JSON 形式でインポートする場合。
17. 選択 Save カスタム HTTP 統合を保存します。
18. 統合をキャンセルしたい場合は、 キャンセル.