Azure Monitor のログ検索アラートのトラブルシューティング

[アーティクル]
10/14/2024

この記事では、Azure Monitor 内のログ検索アラートに関する一般的な問題の解決方法について説明します。また、ログアラートの機能や構成でよく発生する問題の解決策も紹介しています。

ログアラートにより、ユーザーは Log Analytics クエリを使用して、設定された頻度でリソースログを評価し、その結果に基づいてアラートを発行することができます。アクショングループを使用することで、ルールによって 1 つ以上のアクションをトリガーできます。ログ検索アラートの機能と用語の詳細については、「Azure Monitor でのログアラート」を参照してください。

Note

この記事では、Azure portal に警告ルールがトリガーされたことが表示されていても、通知が送信されなかったケースについては説明していません。このようなケースについては、アラートのトラブルシューティングに関するページをご覧ください。

ログ検索アラートが発生するはずなのに発生しなかった

ログ検索アラートが発生するはずなのに発生しなかった場合は、次の項目を確認します。

警告ルールの正常性状態が低下または利用不可になっていませんか?

ログ検索警告ルールの正常性状態を表示します。
1. ポータルで、[モニター] を選び、[アラート] を選びます。
2. 上部のコマンドバーから [警告ルール] を選択します。このページには、すべてのサブスクリプションのすべての警告ルールが表示されます。
3. 監視するログ検索アラートルールを選択します。
4. 左側のウィンドウの [ヘルプ] で、[リソース正常性] を選択します。
詳細については、「ログ検索警告ルールの正常性を監視する」を参照してください。
ログインジェストの待機時間を確認します。

Azure Monitor では、世界中にわたる顧客のテラバイト単位のログを処理します。それにより、ログインジェストの待機時間が発生する可能性があります。

ログは半構造化されたデータであり、本質的にメトリックよりも潜在的な状態で存在します。発せられたアラートの遅延が 4 分以上発生している場合は、メトリックアラートの使用を検討してください。ログのメトリックアラートを使用して、ログからメトリックストアにデータを送信できます。

待機時間を軽減するため、システムではアラートの評価が複数回再試行されます。データが到着するとアラートが発生します。ほとんどの場合、ログレコードの時刻とは等しくありません。
アクションがミュートされていませんか? あるいは、アラートが自動的に解決されるようにルールが構成されていませんか?

アラートが起動しなかったことを問題と考えてしまいますが、問題なのは、アラートが起動しないようにルールが構成されていることです。ログ検索警告ルールの詳細オプションを見て、次の両方が選択されていないことを確認します。
- [アクションのミュート] チェックボックス: 起動したアラートアクションを一定時間ミュートできます。
- [アラートを自動的に解決する]: 条件が一致するごとにアラートが一度だけ起動するように構成します。
警告ルールリソースが移動または削除されていませんか?

警告ルールリソースが移動または削除された場合、あるいは名前が変更された場合、そのリソースを参照しているすべてのログ警告ルールが機能しなくなります。この問題を解決するには、そのスコープに対して有効なターゲットリソースを使用して、警告ルールを再作成する必要があります。
警告ルールで、システム割り当てマネージド ID が使用されていませんか?

システム割り当てマネージド ID を使用してログアラートルールを作成すると、アクセス許可なしで ID が作成されます。ルールを作成したら、クエリするデータにアクセスできるように、ルールの ID に適切なロールを割り当てる必要があります。たとえば、関連する Log Analytics ワークスペースには閲覧者ロールを、関連する ADX クラスターには閲覧者ロールとデータベースビューアーロールを付与することが必要になる場合があります。ログアラートでのマネージド ID の使用の詳細については、マネージド ID に関するページを参照してください。
ログ検索警告ルールで使用されるクエリは有効ですか?

ログアラートルールが作成されるときには、クエリの構文が正しいか検証されます。ただし場合によっては、ログ警告ルールで指定されたクエリが失敗し始めることがあります。一般的な理由を以下にいくつか示します。
- ルールが API によって作成され、ユーザーが検証をスキップしました。
- クエリが複数のリソースに対して実行され、1 つ以上のリソースが削除または移動されました。
- クエリが失敗するのは以下のためです。
  - ログ記録ソリューションがワークスペースにデプロイされなかったために、テーブルが作成されていません。
  - クエリのテーブルへのデータフローが 30 日より長く停止しました。
  - データフローが開始されていないため、カスタムログテーブルが作成されていません。
- クエリ言語が変更されて、コマンドと関数の形式が変更されたため、前に指定したクエリが無効になります。
Azure Service Health では、ログ検索アラートルールを含むクラウドリソースの正常性を監視します。ログ検索アラートルールが正常な場合、ルールが実行され、クエリが正常に実行されます。ログ検索アラートルールのリソース正常性を使用して、ログ検索アラートルールに影響する問題を調べることができます。
ログ検索警告ルールが無効になっていませんか?

ログ検索警告ルールのクエリが 1 週間にわたり評価に失敗し続けた場合、そのルールは Azure Monitor によって自動的に無効にされます。

