Azure Monitor で Log Analytics エージェントを使用してテキスト ログを収集する
Azure Monitor の Log Analytics エージェントのカスタム ログ データ ソースでは、Windows コンピューターと Linux コンピューターの両方のテキスト ファイルからイベントを収集できます。 多くのアプリケーションは、Windows イベント ログや Syslog などの標準のログ記録サービスの代わりに、テキスト ファイルに情報を記録します。 データを収集した後、それをクエリで解析して個別のフィールドに格納するか、または収集時に個別のフィールドに抽出することができます。
重要
この記事では、Log Analytics エージェントでテキスト ログを収集する方法について説明します。 Azure Monitor エージェントを使用している場合は、「Azure Monitor エージェントを使用してテキスト ログを収集する」をご覧ください。
重要
レガシの Log Analytics エージェントは、2024 年 8 月 31 日の時点で非推奨となっています。 今後 Microsoft は、Log Analytics エージェントに関するすべてのサポートを提供しません。 Azure Monitor にデータを取り込むために Log Analytics エージェントを使用している場合は、今すぐ Azure Monitor エージェントに移行してください。
収集するログ ファイルは、次の条件に一致する必要があります。
ログでは 1 行につき 1 エントリとするか、各エントリの先頭に次のいずれかの形式に一致するタイムスタンプを使用する必要があります。
YYYY-MM-DD HH:MM:SS
M/D/YYYY HH:MM:SS AM/PM
Mon DD, YYYY HH:MM:SS
yyMMdd HH:mm:ss
ddMMyy HH:mm:ss
MMM d hh:mm:ss
dd/MMM/yyyy:HH:mm:ss zzz
yyyy-MM-ddTHH:mm:ssKログ ファイルでは、循環ログを許可しないでください。 この動作はログ ローテーションであり、ファイルが新しいエントリで上書きされるか、ファイル名が変更され、同じファイル名が継続的なログ記録に再利用されます。
ログ ファイルでは、ASCII または UTF-8 エンコードを使用する必要があります。 UTF-16 など他の形式はサポートされていません。
Linux の場合、ログのタイム スタンプについてタイム ゾーンの変換はサポートされていません。
ベスト プラクティスとして、ログのローテーションによる上書きまたは名前変更を防ぐために、ログ ファイルには作成された日時を含める必要があります。
Note
ログ ファイルに重複するエントリがあると、Azure Monitor によりその重複が収集されます。 生成されるクエリ結果に一貫性がなくなります。 フィルターの結果には、結果の数よりも多くのイベントが表示されます。 ログを検証して、それを作成するアプリケーションがこの動作を引き起こしているかどうかを判断する必要があります。 カスタム ログ収集の定義を作成する前に、可能な限り問題に対処してください。
Log Analytics ワークスペースでのサポートには次の制限があります。
- 作成できるカスタム ログの数は 500 個のみです。
- テーブルでサポートされる最大列数は 500 列のみです。
- 列名の最大文字数は 500 です。
重要
カスタム ログの収集では、ログ ファイルを書き込むアプリケーションによって、ログのコンテンツがディスクに定期的にフラッシュされる必要があります。 これは、カスタム ログの収集が、追跡されているログ ファイルのファイル システムの変更通知に依存しているためです。
カスタム ログ テーブルを定義する
次の手順でカスタム ログ テーブルを定義できます。 この記事の最後にカスタム ログ追加のサンプル チュートリアルがあります。
カスタム ログ ウィザードを開く
カスタム ログ ウィザードは Azure portal で実行され、収集する新しいカスタム ログを定義できます。
Azure portal で、[Log Analytics ワークスペース]>[目的のワークスペース]>[テーブル] の順に選択します。
[作成] を選択してから、[新しいカスタム ログ (MMA ベース)] を選択します。
既定では、すべての構成変更はすべてのエージェントに自動的にプッシュされます。 Linux エージェントの場合、構成ファイルが Fluentd データ コレクターに送信されます。
サンプル ログをアップロードし、解析する
最初に、カスタム ログのサンプルをアップロードします。 ユーザーが評価できるように、ウィザードはこのファイルのエントリを解析して表示します。 Azure Monitor はユーザーが指定した区切り記号を利用して各レコードを識別します。
改行が既定の区切り記号であり、1 行につき 1 エントリのログ ファイルに利用されます。 利用可能な形式の 1 つで表現された日付と時刻で行が始まるとき、区切り記号としてタイムスタンプを指定できます。その場合、1 行以上のエントリに対応します。
区切り記号としてタイムスタンプが使用されるとき、Azure Monitor に保存される各レコードの TimeGenerated プロパティに、ログ ファイルでそのエントリに指定された日時が入力されます。 区切り記号として改行が使用される場合、Azure Monitor がエントリを収集した日時が TimeGenerated に入力されます。
[閲覧] を選択し、サンプル ファイルを表示します。 一部のブラウザーでは、このボタンのラベルは [ファイルの選択] になっていることがあります。
[次へ] を選択します。
カスタム ログ ウィザードはファイルをアップロードし、識別したレコードを一覧表示します。
新しいレコードを識別するために使用する区切り記号を変更します。 ログ ファイル内のレコードを最も適切に識別できる区切り記号を選択します。
[次へ] を選択します。
ログのコレクション パスを追加する
エージェントに 1 つまたは複数のパスを定義する必要があります。エージェントがカスタム ログを見つける場所です。 ログ ファイルの特定のパスと名前を入力するか、名前にワイルドカードを含むパスを指定できます。 このステップは、毎日新しいファイルを作成するアプリケーションに対応し、1 つのファイルが一定のサイズに到達した場合にも対応します。 また、1 つのログ ファイルに複数のパスを指定できます。
たとえば、ログ ファイルを毎日作成するアプリケーションがあります。log20100316.txt のように、名前に日付を含めます。 このようなログのパターンは、たとえば、log*.txt になります。このアプリケーションの命名規則に従うあらゆるログ ファイルに適用されます。
次の表は、異なるログ ファイルを指定する有効なパターンの例をまとめたものです。
| 説明 | Path |
|---|---|
| Windows エージェントの C:\Logs にあり、拡張子が .txt のすべてのファイル | C:\Logs\*.txt |
| Windows エージェントの C:\Logs にあり、名前が log で始まり、拡張子が .txt のすべてのファイル | C:\Logs\log*.txt |
| Linux エージェントの /var/log/audit にあり、拡張子が .txt のすべてのファイル | /var/log/audit/*.txt |
| Linux エージェントの /var/log/audit にあり、名前が log で始まり、拡張子が .txt のすべてのファイル | /var/log/audit/log*.txt |
- Windows または Linux を選択し、追加するパス書式を指定します。
- パスを入力し、+ ボタンを選択します。
- 追加のパスがある場合は、このプロセスを繰り返します。
ログの名前と説明を指定する
指定した名前は上述の種類のログに使用されます。 カスタム ログとして区別されるように常に _CL で終わります。
- ログの名前を入力します。 _CL が接尾辞として自動的に追加されます。
- 任意で [説明] を追加します。
- [次へ] を選択し、カスタム ログ定義を保存します。
カスタム ログが収集されていることを確認する
新しいカスタム ログの最初のデータが Azure Monitor に表示されるまで最大 1 時間かかることがあります。 Azure Monitor は、指定されたパスにあるログの、カスタム ログに定義されているポイントからエントリの収集を開始します。 カスタム ログの作成時にアップロードしたエントリは保持されません。 特定したログ ファイル内の既存のエントリを収集します。
Azure Monitor がカスタム ログから収集を始めると、そのレコードがログ クエリで利用できるようになります。 クエリの [種類] としてカスタム ログに指定した名前を使用します。
Note
RawData プロパティがクエリに表示されない場合、ブラウザーを閉じて再び開いてみてください。
カスタム ログ エントリを解析する
ログ エントリ全体は、 RawDataと呼ばれる 1 つのプロパティに格納されます。 それぞれのエントリに含まれる異なる情報を、各レコードの個別のプロパティに分けたいと考えるケースが大半でしょう。 RawData を解析して複数のプロパティに格納する方法については、Azure Monitor でのテキスト データの解析に関するページを参照してください。
カスタム ログ テーブルを削除する
[テーブルを削除する] を参照してください。
データ コレクション
Azure Monitor は約 5 分おきに各カスタム ログから新しいエントリを収集します。 エージェントは、収集元の場所を各ログ ファイルに記録します。 エージェントが一定時間オフラインになった場合、Azure Monitor は、オフライン中に作成されたエントリも含めて、中止した箇所からエントリを収集します。
ログ エントリのコンテンツ全体は RawData という名前の 1 つのプロパティに書き込まれます。 インポートした各ログ エントリを解析して複数のプロパティに格納する方法については、Azure Monitor でのテキスト データの解析に関するページを参照してください。
カスタム ログ レコードのプロパティ
カスタム ログ レコードには、種類、ユーザーが指定するログ名、次の表にあるプロパティが与えられます。
| プロパティ | 説明 |
|---|---|
| TimeGenerated | Azure Monitor がレコードを収集した日付と時刻。 ログが時刻ベースの区切り記号を使用する場合、これはエントリから収集された時間になります。 |
| SourceSystem | レコードが収集されたエージェントの種類。 OpsManager – Windows エージェント、直接接続または System Center Operations Manager Linux – すべての Linux エージェント |
| RawData | 収集されたエントリの完全テキスト。 このデータを解析して個別のプロパティに格納するのが最も一般的です。 |
| ManagementGroupName | System Center Operations Manager エージェントの管理グループの名前。 その他のエージェントの場合、この名前は AOI-<workspace ID> です。 |
カスタム ログ追加のサンプル チュートリアル
次のセクションでは、カスタム ログの作成例を段階的に説明します。 収集されるサンプル ログには 1 行につき 1 エントリが与えられます。これは日時で始まり、コード、状態、メッセージがコンマで区切られて続きます。 いくつかのサンプルのエントリを示します。
2019-08-27 01:34:36 207,Success,Client 05a26a97-272a-4bc9-8f64-269d154b0e39 connected
2019-08-27 01:33:33 208,Warning,Client ec53d95c-1c88-41ae-8174-92104212de5d disconnected
2019-08-27 01:35:44 209,Success,Transaction 10d65890-b003-48f8-9cfc-9c74b51189c8 succeeded
2019-08-27 01:38:22 302,Error,Application could not connect to database
2019-08-27 01:31:34 303,Error,Application lost connection to database
サンプル ログをアップロードし、解析する
ログ ファイルの 1 つをお見せします。ログ ファイルで収集されているイベントを確認できます。 この例の場合、区切り記号には改行を選択して問題ありません。 ログの 1 エントリが複数行にまたがるようであれば、区切り記号としてタイムスタンプを使用する必要があります。
ログのコレクション パスを追加する
ログ ファイルは C:\MyApp\Logs に置かれます。 新しいファイルが毎日作成されます。名前には日付が含まれ、appYYYYMMDD.log というパターンになります。 このログには C:\MyApp\Logs\*.log というパターンを使えばよいでしょう。
ログの名前と説明を指定する
MyApp_CL という名前を使用し、 [説明] に入力します。
カスタム ログが収集されていることを確認する
収集されたログからすべてのレコードを返す MyApp_CL という単純なクエリを使用します。
カスタム ログの代替手段
一覧表示されている条件をデータが満たす場合はカスタム ログが便利ですが、次のような場合には、別の方法が必要になることもあります。
- タイムスタンプの形式が異なるなど、求められる構造にデータが適合していない。
- ファイル エンコードや非対応のフォルダー構造などの要件をログ ファイルが満たさない。
- データの収集前に事前処理やフィルター処理が必要である。
カスタム ログではデータを収集できない場合、次の代替手段を検討してください。
- カスタム スクリプトまたはその他の手法を使用し、Azure Monitor によって収集される Windows イベントまたは Syslog にデータを書き込む。
- HTTP Data Collector API を使用して Azure Monitor に直接データを送信する。
次のステップ
- インポートした各ログ エントリを解析して複数のプロパティに格納する方法については、Azure Monitor でのテキスト データの解析に関するページを参照してください。
- ログ クエリについて学習し、データ ソースとソリューションから収集されたデータを分析します。