ログはITシステムに不可欠なコンポーネントで、次のすべてにおいて有用です。

• インフラストラクチャパフォーマンスのモニタリング
• アプリケーションバグの検知
• 根本原因分析の実施
• セキュリティインシデントの調査
• ユーザーの振る舞いの追跡
• その他

ログを十分に活用するには、さまざまな構造化形式と非構造化形式に対処できる堅牢なログ管理システムが必要です。

適切に設計されたログ管理ソリューションは、形式に関係なくログの取り込み、解析、保存を行います。つまり、さまざまなシステムからデータを検索、分析、相関付けて、傾向を見つけたり、ダッシュボードを作成したり、アラートをトリガーしたりして、ビジネスプロセスを改善できます。

この記事では、一般的なログ形式について説明し、ITシステム全体で一般的に使用されるログ形式をいくつか紹介します。

ログ形式の簡単な紹介

ログ形式では、ログファイルの内容の解釈方法を定義します。通常、形式は次のことを示します。

• ログの内容が構造化されているかどうか
• データがプレーンテキストかバイナリか
• ログファイルで使用されるエンコーディングの種類
• レコードの区切り方法

ログ形式では、ログファイルに含まれるフィールドや、それらのフィールドのデータ型を定義することもできます。例えば、name=textやage=numberなどです。タイムスタンプなどの特殊なフィールドは、通常、事前定義された形式で表示されます（例えば、ISO 8601では2022-07-10 15:21:00.000と表示されます）。

通常、アプリケーションでは使用可能なログ形式を定義します。アプリケーションによっては、ユーザーが形式（JSONやCSVなど）を選択できる場合があります。ハードウェアデバイスの場合は、通常は製造元が使用するログタイプを定義します。

構造化ログ、半構造化ログ、非構造化ログ

ログファイルは、構造化形式、半構造化形式、または非構造化形式です。

構造化ログ形式は、パターンが明確で一貫しており、人間と機械が読み取ることができます。複数のフィールドは、カンマ（CSVファイルなど）、スペース、ハイフンなどの文字で区切られることがあります。また、等号（=）で結合することもできます（例：name=Jane、city=Paris）。

ほとんどのログ管理システムには、事前設定されたパーサーが組み込まれており、構造化ログ形式を簡単に取り込むことができます。構造化ログファイルの例を次に示します。

[{
"Env" : "Prod",
"ServerName" : "LAPTOP123",
"AppName" : "Console1.vmhost.exe",
"AppLoc" : "C:Teststackify-api-dotnetdstConsoleApplication1binDebugConsole1.vmhost.exe",
"Logger" : "StackifyLib.net",
"Msgs" : [{
"Msg" : "Incoming metrics data",
"data" : "{"clientid":12345}",
"EpochMs" : 1445345672470,
"Level" : "INFO",
"id" : "0c12301b-e4ge-11e6-8933-897567896a4"
}]
}]

非構造化ログ形式は、特定のパターンを使用しませんが、人間が読みやすい形式です。これにより、解析中にイベントを分割してキーと値のペアを抽出するのが難しくなります。ログ管理システムにパーサーが組み込まれていない場合、非構造化ログにはカスタム解析が必要になり、エンジニアにとって追加の作業が発生することがよくあります。

2018-10-25 11:56:35,008 INFO  [LAPTOP321-1-3]  c.a.c.d.RFC4519DirectoryMembershipsIterable Found 7 children for 7 groups in 2 ms
Starting process to remove.
Process started.
Process completed.

半構造化ログは、人間が読みやすい形式であるだけでなく、スキーマやパターンがあるため機械も読むことができる形式です。フィールドとイベントの区切り文字はカンマや等号よりも複雑ですが、パターンがあります。ログ管理システムは、半構造化ログを取り込むことができますが、通常はイベントを分割してキーと値のペアを抽出したりするためのパーサーが必要です。通常、これは正規表現やその他のコードを使用して行われます。

一般的に使用されるログ形式

ログ形式は、システム、アプリケーション、ツールによって大きく異なりますが、特定のログ形式が一般的に使用されます。注目すべき形式を詳しく見ていきましょう。

JSON

JavaScript Object Notation (JSON) は、最も一般的に使用されるログ形式の1つです。JSONログは半構造化ログで、キーと値のペアが複数含まれています。JSONでは、ログは人間が読みやすい形式を維持したままデータを異なるレイヤーにネストできます。JSONには、文字列、数値、ブール値、null/空、オブジェクト、配列などのデータ型を維持する方法も用意されています。

比較的新しい形式として、JSONは保存中と転送中に通常はUTF-8エンコーディングを使用するため、*nixとWindowsの両方のオペレーティングシステムからアクセスできます。含めることができるフィールドの数や型に制限はありません。NoSQL（またはスキーマレス）データベースと良好に連携しますが、アプリケーションとログソースの間でフィールドの型の一貫性を確保するためにログ作成者側で追加の作業が必要になることがあります。

JSONログファイルの例を次に示します。

{
"timestamp": "2022-07-29T02:03:45.293Z",
"message": "User Jane.Doe has logged in",
"log": {
"level": "info",
"file": "auth.c",
"line": 66,
},
"user": {
"name": "jane.doe",
"id": 235
},
"event": {
"success": true
}
}

Windowsイベントログ

Windowsイベントログには、Windowsオペレーティングシステムで発生したイベントに関連するデータが含まれています。Windowsイベントログの例として、セキュリティ、アプリケーション、システム、DNSのイベントがあり、すべてにおいて同じログ形式が使用されます。