以降のセクションで、Azure Monitor によってログ検索アラートルールが無効にされた可能性があるいくつかの理由を挙げます。さらに、ルールが無効にされたときに送信されるアクティビティログイベントの例があります。

ルールが無効になっているときのアクティビティログの例

{
    "caller": "Microsoft.Insights/ScheduledQueryRules",
    "channels": "Operation",
    "claims": {
        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/spn": "Microsoft.Insights/ScheduledQueryRules"
    },
    "correlationId": "abcdefg-4d12-1234-4256-21233554aff",
    "description": "Alert: test-bad-alerts is disabled by the System due to : Alert has been failing consistently with the same exception for the past week",
    "eventDataId": "f123e07-bf45-1234-4565-123a123455b",
    "eventName": {
        "value": "",
        "localizedValue": ""
    },
    "category": {
        "value": "Administrative",
        "localizedValue": "Administrative"
    },
    "eventTimestamp": "2019-03-22T04:18:22.8569543Z",
    "id": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "level": "Informational",
    "operationId": "",
    "operationName": {
        "value": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "localizedValue": "Microsoft.Insights/ScheduledQueryRules/disable/action"
    },
    "resourceGroupName": "<Resource Group>",
    "resourceProviderName": {
        "value": "MICROSOFT.INSIGHTS",
        "localizedValue": "Microsoft Insights"
    },
    "resourceType": {
        "value": "MICROSOFT.INSIGHTS/scheduledqueryrules",
        "localizedValue": "MICROSOFT.INSIGHTS/scheduledqueryrules"
    },
    "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
    "status": {
        "value": "Succeeded",
        "localizedValue": "Succeeded"
    },
    "subStatus": {
        "value": "",
        "localizedValue": ""
    },
    "submissionTimestamp": "2019-03-22T04:18:22.8569543Z",
    "subscriptionId": "<SubscriptionId>",
    "properties": {
        "resourceId": "/SUBSCRIPTIONS/<subscriptionId>/RESOURCEGROUPS/<ResourceGroup>/PROVIDERS/MICROSOFT.INSIGHTS/SCHEDULEDQUERYRULES/TEST-BAD-ALERTS",
        "subscriptionId": "<SubscriptionId>",
        "resourceGroup": "<ResourceGroup>",
        "eventDataId": "12e12345-12dd-1234-8e3e-12345b7a1234",
        "eventTimeStamp": "03/22/2019 04:18:22",
        "issueStartTime": "03/22/2019 04:18:22",
        "operationName": "Microsoft.Insights/ScheduledQueryRules/disable/action",
        "status": "Succeeded",
        "reason": "Alert has been failing consistently with the same exception for the past week"
    },
    "relatedEvents": []
}

ログ検索アラートが発生するはずがないときに発生した

構成した Azure Monitor のログアラートルールが予期せずトリガーされる場合があります。以下のセクションでは、よくある原因をいくつか説明します。

待機時間の問題が原因でアラートがトリガーされていませんか?

Azure Monitor では、世界中の顧客のテラバイト単位のログが処理されます。このため、ログインジェストの待機時間が発生する可能性があります。誤ったアラートを防止する機能は組み込まれていますが、それでも、非常に潜在性の高いデータ (約 30 分以上) や待機時間が急増することがあるデータで発生する可能性があります。

ログは半構造化されたデータであり、本質的にメトリックよりも潜在的な状態で存在します。発せられたアラートで、誤発生が多数起きている場合は、メトリックアラートの使用を検討してください。ログのメトリックアラートを使用して、ログからメトリックストアにデータを送信できます。

ログ検索アラートが最適に機能するのは、ログ内で特定のデータの検出を試みるときです。仮想マシンのハートビートに関するアラートなど、ログ内にデータがないことを検出しようとしている場合、あまり効果的ではありません。

ログ検索警告ルールを構成するときのエラーメッセージ

具体的なエラーメッセージとその解決策については、次のセクションを参照してください。

ログのアクセス許可が必要なため、クエリを検証できなかった

警告ルールクエリの作成時または編集時にこのエラーメッセージが表示される場合は、ターゲットリソースログを読み取るアクセス許可があることを確認します。

ワークスペースコンテキストアクセスモードでログを読み取るために必要なアクセス許可: Microsoft.OperationalInsights/workspaces/query/read
リソースコンテキストアクセスモード (ワークスペースベースの Application Insights リソースを含む) でログを読み取るために必要なアクセス許可: Microsoft.Insights/logs/tableName/read

アクセス許可の詳細については、「Log Analytics ワークスペースへのアクセスを管理する」を参照してください。

このクエリでは 1 分間隔がサポートされていない

1分間のアラート規則頻度を使用するには、いくつかの制限があります。アラートルールの頻度を 1 分に設定すると、クエリを最適化するために内部操作が実行されます。サポートされていない操作が含まれている場合、この操作によってクエリが失敗するおそれがあります。

サポートされていないシナリオのリストについては、こちらの注を参照してください。

<> という名前のスカラー式を解決できない

