Azure Monitor を使用して仮想マシンから JSON ファイルを収集する

多くのアプリケーションとサービスでは、Windows イベント ログや Syslog などの標準のログ記録サービスの代わりに、テキスト ファイルに情報を記録します。 このデータが JSON 形式で格納されている場合は、カスタム JSON ログ データ ソースを使用してデータ収集規則 (DCR) で Azure Monitor によって収集できます。

DCR の作成の詳細については、「Azure Monitor エージェントを使用してデータを収集する」を参照してください。 この記事では、JSON ログの種類の詳細について説明します。

[前提条件]

「Azure Monitor を使用して仮想マシン クライアントからデータを収集する」に記載されている前提条件に加えて、データを受信するには Log Analytics ワークスペースにカスタム テーブルが必要です。 このテーブルの要件の詳細については、 Log Analytics ワークスペースの表 を参照してください。

カスタム JSON ファイル のデータ ソースを構成する

「Azure Monitor を使用して仮想マシン クライアントからデータを収集する」のプロセスを使用して DCR を作成します。 DCR の [収集と配信] タブで、[データ ソースの種類] ドロップダウンから [カスタム JSON ログ] を選択します。

カスタム JSON ログ構成で使用できるオプションについては、次の表で説明します。

宛先を追加する

カスタム JSON ログは、作成した カスタム テーブル に格納されている Log Analytics ワークスペースにのみ送信できます。 Azure Monitor ログの種類の宛先を追加し、Log Analytics ワークスペースを選択します。 カスタム JSON ログ データ ソースの DCR に追加できるワークスペースは 1 つだけです。 複数の宛先が必要な場合は、複数の DCR を作成します。 ただし、これにより重複するデータがそれぞれに送信され、追加コストが発生します。

JSON ファイルの要件とベスト プラクティス:

Azure Monitor エージェントが収集するファイルは、次の要件を満たしている必要があります。

• ファイルは、監視対象のディレクトリ内のエージェント コンピューターのローカル ドライブに格納する必要があります。
• 各エントリは JSON 行 (JSONL または NDJSON) である必要があります。これは JSON の 1 行であり、行末で示されます。 JSON 本文フォーマットはサポートされません。 以下のサンプルを参照してください。
• ファイルでは、ASCII または UTF-8 エンコードを使用する必要があります。 UTF-16 など他の形式はサポートされていません。
• 新しいレコードは、古いレコードを上書きせず、ファイルの末尾に追加する必要があります。 上書きすると、データが失われます。

Azure Monitor によって収集できる一般的な JSON ログ ファイルのサンプルを次に示します。 これには、 Time、 Code、 Severity、Module、 Messageの各フィールドが含まれます。

{"Time":"2025-03-07 13:17:34","Code":1423,"Severity":"Error","Module":"Sales","Message":"Unable to connect to pricing service."}
{"Time":"2025-03-07 13:18:23","Code":1420,"Severity":"Information","Module":"Sales","Message":"Pricing service connection established."}
{"Time":"2025-03-07 15:45:13","Code":2011,"Severity":"Warning","Module":"Procurement","Message":"Module failed and was restarted."}
{"Time":"2025-03-07 15:53:31","Code":4100,"Severity":"Information","Module":"Data","Message":"Daily backup complete."}

データの損失やパフォーマンスの問題が発生しないように、次の推奨事項に従ってください。

• ログ ファイルを含む 10 個を超えるディレクトリをターゲットにしないでください。 ポーリングするディレクトリが多すぎると、パフォーマンスが低下します。
• 監視対象ディレクトリのログ ファイルを継続的にクリーンアップします。 多くのログ ファイルを追跡すると、エージェントの CPU とメモリの使用量が増える可能性があります。 すべてのログが処理されるための十分な時間を確保できるよう、少なくとも 2 日間待ちます。
• ファイル スキャンのパターンと一致するファイルの名前を、ファイル スキャンのパターンと一致する別の名前に変更しないでください。 これにより、重複するデータが取り込まれることになります。
• ファイル スキャンのパターンと一致する大規模ログ ファイルの名前を変更したり、監視対象のディレクトリにコピーしたりしないでください。 必要な場合は、1 分あたり 50 MB を超えないようにしてください。

