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

[アーティクル]
2025-04-30

仮想マシン上の多くのアプリケーションとサービスでは、Windows イベントログや Syslog などの標準的なログサービスではなく、テキストファイルに情報が記録されます。仮想マシンからカスタムテキストログを収集するには、データ収集規則 (DCR) と カスタムテキストログ データソースを使用できます。

DCR の作成の詳細については、「Azure Monitor を使用して VM クライアントからデータを収集する」を参照してください。この記事では、カスタムテキストログデータソースの種類の詳細について説明します。

注

DCR 定義を直接操作するか、ARM テンプレートなどの他の方法でデプロイするには、 Azure Monitor のデータ収集規則 (DCR) サンプルを参照してください。

[前提条件]

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

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

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

カスタムテキストログ構成で使用できるオプションについては、次の表を参照してください。

設定	説明
ファイルパターン	ローカルディスク上のログファイルの場所と名前を確認します。新しい名前で毎日新しいファイルが作成される場合など、異なるファイル名にはワイルドカードを使用します。複数のファイルパターンをコンマで区切って入力できます。例： - C:\Logs\MyLog.txt - C:\Logs\MyLog.txt - C:\App01\AppLog.txt、C:\App02\AppLog.txt - /var/mylog.log - /var/mylog.log
テーブル名	Log Analytics ワークスペースの宛先テーブルの名前。このテーブルは既に存在している必要があります。
レコードの区切り記号	ログエントリ間の区切り記号を示します。 `TimeStamp` は、現在許可されている唯一の値です。これにより、新しいレコードの先頭を識別するために、 `timeFormat` で指定された形式の日付が検索されます。指定した形式の日付が見つからない場合は、行末が使用されます。詳細については、時刻形式を参照してください。
タイムスタンプ形式	ログファイルで使用される時刻形式を、以下の時刻形式で説明します。
変換	インジェスト時の変換を行ってレコードをフィルター処理したり、変換先テーブルの受信データを書式設定したりします。受信データを変更せずに`source`列に送信するには、`RawData`を使用します。変換の使用例については、区切りログファイルを参照してください。

宛先を追加する

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

時間形式

次の表では、DCR の timeFormat 設定でサポートされる時刻形式について説明します。指定した形式の時刻がログエントリに含まれている場合は、新しいログエントリを識別するために使用されます。指定した形式の日付が見つからない場合は、行末が区切り記号として使用されます。この設定の使用方法の詳細については、複数行のログファイルを参照してください。

時刻の形式	例
`ISO 8601`	2024-10-29T18:28:34Z
`yyyy-MM-ddTHH:mm:ssk`	2024-10-29T18:28:34Z 2024-10-29T18:28:34+01:11
`YYYY-MM-DD HH:MM:SS`	2024-10-29 18:28:34
`M/D/YYYY HH:MM:SS AM/PM`	2024 年 10 月 29 日午後 6:28:34
`Mon DD, YYYY HH:MM:SS`	2024 年 10 月 29 日 18:28:34
`yyMMdd HH:mm:ss`	241029 18:28:34
`ddMMyy HH:mm:ss`	291024 18:28:34
`MMM d HH:mm:ss`	10 月 29 日 18:28:34
`dd/MMM/yyyy:HH:mm:ss zzz`	14/Oct/2024:18:28:34 -00

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

Azure Monitor によって収集されるファイルは、次の要件を満たしている必要があります。

ファイルは、監視対象のディレクトリ内のエージェントコンピューターのローカルドライブに格納する必要があります。
ファイルでは、ASCII または UTF-8 エンコードを使用する必要があります。 UTF-16 など他の形式はサポートされていません。
新しいレコードは、古いレコードを上書きせず、ファイルの末尾に追加する必要があります。上書きすると、データが失われます。

Azure Monitor で収集できる一般的なカスタムテキストファイルのサンプルを次に示します。各行は日付で始まりますが、日付が見つからない場合は行末を使用して各エントリを識別するため、これは必要ありません。

2024-06-21 19:17:34,1423,Error,Sales,Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,Nightly backup complete.

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

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

Log Analytics ワークスペーステーブル

ログファイル内の各エントリは、作成されると収集され、Log Analytics ワークスペース内の指定されたテーブルに送信されます。 DCR を作成する前に、データを受け取る Log Analytics ワークスペース内のカスタムテーブルが存在している必要があります。

次の表では、ワークスペーステーブルの必須列と省略可能な列について説明します。テーブルには他の列を含めることができますが、「区切りログファイル」に記載されている説明に従って変換でデータを解析しない限り、これらの列は入力されません。