多くの場合、Windowsイベントログは、システムやアプリケーションのエラーのトラブルシューティング、セキュリティインシデントの調査、ユーザーログインの追跡のためにシステム管理者が使用します。通常は非常に詳細で、タイムスタンプ、イベントID、ユーザー名、ホスト名、メッセージ、タスクカテゴリなどの情報が含まれます。

Windowsイベントログの例を次に示します。

An account was successfully logged on.
Subject:
Security ID: SYSTEM
Account Name: DESKTOP-LLHJ389$
Account Domain: WORKGROUP
Logon ID: 0x3E7
Logon Information:
Logon Type: 7
Restricted Admin Mode: -
Virtual Account: No
Elevated Token: No
Impersonation Level: Impersonation
New Logon:
Security ID: AzureADRandyFranklinSmith
Account Name: rsmith@montereytechgroup.com
Account Domain: AzureAD
Logon ID: 0xFD5113F
Linked Logon ID: 0xFD5112A
Network Account Name: -
Network Account Domain: -
Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information:
Process ID: 0x30c
Process Name: C:WindowsSystem32lsass.exe
Network Information:
Workstation Name: DESKTOP-LLHJ389
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Negotiate
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

CEF

共通イベント形式 (CEF) は、セキュリティ関連のデバイスとアプリケーションによって使用されるオープンなテキストベースのログ形式です。CEFはArcSight Enterprise Security Managerによって開発され、SIEMやログ管理システムによるデータの収集および集約で使用されます。

CEFログでは、UTF-8エンコーディングが使用され、共通のプレフィックス、CEFヘッダー、キーと値のペアのリストを含む可変拡張子が含まれます。

プレフィックスには、イベントのタイムスタンプとホスト名が含まれます。ヘッダーには、CEFソフトウェアバージョン、デバイスベンダー、デバイス製品、デバイスバージョン、デバイスイベントクラスID、名前、重大度が含まれます。ログメッセージの残りの部分は、内容を拡充するための追加カスタムフィールドで構成されます。

CEFを使用するエントリの例を次に示します。

CEF:0|Trend Micro|Deep Security Manager||600|User Signed In|3|src=10.52.116.160 suser=admin target=admin msg=User signed in from 2001:db8::5

CLF

NCSA Common Log Format (CLF) は、Webサーバーで使用される最も古いログ形式です。標準化されたテキストベースのログファイルで、固定形式であるためフィールドをカスタマイズできません。ログファイルの各行には次のものが含まれます。

• リモートホストアドレス
• リモートログ名
• ユーザー名
• タイムスタンプ
• リクエストとプロトコルバージョン
• HTTPステータスコード
• 送信バイト数

そのイベントのデータを含まないフィールドを表すためにハイフンが使用され、プラス記号（+）はサポートされていない文字を表します。

CLFログの例を次に示します。

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

ELF

拡張ログ形式 (ELF) は、Webアプリケーションで使用されます。CLFと似ていますが、より詳細な情報が含まれ、使用されるフィールドに対して柔軟性があります。ELFログには、単一のHTTPトランザクションに関連するデータが含まれています。フィールドは空白で区切られ、ハイフンはフィールドが欠落していることを示します。

ログの先頭には、バージョン、日付、時刻、ソフトウェア、関連コメントに関する情報が含まれています。その前にハッシュ記号（#）が付いています。ログにはフィールド名も含まれているため、ログハンドラーはすべてのフィールドを簡単かつ適切に解析できます。

W3C

W3C拡張ログファイル形式は、高度にカスタマイズ可能なログファイル形式で、Windows IISサーバーで使用されます。含めるフィールドを設定できるため、ログファイルのサイズを縮小したり、関連する情報のみを保持したりするために役立ちます。利用可能なフィールドは次のとおりです。

• タイムスタンプ
• クライアントIP
• サーバーIP
• URIステム
• HTTPステータスコード
• 送信バイト数
• 受信バイト数
• 所要時間
• バージョン

一部のフィールドには、s（サーバー）、c（クライアント）、sc（サーバーからクライアントに対するアクション）、cs（クライアントからサーバーに対するアクション）のプレフィックスが付けられ、サーバー側とクライアント側のどちらに関連しているかを示します。

W3Cログの例を次に示します。

#Software: Internet Information Services 6.0
#Version: 1.0
#Date: 2001-05-02 17:42:15
#Fields: time c-ip cs-method cs-uri-stem sc-status cs-version
17:42:15 172.16.255.255 GET /default.htm 200 HTTP/1.0

次世代SIEMおよびログ管理のための世界をリードするAIネイティブプラットフォームをお試しください

SIEMとログ管理のための最高水準のAIネイティブプラットフォーム、CrowdStrike Falcon^®プラットフォームでサイバーセキュリティを強化しましょう。ペタバイト規模でのセキュリティログを体験してみてください。クラウドネイティブ型または自己ホスト型での展開が可能です。ボトルネックの生じない、強力でインデックスフリーのアーキテクチャを利用してデータをロギングすれば、1日あたり1PB以上のデータを取り込んで脅威ハンティングに役立てることができます。リアルタイムの検索機能により攻撃者をしのぐスピードで対策を実施できます。複雑なクエリを実行しても、そのレイテンシーは1秒未満です。360度の可視性によりデータを統合してサイロ化を解消し、セキュリティ、IT、DevOpsチームがシームレスに脅威のハンティング、パフォーマンスのモニタリング、コンプライアンスの確保を行うことができます。30億件ものイベントにわたる作業でも1秒未満で実施できます。