Azure Monitor の Log Analytics エージェントのカスタム ログ データ ソースを使用すると、Windows コンピューターと Linux コンピューターの両方のテキスト ファイルからイベントを収集できます。 多くのアプリケーションでは、Windows イベント ログや Syslog などの標準的なログ サービスではなく、テキスト ファイルに情報を記録します。 データが収集されたら、クエリ内の個々のフィールドに解析するか、コレクション中に個々のフィールドに抽出することができます。
Important
この記事では、Log Analytics エージェントでテキスト ログを収集する方法について説明します。 Azure Monitor エージェントを使用している場合は、「Azure Monitor エージェントを使用して テキスト ログを収集する」を参照してください。
Important
従来の Log Analytics エージェントは、2024 年 8 月 31 日の時点で非推奨となっています。 Microsoft は Log Analytics エージェントのサポートを提供しなくなります。 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 の場合、ログ内のタイム スタンプではタイム ゾーン変換はサポートされていません。
ベスト プラクティスとして、ログ ファイルには、ログローテーションの上書きや名前変更を防ぐために作成された日付と時刻を含める必要があります。
注
ログ ファイルに重複するエントリがある場合、Azure Monitor によってそれらのエントリが収集されます。 生成されるクエリ結果に一貫性がありません。 フィルターの結果には、結果の数よりも多くのイベントが表示されます。 ログを検証して、ログを作成するアプリケーションがこの動作を引き起こしているかどうかを判断する必要があります。 カスタム ログ コレクション定義を作成する前に、可能な場合は問題に対処してください。
Log Analytics ワークスペースでは、次の制限がサポートされています。
- 作成できるカスタム ログは 500 個のみです。
- テーブルでは、最大 500 個の列のみがサポートされます。
- 列名の最大文字数は 500 文字です。
Important
カスタム ログ収集では、ログ ファイルを書き込むアプリケーションがログの内容をディスクに定期的にフラッシュする必要があります。 これは、カスタム ログ コレクションが追跡対象のログ ファイルのファイル システム変更通知に依存しているためです。
カスタム ログ テーブルを定義する
カスタム ログ テーブルを定義するには、次の手順に従います。 カスタム ログを追加するサンプルのチュートリアルについては、この記事の最後までスクロールしてください。
カスタム ログ ウィザードを開く
カスタム ログ ウィザードは Azure portal で実行され、収集する新しいカスタム ログを定義できます。
Azure ポータルで、Log Analytics ワークスペースを選択し、>のテーブルを選びます。
[ 作成 ] を選択し、[ 新しいカスタム ログ (MMA ベース)] を選択します。
既定では、すべての構成変更がすべてのエージェントに自動的にプッシュされます。 Linux エージェントの場合、構成ファイルは Fluentd データ コレクターに送信されます。
サンプル ログをアップロードして解析する
開始するには、カスタム ログのサンプルをアップロードします。 このファイル内のエントリを解析して表示し、検証します。 Azure Monitor では、指定した区切り記号を使用して各レコードを識別します。
新しい行 は既定の区切り記号であり、1 行に 1 つのエントリがあるログ ファイルに使用されます。 行が使用可能な形式のいずれかで日付と時刻で始まる場合は、複数の行にまたがるエントリをサポートする タイムスタンプ 区切り記号を指定できます。
タイムスタンプ区切り記号が使用されている場合、Azure Monitor に格納されている各レコードの TimeGenerated プロパティには、ログ ファイル内のそのエントリに指定された日付と時刻が設定されます。 新しい行区切り記号が使用されている場合、TimeGenerated には、Azure Monitor がエントリを収集した日時が設定されます。
[ 参照] を選択し、サンプル ファイルを参照します。 一部のブラウザーでは、このボタンに [ ファイルの選択] というラベルが付く場合があります。
[次へ] を選択します。
カスタム ログ ウィザードでは、ファイルがアップロードされ、識別されたレコードが一覧表示されます。
新しいレコードを識別するために使用する区切り記号を変更します。 ログ ファイル内のレコードを最もよく識別する区切り記号を選択します。
[次へ] を選択します。
ログ 収集パスを追加する
エージェントでカスタム ログを検索できる 1 つ以上のパスを定義する必要があります。 ログ ファイルの特定のパスと名前を指定することも、名前にワイルドカードを使用してパスを指定することもできます。 この手順では、毎日、または 1 つのファイルが特定のサイズに達したときに新しいファイルを作成するアプリケーションをサポートします。 1 つのログ ファイルに複数のパスを指定することもできます。
たとえば、アプリケーションでは、log20100316.txtのように、名前に含まれる日付を含むログ ファイルを毎日作成できます。 このようなログのパターンは 、log*.txtである可能性があります。これは、アプリケーションの名前付けスキームに従う任意のログ ファイルに適用されます。
次の表に、異なるログ ファイルを指定する有効なパターンの例を示します。
| Description | 経路 |
|---|---|
| Windows エージェントで拡張子が .txt されている C:\Logs 内のすべてのファイル | C:\Logs\*.txt |
| Windows エージェントで、C:\Logs にあるログで始まり、拡張子が .txt の名前を持つすべてのファイル | C:\Logs\log*.txt |
| Linux エージェントの/var/log/audit 内にある .txt 拡張子のすべてのファイル。 | /var/log/audit/*.txt |
| /var/log/audit 内のすべてのファイルで、名前が log で始まり、Linux エージェント上の .txt 拡張子が付いています | /var/log/audit/log*.txt |
- 追加するパス形式を指定するには、Windows または Linux を選択します。
- パスを入力し、[ + ] ボタンを選択します。
- それ以上のパスに対してプロセスを繰り返します。
ログの名前と説明を入力します
指定した名前は、説明に従ってログの種類に使用されます。 カスタム ログとして区別するために、常に_CLで終了します。
- ログの名前を入力します。 _CLサフィックスは自動的に指定されます。
- 省略可能な 説明を追加します。
- [ 次へ ] を選択してカスタム ログ定義を保存します。
カスタム ログが収集されていることを検証する
新しいカスタム ログの初期データが Azure Monitor に表示されるまでに最大 1 時間かかる場合があります。 Azure Monitor は、カスタム ログを定義した時点から指定したパスにあるログからエントリの収集を開始します。 カスタム ログの作成時にアップロードしたエントリは保持されません。 検索したログ ファイル内の既存のエントリが収集されます。
Azure Monitor がカスタム ログからの収集を開始すると、そのレコードはログ クエリで使用できるようになります。 クエリの Type としてカスタム ログに指定した名前を使用します。
注
RawData プロパティがクエリに表示されない場合は、ブラウザーを閉じてから再度開く必要があります。
カスタム ログ エントリを解析する
ログ エントリ全体は、 RawData という 1 つのプロパティに格納されます。 ほとんどの場合、各エントリのさまざまな情報をレコードごとに個別のプロパティに分割する必要があります。 RawData を複数のプロパティに解析するオプションについては、「Azure Monitor でのテキスト データの解析」を参照してください。
カスタム ログ テーブルを削除する
テーブル の削除を参照してください。
データ コレクション
Azure Monitor は、カスタム ログごとに約 5 分ごとに新しいエントリを収集します。 エージェントは、収集する各ログ ファイルにその場所を記録します。 エージェントが一定期間オフラインになった場合、Azure Monitor は、エージェントがオフラインの間にエントリが作成された場合でも、最後に中断した場所からエントリを収集します。
ログ エントリの内容全体は、 RawData という 1 つのプロパティに書き込まれます。 インポートされた各ログ エントリを複数のプロパティに解析する方法については、「 Azure Monitor でのテキスト データの解析」を参照してください。
カスタム ログ レコードのプロパティ
カスタム ログ レコードには、指定したログ名と次の表のプロパティを含む種類があります。
| プロパティ | Description |
|---|---|
| タイムジェネレイテッド | レコードが Azure Monitor によって収集された日付と時刻。 ログで時間ベースの区切り記号が使用されている場合、これはエントリから収集された時刻です。 |
| ソースシステム | レコードが収集されたエージェントの種類。 OpsManager – Windows エージェント(直接接続または System Center Operations Manager) Linux – すべての Linux エージェント |
| RawData | 収集されたエントリのフルテキスト。 ほとんどの場合、 このデータを個々のプロパティに解析する必要があります。 |
| 管理グループ名 | System Center Operations Manager エージェントの管理グループの名前。 他のエージェントの場合、この名前は AOI-<workspace ID> です。 |
カスタム ログの追加のサンプル チュートリアル
次のセクションでは、カスタム ログを作成する例について説明します。 収集されるサンプル ログには、日付と時刻で始まる各行に 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 データ コレクター API を使用して、Azure Monitor に直接データを送信します。
次のステップ
- インポートされた各ログ エントリを複数のプロパティに解析する方法については、 Azure Monitor のテキスト データ の解析に関するページを参照してください。
- データ ソースとソリューションから収集されたデータを分析するための ログ クエリ について説明します。