Azure Monitor で Log Analytics エージェントを使用して テキスト ログを収集する
重要
この記事では、Log Analytics エージェントを使用したファイル ベースのテキスト ログの収集について説明します。 REST API を使用して Azure Monitor ログにデータを送信できるカスタム ログ API と混同しないようにしてください。
Azure Monitor の Log Analytics エージェントのカスタム ログ データ ソースでは、Windows コンピューターと Linux コンピューターの両方のテキスト ファイルからイベントを収集できます。 多くのアプリケーションは、Windows イベント ログや Syslog などの標準のログ記録サービスの代わりに、テキスト ファイルに情報を記録します。 収集されたデータは、クエリで解析して個別のフィールドに格納するか、または収集時に個別のフィールドに抽出することができます。
重要
この記事では、Log Analytics エージェントを使用したテキスト ログの収集について説明します。 Azure Monitor エージェントを使用したテキスト ログの収集の詳細については、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 によりその重複が収集されます。 ただし、フィルター結果に示されるイベント数がクエリ結果の件数より多いという矛盾が生じます。 重要になるのは、ログを検証して、そのログを作成したアプリケーションがこの動作を引き起こしているかどうか、また、これに対処できるかどうかを、カスタム ログ収集の定義を作成する前に判断することです。
Note
Log Analytics ワークスペースでのサポートには次の制限があります。
- 作成できるカスタム ログの数は 500 個のみです。
- テーブルでサポートされる最大列数は 500 列のみです。
- 列名の最大文字数は 500 です。
重要
カスタム ログの収集では、ログ ファイルを書き込むアプリケーションによって、ログのコンテンツがディスクに定期的にフラッシュされる必要があります。 これは、カスタム ログの収集が、追跡されているログ ファイルのファイル システムの変更通知に依存しているためです。
カスタム ログを定義する
次の手順でカスタム ログ ファイルを定義できます。 この記事の最後にカスタム ログ追加のサンプル チュートリアルがあります。
手順 1. カスタム ログ ウィザードを開く
カスタム ログ ウィザードは Azure Portal で実行され、収集する新しいカスタム ログを定義できます。
- Azure portal で、[Log Analytics ワークスペース]、>目的のワークスペース>、[設定] の順に選択します。
- [カスタム ログ] をクリックします。
- 既定では、すべての構成変更はすべてのエージェントに自動的にプッシュされます。 Linux エージェントの場合、構成ファイルが Fluentd データ コレクターに送信されます。
- [追加+] をクリックし、カスタム ログ ウィザードを開きます。
手順 2. サンプル ログをアップロードし、解析する
始めにカスタム ログのサンプルをアップロードします。 ユーザーが評価できるように、ウィザードはこのファイルのエントリを解析して表示します。 Azure Monitor はユーザーが指定した区切り記号を利用して各レコードを識別します。
改行が既定の区切り記号であり、1 行につき 1 エントリのログ ファイルに利用されます。 利用可能な形式の 1 つで表現された日付と時刻で行が始まるとき、区切り記号としてタイムスタンプを指定できます。その場合、1 行以上のエントリに対応します。
区切り記号としてタイムスタンプが使用されるとき、Azure Monitor に保存される各レコードの TimeGenerated プロパティに、ログ ファイルでそのエントリに指定された日付/時刻が入力されます。 区切り記号として改行が使用される場合、Azure Monitor がエントリを収集した日付と時刻が TimeGenerated に入力されます。
- [閲覧] をクリックし、サンプル ファイルを表示します。 一部のブラウザーでは、このボタンのラベルは [ファイルの選択] になっていることがあります。
- [次へ] をクリックします。
- カスタム ログ ウィザードはファイルをアップロードし、識別したレコードを一覧表示します。
- 新しいレコードの識別に使用される区切り記号を変更し、ログ ファイルのレコードを最も効率的に識別する区切り記号を選択します。
- [次へ] をクリックします。
手順 3. ログのコレクション パスを追加する
エージェントに 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 を選択し、追加するパス書式を指定します。
- パスを入力し、 + ボタンをクリックします。
- 追加のパスがあれば、以上のプロセスを繰り返します。
手順 4. ログの名前と説明を指定する
指定した名前は上述の種類のログに使用されます。 カスタム ログとして区別されるように常に _CL で終わります。
- ログの名前を入力します。 _CL が接尾辞として自動的に追加されます。
- 任意で [説明] を追加します。
- [次へ] をクリックし、カスタム ログ定義を保存します。
手順 5. カスタム ログが収集されていることを確認する
新しいカスタム ログの最初のデータが Azure Monitor に表示されるまで最大 1 時間かかることがあります。 指定されたパスにあるログからエントリの収集が始まります。カスタム ログに定義されているポイントから開始されます。 カスタム ログ作成中にアップロードしたエントリは保持されませんが、ログ ファイルに既に存在するエントリが収集されます。
Azure Monitor がカスタム ログから収集を始めると、そのレコードがログ クエリで利用できるようになります。 クエリの [種類] としてカスタム ログに指定した名前を使用します。
Note
RawData プロパティがクエリに表示されない場合、ブラウザーを閉じて再び開いてみてください。
手順 6. カスタム ログ エントリを解析する
ログ エントリ全体は、 RawDataと呼ばれる 1 つのプロパティに格納されます。 それぞれのエントリに含まれる異なる情報を、各レコードの個別のプロパティに分けたいと考えるケースが大半でしょう。 RawData を解析して複数のプロパティに格納する方法については、Azure Monitor でのテキスト データの解析に関するページを参照してください。
カスタム ログの削除
Azure Portal で次のプロセスを使用して、これまでに定義したカスタム ログを削除します。
- ワークスペースの [詳細設定] 内の [データ] メニューから [カスタム ログ] を選択して、すべてのカスタム ログを一覧表示します。
- 削除するカスタム ログの横にある [削除] をクリックします。
データ コレクション
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 でのテキスト データの解析に関するページを参照してください。
- ログ クエリについて学習し、データ ソースとソリューションから収集されたデータを分析します。