Webhook を使用して問題管理システム用に正常性通知を構成する
この記事では、既存の通知システムに Webhook を使用してデータを送信するように Azure Service Health アラートを構成する方法を示します。
Azure サービス インシデントの影響を受けた場合にテキスト メッセージまたはメール経由で通知を受け取るように Service Health アラートを構成することができます。
しかし、利用したい既存の外部通知システムが既に構成されている場合もあります。 この記事では、Webhook ペイロードの最も重要な部分について説明します。 また、関連するサービスの問題が発生したときに通知を受けられるようにカスタム アラートを作成する方法についても説明します。
構成済みの統合を使用する場合は、以下を参照してください。
紹介ビデオを視聴する:
Service Health の Webhook ペイロードを使用してカスタム通知を構成する
独自のカスタム Webhook 統合を設定するには、Service Health の通知を介して送信される JSON ペイロードを解析する必要があります。
Webhook ペイロードの例 ServiceHealth
を参照してください。
それがサービス正常性アラートであることを確認するには、context.eventSource == "ServiceHealth"
を探します。 以下のプロパティが最も関連性があります。
- data.context.activityLog.status
- data.context.activityLog.level
- data.context.activityLog.subscriptionId
- data.context.activityLog.properties.title
- data.context.activityLog.properties.impactStartTime
- data.context.activityLog.properties.communication
- data.context.activityLog.properties.impactedServices
- data.context.activityLog.properties.trackingId
インシデントに関する Service Health ダッシュボードへのリンクを作成する
ご利用の Service Health ダッシュボードへの直接リンクをデスクトップまたはモバイル上に作成するには、特別な URL を生成します。 trackingId と、ご利用の subscriptionId の最初の 3 桁と最後の 3 桁を次の形式で使用します。
https://app.azure.com/h/<trackingId>/<subscriptionId の最初の 3 桁と最後の 3 桁>
たとえば、subscriptionId が aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e であり、trackingId が 0DET-URB である場合、Service Health URL は次のようになります。
https://app.azure.com/h/0DET-URB/bbadb3
level を使用して問題の重大度を検出する
ペイロードの level プロパティは、Informational、Warning、Error、または Critical とすることができます (最低の重大度から順に最高の重大度まで)。
影響を受けるサービスを解析してインシデントの範囲を特定する
Service Health アラートによって通知される内容は、複数のリージョンおよびサービスにまたがる問題である場合もあります。 完全な詳細情報を取得するには、impactedServices
の値を解析する必要があります。
その内部にあるコンテンツは、エスケープされた JSON 文字列です。エスケープされていない場合は、規則的に解析することができる別の JSON オブジェクトが含まれます。 次に例を示します。
{"data.context.activityLog.properties.impactedServices": "[{\"ImpactedRegions\":[{\"RegionName\":\"Australia East\"},{\"RegionName\":\"Australia Southeast\"}],\"ServiceName\":\"Alerts & Metrics\"},{\"ImpactedRegions\":[{\"RegionName\":\"Australia Southeast\"}],\"ServiceName\":\"App Service\"}]"}
を次に変更
[
{
"ImpactedRegions":[
{
"RegionName":"Australia East"
},
{
"RegionName":"Australia Southeast"
}
],
"ServiceName":"Alerts & Metrics"
},
{
"ImpactedRegions":[
{
"RegionName":"Australia Southeast"
}
],
"ServiceName":"App Service"
}
]
この例では、次の問題を示します。
- オーストラリア東部とオーストラリア南東部での "アラートとメトリック"。
- オーストラリア南東部の "App Service"。
HTTP POST 要求によって Webhook 統合をテストする
次の手順のようにします。
送信するサービス正常性のペイロードを作成します。 サービス正常性 Webhook ペイロードの例については、「Azure アクティビティ ログ アラートのための Webhook」を参照してください。
次のような HTTP POST 要求を作成します。
POST https://your.webhook.endpoint HEADERS Content-Type: application/json BODY <service health payload>
"2XX - Successful" という応答が表示されます。
PagerDuty に移動して、統合が正常に設定されたことを確認します。
次のステップ
- アクティビティ ログ アラート webhook スキーマを確認します。
- サービス正常性の通知について学習します。
- アクション グループについて学習します。