コラム	タイプ	必須。	説明
`TimeGenerated`	DATETIME	イエス	この列には、レコードが生成された時刻が含まれており、すべてのテーブルで必要です。この値には、レコードが Log Analytics ワークスペースに追加された時刻が自動的に設定されます。変換を使用してこの値をオーバーライドして、ログエントリの値に `TimeGenerated` を設定できます。
`RawData`	ひも	はい¹	1つの列にすべてのログエントリをまとめて。このデータを複数の列に分割してからテーブルに送信する場合は、変換を使用できます。
`Computer`	ひも	いいえ	テーブルにこの列が含まれている場合は、ログエントリが収集されたコンピューターの名前が入力されます。
`FilePath`	ひも	いいえ	テーブルにこの列が含まれている場合は、ログエントリが収集されたログファイルへのパスが設定されます。

¹ 変換を使用してデータを複数の列に解析する場合、テーブルに RawData 列を含める必要はありません。

既定の設定を使用して収集した場合、上記のサンプルログファイルのデータは、ログクエリを使用して取得すると次のように表示されます。

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

変換先テーブルがまだ存在しない場合は、DCR を作成する前に作成する必要があります。テーブルを作成するさまざまな方法については、「カスタムテーブルを作成する」を参照してください。

たとえば、次の PowerShell スクリプトを使用して、カスタムテキストログからデータを受信するカスタムテーブルを作成できます。この例では、オプションの列も追加します。

$tableParams = @'
{
    "properties": {
        "schema": {
               "name": "{TableName}_CL",
               "columns": [
                    {
                        "name": "TimeGenerated",
                        "type": "DateTime"
                    }, 
                    {
                        "name": "Computer",
                        "type": "string"
                    },
                    {
                        "name": "FilePath",
                        "type": "string"
                    },
                    {
                        "name": "RawData",
                        "type": "string"
                    }
              ]
        }
    }
}
'@

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

複数行ログファイル

一部のログファイルには、複数の行にまたがるエントリが含まれている場合があります。各ログエントリが日付で始まる場合、この日付を区切り記号として使用して各ログエントリを定義できます。この場合、追加の行が RawData 列に結合されます。

たとえば、前の例のテキストファイルの形式は次のようになります。

2024-06-21 19:17:34,1423,Error,Sales,
Unable to connect to pricing service.
2024-06-21 19:18:23,1420,Information,Sales,
Pricing service connection established.
2024-06-21 21:45:13,2011,Warning,Procurement,
Module failed and was restarted.
2024-06-21 23:53:31,4100,Information,Data,
Nightly backup complete.

YYYY-MM-DD HH:MM:SSタイムスタンプ形式が DCR で使用されている場合、データは前の例と同じ方法で収集されます。追加の行は、 RawData 列に含まれます。ログエントリの日付と一致しない別のタイムスタンプ形式が使用された場合、各エントリは 2 つの個別のレコードとして収集されます。

区切り文字で区切られたログファイル

多くのテキストログファイルには、コンマなどの文字で区切られた列を含むエントリがあります。エントリ全体を RawData 列に送信する代わりに、データを個別の列に解析して、それぞれを宛先テーブルに設定できます。分割関数で変換を使用して、この解析を実行します。

上記のサンプルテキストファイルはコンマ区切りであり、フィールドは Time、 Code、 Severity、 Module、および Messageとして記述できます。このデータを個別の列に解析するには、各列を変換先テーブルに追加し、次の変換を DCR に追加します。

重要

この変換を DCR に追加する前に、これらの列を変換先テーブルに追加する必要があります。上記の PowerShell スクリプトを変更して、テーブルの作成時に追加の列を含めることができます。または、「カスタム列を追加または削除して既存のテーブルに列を追加する」の説明に従って、Azure portal を使用します。

変換クエリの注目すべき詳細は次のとおりです。

このクエリは、ターゲットテーブル内の列名に一致するプロパティを出力します。
次の使用例は、ログファイルの Time プロパティの名前を変更して、この値を TimeGeneratedに使用します。これが指定されていない場合、 TimeGenerated にはインジェスト時間が設定されます。
split は動的データを返すので、tostring や toint などの関数を使用して、データを正しいスカラー型に変換する必要があります。

source | project d = split(RawData,",") | project TimeGenerated=todatetime(d[0]), Code=toint(d[1]), Severity=tostring(d[2]), Module=tostring(d[3]), Message=tostring(d[4])

ログクエリでこのデータを取得すると、次の結果が返されます。

トラブルシューティング

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

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

次のステップ

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

次の方法で共有

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

[前提条件]

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

宛先を追加する

時間形式

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

Log Analytics ワークスペース テーブル

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

複数行ログ ファイル