サポートセンターホーム


アラート統合の概要

アラート統合の概要

LogicMonitorは、ほとんどのチャットツール、チケットシステム、および社内で利用できるその他のサービスと連携するように作成できます。 これらのアラート統合により、LogicMonitorはサードパーティのコラボレーションツールと対話し、LogicMonitorアラートに基づいて、これらのツールでインシデントを開く、更新する、閉じるなどのアクティビティをサポートできます。

すぐに使用できるアラート統合

LogicMonitorアカウントには、次のすぐに使用できる統合が事前に構成されています。

カスタムアラート統合

LogicMonitorは、すぐに使用できる多数の統合に加えて、カスタム統合の作成もサポートしています。 通常、これらの統合は次を使用して実現されます カスタムHTTP配信(Webhook) or カスタムメール配信。 LogicMonitorのカスタムHTTP配信は、HTTP要求を介してアラートを外部システムおよびツールにルーティングし、応答からチケットIDまたはその他の一意の識別子を取得できます。 カスタム電子メール配信は、アカウントでトリガーされたアラートに応答して、カスタム形式のアラート通知を外部システムおよびツールに電子メールで送信します。 その他の場合、カスタム統合は LogicMonitor API or 外部アラート 機能を提供します。

アラート統合の作成

すべての新しい統合セットアップは、 設定| 統合| 追加、次に示すように。 すぐに使用できるアラート統合(Autotask、Slackなど)またはドキュメントを提供する一般的なカスタム統合(Campfire、Zendeskなど)の構成の詳細については、その統合タイプを参照してください。 個別サポート記事。 作成するアラート統合のドキュメントが存在しない場合は、いずれかを使用してカスタムアラート統合を作成する手順を確認してください。 カスタムHTTP配信(Webhook) or カスタムメール配信.

統合のリスト

アラート統合のためのアラートルール構成ガイドライン

アラートルールは、チケットを開いたり、更新したり、閉じたりする目的で、サードパーティアプリケーションにアラート通知をルーティングする役割を果たします。 このため、さまざまなアラートルール構成がアラート統合にどのように影響するかを理解することが重要です。 次に、アラート統合のアラートルールを構成する際のいくつかのベストプラクティスを文書化しました。

アラートルールの詳細については、を参照してください。 アラートルール.

アラートライフサイクルに単一のアラートルールを使用する

アラートルールをアラート統合に関連付ける場合、単一のアラートルールがアラートのライフサイクル全体を維持することが重要です。 言い換えると、アラートルールがエスカレーションチェーンの一部としてアラート統合への配信を参照する場合、そのルールはすべての潜在的なアラートレベルの重大度に一致するように構成する必要があります。 そうでない場合は、次のリスクがあります。

  • 統合ターゲットおよび/または統合ターゲットへの重複ペイロードの配信
  • 孤立したチケット(つまり、クリアされないチケット)

どうして? LogicMonitorがアラート情報をサードパーティの統合に配信する準備をするとき、ServiceNowチケットIDやPagerDuty参照IDなどの外部参照がそのアラートに配置されているかどうかを確認します。 これらの参照は、LogicMonitorのHTTP / S投稿への応答で統合ターゲットによって返されます。 LogicMonitorはこの参照をキャプチャし、アラートルールIDと統合IDで構成されるキーを使用してアラートに関連付け、それを使用して、そのアラートの今後のすべてのアクティビティを元のターゲット統合オブジェクト(チケットなど)に関連付けます。

アラートの外部参照が見つからない場合、「作成」ペイロードが統合ターゲットに送信され、その結果、新しいオブジェクトが作成されます。 外部参照が見つかった場合、「更新」ペイロードが統合ターゲットに送信され、既存のオブジェクトのステータスを何らかの方法で変更します(たとえば、アラートの重大度ステータスを更新するか、アラートがクリアまたは確認されたことを示します)。

LogicMonitorは外部参照をアラートルールIDを含むキーの組み合わせに関連付けるため、複数のアラートルールが関係している場合、チケットの重複や孤立が発生し、外部参照との接続が事実上切断される可能性があります。 たとえば、次のシナリオについて考えてみます。

アラートルールはクリティカルアラートと一致し、それをServiceNow統合に配信して、チケットを作成します。 アラートは後でLogicMonitor内の警告にエスカレート解除されます。これは、同じServiceNow統合にも配信される別のアラートルールに一致します。 ただし、XNUMX番目のアラートルールは最初のルールの結果として生成された外部チケットIDとは関係がないため、同じ問題に対してXNUMXつのチケットがServiceNowに存在します(最初のチケットはクリティカルアラートの結果として作成され、XNUMX番目のチケットは結果として作成されます)警告にデエスカレートするクリティカルアラートの)。

注意: 外部参照は、## EXTERNALTICKETID ##トークンを介して公開できます。

アラートクリア通知のルーティングを確認する

サードパーティアプリケーションで孤立したチケットの発生率を減らすには、 アラートがクリアされたときに通知を送信する アラートルールのオプション。 このオプションは、最初のアラート通知が配信されたすべての受信者がアラートクリア通知も受信することを保証することに加えて(アラートタイプがアラートクリア通知をサポートしていると仮定)、SDT(スケジュール済み)であっても、このアラートクリア通知が配信されることを保証します。その後、ダウンタイム)がアクティブ化されました。 つまり、サードパーティアプリケーションがアラート通知を受信した場合、SDTステータスに関係なく、アラートクリア通知も受信します。

SDTはアラートルーティングを抑制するように設計されていますが、この場合のSDTのオーバーライドは、サードパーティアプリケーションでチケットを閉じるためにルーティングされたアラートクリア通知に依存するアラート統合にとって重要です。 このSDTオーバーライド動作は、データソースによってトリガーされたアラートにのみ適用されることに注意してください。 SDTの詳細については、を参照してください。 SDTタブ.

記事上で