この記事では、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.trackingId
インシデントに関する Service Health ダッシュボードへのリンクを作成する
特殊な URL を生成して、デスクトップまたはモバイル デバイス上の Service Health ダッシュボードへの直接リンクを作成します。 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 スキーマを確認します。
- サービス正常性の通知について学習します。
- アクション グループについて学習します。