ログ解析ワークスペースのテーブル

エージェントは、指定された名前パターンと一致するローカル ディスク上の json ファイルを監視します。 各エントリはログに書き込まれると収集され、Log Analytics ワークスペース内の指定されたテーブルに送信される前に解析されます。 DCR を作成する前に、データを受け取る Log Analytics ワークスペース内のカスタム テーブルが存在している必要があります。

解析された Json データ内のフィールドの名前と一致するテーブル内の列には、ログ エントリの値が設定されます。 次の表では、JSON データで識別される列に加えて、ワークスペース テーブルの必須列と省略可能な列について説明します。

次の例は、上記のサンプル JSON ファイル用に作成されたテーブルからデータを返すクエリを示しています。 上記のサンプル JSON スキーマを使用して DCR を使用して収集されました。 JSON データには TimeGeneratedのプロパティが含まれていないため、インジェスト時間が使用されます。 Computer列とFilePath列も自動的に設定されます。

カスタム テーブルを作成する

変換先テーブルがまだ存在しない場合は、DCR を作成する前に作成する必要があります。 テーブル を作成する さまざまな方法については、「カスタム テーブルを作成する」を参照してください。 たとえば、次の PowerShell スクリプトを使用して、上記のサンプル JSON ファイルからデータを受信するカスタム テーブルを作成できます。 この例では、オプションの列も追加します。

$tableParams = @'
{
    "properties": {
        "schema": {
               "name": "{TableName}_CL",
               "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "dateTime"
                    }, 
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "Time",
                        "type": "dateTime"
                    },
                    {
                        "name": "Code",
                        "type": "int"
                    },
                    {
                        "name": "Severity",
                        "type": "string"
                    },
                    {
                        "name": "Module",
                        "type": "string"
                    },
                    {
                        "name": "Message",
                        "type": "string"
                    }
              ]
        }
    }
}
'@

Invoke-AzRestMethod -Path "/subscriptions/{subscription}/resourcegroups/{resourcegroup}/providers/microsoft.operationalinsights/workspaces/{WorkspaceName}/tables/{TableName}_CL?api-version=2021-12-01-preview" -Method PUT -payload $tableParams

変革

この変換では、受信ストリームを変更するためにレコードがフィルター処理されたり、ターゲット テーブルと一致するようにスキーマが変更されたりする可能性があります。 受信ストリームのスキーマがターゲット テーブルと同じ場合は、source の既定の変換を使用できます。 そうでない場合は、必要なスキーマを返す KQL クエリを使用して、ARM テンプレートの transformKql セクションを変更します。

たとえば、上記の例では、ログ エントリには、ログ エントリが作成された時刻を含む Time フィールドがあります。 これを変換先テーブルに個別の列として格納する代わりに、次の変換を使用して、 Time プロパティの値を TimeGeneratedにマップできます。

source | extend TimeGenerated = todatetime(Time) | project-away Time

これにより、次のログ クエリが発生します。 Time列が空白であり、そのプロパティの値がTimeGeneratedに使用されていることに注意してください。

トラブルシューティング

想定している JSON ログからデータを収集しない場合は、次の手順を実行します。

• 収集されるログ ファイルにデータが書き込まれていることを確認します。
• ログ ファイルの名前と場所が、指定したファイル パターンと一致することを確認します。
• DCR の受信ストリームのスキーマが、ログ ファイルのスキーマと一致していることを確認します。
• ターゲット テーブルのスキーマが受信ストリームと一致していること、または受信ストリームを正しいスキーマに変換する変換があることを確認します。
• 「操作の確認」を参照して、エージェントが動作していて、データが受信されているかどうかを確認します。

次のステップ

• Azure Monitor エージェントの詳細を理解します。
• データ収集ルールの詳細を確認します。