このエラーメッセージは、警告ルールクエリを作成または編集しているとき、次の場合に返されることがあります。

テーブルスキーマが存在しない列を参照している。
以前のクエリのプロジェクト句で使われていない列を参照しています。

これを軽減するには、前のプロジェクト句に列を追加するか、columnifexists 演算子を使います。

読み取り専用 OMS アラートで ScheduledQueryRules API がサポートされていない

このエラーメッセージは、Azure portal を使用してレガシ API バージョンで作成されたルールを更新または削除しようとすると返されます。

Log Analytics REST API を使って、プログラムでルールを編集または削除します。
推奨: 警告ルールをアップグレードして Scheduled Query Rules API を使います (レガシ API は非推奨になる予定です)。

警告ルールサービスの制限に達した

サブスクリプションごとのログ検索アラートルールの数とリソースの上限の詳細については、「Azure Monitor サービスの制限」を参照してください。使用中のログ警告ルールの合計数の確認に関するページを参照して、現在使用中のメトリック警告ルールの数を確認します。クォータ制限に達した場合は、次の手順が問題の解決に役立つ場合があります。

今後使用しないログ検索アラートルールを削除または無効にします。
ディメンションごとの分割を使用して、ルール数を減らします。ディメンションごとの分割を使用する場合、1 つのルールで多くのリソースを監視できます。
クォータ制限を増やす必要がある場合は、引き続きサポートリクエストを開き、以下の情報を提供します。
- クォータ制限を引き上げる必要があるサブスクリプション ID とリソース ID
- クォータの引き上げの理由
- クォータを引き上げるリソースの種類 (Log Analytics、Application Insights など)
- 要求されるクォータ制限

ARG および ADX クエリでの不完全な時間フィルター処理

ログ検索アラートで Azure Data Explorer (ADX) または Azure Resource Graph (ARG) クエリを使用すると、"集計の粒度" 設定でクエリに時間フィルターが適用されないという問題が発生する可能性があります。これにより、クエリでは、意図した時間範囲ではなく、ドラフトから 30 日間のデータがすべて返されるため、予期しない結果や潜在的なパフォーマンスの問題につながる可能性があります。

この問題を解決するには、ARG および ADX クエリに時間フィルターを明示的に適用する必要があります。確認する手順を以下に示します。

適切な時間フィルター処理: 時間範囲を特定する: クエリを実行する特定の時間範囲を決定します。たとえば、過去 24 時間のデータに対してクエリを実行する場合は、クエリでこの時間範囲を指定する必要があります。
クエリを変更する: ARG または ADX クエリに時間フィルターを追加して、返されるデータを目的の時間範囲に制限します。クエリを変更する方法の例を以下に示します。

    // Original query without time filter
    resources
    | where type == "microsoft.compute/virtualmachines"

    // Modified query with time filter
    resources
    | where type == "microsoft.compute/virtualmachines"
    | where timestamp >= ago(24h)

クエリをテストする: 変更されたクエリを実行して、指定した時間内に予想される結果が返されることを確かめます。
アラートを更新する: 明示的な時間フィルターで変更されたクエリを使用するようにログ検索アラートを更新します。これにより、アラートが正しいデータに基づいており、不要な履歴データが含まれていないことが保証されます。 ARG および ADX クエリに明示的な時間フィルターを適用することで、過剰なデータを取得する問題を回避し、ログ検索アラートが正確かつ効率的であることを確かめることができます。

次のステップ

Azure でのログアラートについて学習します。
ログアラートの構成に関する詳細を確認します。
ログクエリについてさらに学習します

次の方法で共有

Azure Monitor のログ検索アラートのトラブルシューティング

ログ検索アラートが発生するはずなのに発生しなかった

ルールが無効になっているときのアクティビティログの例

ログ検索アラートが発生するはずがないときに発生した

ログ検索警告ルールを構成するときのエラーメッセージ

ログのアクセス許可が必要なため、クエリを検証できなかった

このクエリでは 1 分間隔がサポートされていない

<> という名前のスカラー式を解決できない

読み取り専用 OMS アラートで ScheduledQueryRules API がサポートされていない

警告ルールサービスの制限に達した

ARG および ADX クエリでの不完全な時間フィルター処理

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Monitor のログ検索アラートのトラブルシューティング

ログ検索アラートが発生するはずなのに発生しなかった

ルールが無効になっているときのアクティビティ ログの例

ログ検索アラートが発生するはずがないときに発生した

ログ検索警告ルールを構成するときのエラー メッセージ

ログのアクセス許可が必要なため、クエリを検証できなかった

このクエリでは 1 分間隔がサポートされていない

<> という名前のスカラー式を解決できない

読み取り専用 OMS アラートで ScheduledQueryRules API がサポートされていない

警告ルール サービスの制限に達した

ARG および ADX クエリでの不完全な時間フィルター処理

次のステップ

フィードバック

その他のリソース

ルールが無効になっているときのアクティビティログの例

ログ検索警告ルールを構成するときのエラーメッセージ

警告ルールサービスの制限に達した