Azure Monitor エージェントを使用してテキスト ファイルからログを収集する
カスタム テキスト ログは、データ収集ルール (DCR) で使用されるデータ ソースの 1 つです。 DCR の作成の詳細については、「Azure Monitor エージェントを使用してデータを収集する」を参照してください。 この記事では、テキスト ログの種類の詳細について説明します。
多くのアプリケーションとサービスでは、Windows イベント ログや Syslog などの標準のログ記録サービスの代わりに、テキスト ファイルに情報を記録します。 このデータは、Azure Monitor エージェントを使用して収集し、他のソースから収集されたデータとともに Log Analytics ワークスペースに格納できます。
前提条件
- 少なくとも共同作成者権限がある Log Analytics ワークスペース。
- このデータ収集エンドポイント (DCE) は、Log Analytics ワークスペースと同じリージョン内に存在します。 詳細については、「デプロイに基づいてデータ収集エンドポイントを設定する方法」を参照してください。
- 「Azure Monitor エージェントを使用してデータを収集する」で説明されている新規または既存の DCR。
基本的な操作
次の図は、テキスト ファイルからログ データを収集する基本的な操作を示しています。
- エージェントは、ローカル ディスク上の指定された名前パターンと一致するすべてのログ ファイルを監視します。
- ログ内の各エントリが収集され、Azure Monitor に送信されます。 受信ストリームでは、ログ エントリ全体が 1 つの列に含まれます。
- 既定の変換が使用されている場合、ログ エントリ全体がターゲット テーブルの 1 つの列に送信されます。
- カスタム変換が使用されている場合、ログ エントリをターゲット テーブル内の複数の列に分割できます。
テキスト ファイルの要件とベスト プラクティス
Azure Monitor エージェントが監視しているファイルは、次の要件を満たしている必要があります。
- ファイルは、Azure Monitor エージェントがあるコンピューターのローカル ドライブの、監視対象のディレクトリ内に格納する必要があります。
- 各レコードは、行末で区切る必要があります。
- ファイルでは、ASCII または UTF-8 エンコードを使用する必要があります。 UTF-16 など他の形式はサポートされていません。
- 新しいレコードは、古いレコードを上書きせず、ファイルの末尾に追加する必要があります。 上書きすると、データが失われます。
データの損失やパフォーマンスの問題が発生しないように、次の推奨事項に従ってください。
- 古いファイルを簡単にクリーンアップできるように、毎日新しいログ ファイルを作成します。
- 監視対象ディレクトリのログ ファイルを継続的にクリーンアップします。 多くのログ ファイルを追跡すると、エージェントの CPU とメモリの使用量が増える可能性があります。 すべてのログが処理されるための十分な時間を確保できるよう、少なくとも 2 日間待ちます。
- ファイル スキャンのパターンと一致するファイルの名前を、ファイル スキャンのパターンと一致する別の名前に変更しないでください。 これにより、重複するデータが取り込まれることになります。
- ファイル スキャンのパターンと一致する大規模ログ ファイルの名前を変更したり、監視対象のディレクトリにコピーしたりしないでください。 必要な場合は、1 分あたり 50 MB を超えないようにしてください。
着信ストリーム
Note
区切りイベントにタイム スタンプを使用する複数行のサポートが利用可能になりました。 ポータル UI にサポートが追加されるまでは、リソース管理テンプレートのデプロイを使用する必要があります。
データの受信ストリームには、次の表にある列が含まれています。
| 列 | タイプ | 説明 |
|---|---|---|
TimeGenerated |
datetime | レコードが生成された時刻。 この値には、レコードが Log Analytics ワークスペースに追加された時刻が自動的に設定されます。 変換を使用してこの値をオーバーライドして、TimeGenerated を別の値に設定できます。 |
RawData |
string | 1 つの列のログ エントリ全体。 このデータを複数の列に分割してからテーブルに送信する場合は、変換を使用できます。 |
FilePath |
string | この列を DCR の受信ストリームに追加すると、ログ ファイルへのパスが設定されます。 この列は自動的には作成されず、ポータルを使用して追加することはできません。 ポータルによって作成された DCR を手動で変更するか、受信ストリームを明示的に定義できる別の方法を使用して DCR を作成する必要があります。 |
Computer |
string | この列を DCR の受信ストリームに追加すると、ログ ファイルのあるコンピューターの名前が設定されます。 この列は自動的には作成されず、ポータルを使用して追加することはできません。 ポータルによって作成された DCR を手動で変更するか、受信ストリームを明示的に定義できる別の方法を使用して DCR を作成する必要があります。 |
カスタム テーブル
テキスト ファイルからログ データを収集する前に、Log Analytics ワークスペースにカスタム テーブルを作成してデータを受信する必要があります。 テーブル スキーマは、収集するデータと一致する必要があります。または、出力スキーマがテーブルと一致するように変換を追加する必要があります。
警告
データ損失を回避するには、MMA エージェントによって現在使用されている既存のカスタム ログ テーブルを使用しないことが重要です。 AMA エージェントで既存のカスタム ログ テーブルに書き込みを行うと、MMA エージェントからそのテーブルへの書き込みを実行できなくなります。 その代わり、AMA エージェント専用の新しいテーブルを作成することで、エージェント間のスムーズな切り替えを確実に実行できます。
たとえば、次の PowerShell スクリプトを使用すると、RawData、FilePath、Computer を含むカスタム テーブルを作成できます。 スキーマは受信ストリームの既定のスキーマと一致するため、このテーブルの変換は必要ありません。
$tableParams = @'
{
"properties": {
"schema": {
"name": "{TableName}_CL",
"columns": [
{
"name": "TimeGenerated",
"type": "DateTime"
},
{
"name": "RawData",
"type": "String"
},
{
"name": "FilePath",
"type": "String"
},
{
"name": "Computer",
"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
テキスト ファイルのデータ収集ルールを作成する
Azure Monitor エージェントを使用したデータの収集に関するページの説明に従って、データ収集ルールを作成します。 [収集と配信] 手順で、[データ ソースの種類] ドロップダウンから [カスタム テキスト ログ] を選択します。
| 設定 | 説明 |
|---|---|
| ファイル パターン | ローカル ディスク上のログ ファイルの場所と名前を確認します。 新しい名前で毎日新しいファイルが作成される場合など、異なるファイル名にはワイルドカードを使用します。 複数のファイル パターンをコンマで区切って入力できます。 例 : - C:\Logs\MyLog.txt - C:\Logs\MyLog*.txt - C:\App01\AppLog.txt, C:\App02\AppLog.txt - /var/mylog.log - /var/mylog*.log |
| テーブル名 | Log Analytics ワークスペースの宛先テーブルの名前。 |
| レコードの区切り記号 | 現在は使用されていませんが、将来の使用のために予約されており、現在サポートされている行末以外の区切り記号 (/r/n) を許可します。 |
| 変換 | インジェスト時の変換を行ってレコードをフィルター処理したり、変換先テーブルの受信データを書式設定したりします。 source を使用して、受信データを変更せずに残します。 |
区切りログ ファイル
多くのテキスト ログ ファイルには、コンマなどの文字で区切られたエントリがあります。 このデータを個別の列に分割するには、分割関数で変換を使用します。
たとえば、次のコンマ区切りのデータを含むテキスト ファイルについて考えてみます。 これらのフィールドは、Time、Code、Severity、Module、および Message として記述できます。
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.
次の変換により、データが個別の列に解析されます。 split は動的データを返すので、tostring や toint などの関数を使用して、データを正しいスカラー型に変換する必要があります。 また、ターゲット テーブル内の列名と一致する各エントリの名前を指定する必要もあります。 この例では、TimeGenerated 値が設定されることに注意してください。 これが指定されていない場合は、インジェスト時間が使用されます。
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])
ログ クエリでこのデータを取得すると、次の結果が返されます。
トラブルシューティング
想定しているテキスト ログからデータを収集しない場合は、次の手順を実行します。
- 収集されるログ ファイルにデータが書き込まれていることを確認します。
- ログ ファイルの名前と場所が、指定したファイル パターンと一致することを確認します。
- ターゲット テーブルのスキーマが受信ストリームと一致していること、または受信ストリームを正しいスキーマに変換する変換があることを確認します。
- 「操作の確認」を参照して、エージェントが動作していて、データが受信されているかどうかを確認します。
次のステップ
各項目の詳細情報