コードを記述せずにクラウド間でのデータのアクセスと使用を自動化する Azure サービス。
@ 様12G-4164
Microsoft Q&Aにお問い合わせいただき、誠にありがとうございます。
Azure MonitorとLogic Appsを使用してアラート通知をカスタマイズする際、組み込みのアラートメールと同様に「Hostname(ホスト名)」フィールドが自動的に入力されることを期待されるケースがよくあります。しかし、これは自動的には機能しません。その理由は、Azure Monitorが「Common Alert Schema(共通アラートスキーマ)」に準拠しており、すべてのアラートタイプに共通する普遍的な「hostname」プロパティが提供されていないためです。代わりに、アラートデータは「Essentials(重要情報:重大度、発生時刻、ターゲットリソースIDなどの一般的なメタデータ)」と「Alert Context(アラートコンテキスト:メトリックのディメンションやログクエリの結果など、シグナル固有の詳細情報)」に分割されます。その結果、AKSクラスター名、ノード名、Pod名といった分かりやすい識別子は、アラートのディメンションやクエリ出力の一部として明示的に含まれていない限り、必ずしもデータに含まれるとは限りません。Logic Apps自体はホスト名を独自に計算したり推測したりする機能を持っておらず、アラートルールから送信されたデータを利用することしかできません。
この問題を解決するため、または回避策として、以下の点をご参照ください。
固定の「Hostname」フィールドではなく、アラートペイロード内のフィールドを使用する
Azure Monitorは、単一の「Hostname」プロパティとしては情報を公開していません。代わりに、configurationItems、alertTargetIDs、メトリックのディメンション、ログクエリの列など、既存のペイロードフィールドからホスト名に相当する情報をマッピング(割り当て)する必要があります。これにカスタムコードの記述は不要で、Logic App内で適切な「動的コンテンツ」を選択するだけで実現可能です。
メトリックアラートの場合 — ホスト名の詳細には「ディメンション」を使用する
メトリックアラート(例:AKS、VM、App Serviceなど)の場合、意味のある識別子は通常、アラートコンテキスト内の「ディメンション」として利用可能です。これには、クラスター名、ノード名、インスタンス名などの値が含まれます。
Logic App内では、別の関数を作成することなく、動的コンテンツや式を使用してこれらの値を直接参照することができます。
ログ検索アラートの場合 — KQLを使用してホスト名の情報を整形する
ログアラートの場合、「hostname」に相当する情報はKQLクエリ自体から取得する必要があります。クエリ内で射影(抽出)された列(例:PodName、NodeName、ClusterNameなど)はすべて、Logic Appのトリガーペイロード内で利用可能になります。
推奨されるアプローチは、KQL内で必要なフィールドを正確に射影し、通知本文内でそれらを直接マッピングすることです。
情報の補完(エンリッチメント)が必要な場合にのみ、関数や追加のAPI呼び出しを使用する
カスタム関数やHTTP呼び出しが必要となるのは、アラートペイロード内に必要な「分かりやすい名前(フレンドリー名)」が含まれていない場合のみです(例:リソースIDしか受信しておらず、それを表示名に変換・解決する必要がある場合など)。ほとんどの標準的なメトリックおよびログアラートについては、これは不要です。