こんにちは。オブザーバビリティの世界へようこそ。
現場でトラブルが起きたとき、真っ先に頼りになるのは「ログ」です。しかし、バラバラの形式で出力されたログを、ただ眺めるだけで終わっていませんか？
「grepで必死に文字列を探す」そんな苦行は今日で卒業しましょう。Datadogのログ管理（Log Management）を使いこなし、「ログをデータとして扱う」技術を身につければ、障害調査は「探す作業」から「クエリを投げて答えを得る作業」に劇的に進化します。
今日は、そのための第一歩である「パース（構造化）」と「リマップ」の神髄を、現場の視点から解説します。
—
1. なぜ「ログの構造化」が必要なのか？
ただのテキストファイルとしてのログは、コンピューターにとっては単なる「長い文字列」です。
しかし、JSONのように「キー」と「値」が分かれていれば、Datadogはそれを理解し、「特定のユーザーIDで絞り込む」「エラー率をグラフ化する」といった分析が可能になります。
この「ただの文字列」を「意味のあるデータ」に変換する魔法こそが、DatadogのPipeline（パイプライン）です。
—
2. 基本セットアップ：ログを流し込む
まずは、あなたのアプリケーションがDatadogにログを送っている状態を作りましょう。最も簡単なのは、Datadog Agentをインストールし、設定ファイル（`conf.yaml`）でログ収集を有効にすることです。
`conf.yaml` の設定例:
logs:
- type: file
path: /var/log/myapp.log
service: my-cool-service # サービス名を明示するのが鉄則です
source: python # 言語を指定すると、Datadogが標準的なパースを試みます
これを設定して再起動するだけで、DatadogのLog Explorerにログが届き始めます。これが「HelloWorld」の第一歩です。
—
3. Pipelineでログを「解剖」する
ログが届いても、まだ中身が文字列のままなら、ここからが本番です。Datadogの [Logs > Configuration > Pipelines] に移動しましょう。
ステップ1：Grok Parserで構造化する
Grokは、正規表現を人間が読みやすくしたようなパターンマッチングツールです。
例えば、ログが `2023-10-27 10:00:00 [ERROR] User 123 failed to login` という形式なら、以下のパターンを定義します。
Grokパターンの書き方:
ログ形式に合わせてパターンを記述
%{date(“yyyy-MM-dd HH:mm:ss”):timestamp} \[%{log.level:word}\] User %{integer:user_id} failed to login
これを通すと、`timestamp`、`log.level`、`user_id` が個別の属性として抽出されます。これで検索ボックスに `user_id:123` と打つだけで、そのユーザーのログだけを瞬時に抜き出せるようになります。
ステップ2：リマッパー（Remapper）で正規化する
ログに出力される「時刻」や「ステータス」の名称は、システムによってバラバラです。
- あるログは `status_code`、あるログは `http_code` と書かれている…。
- これでは集計できません。
ここで Category Processor や Attribute Remapper を使います。
`http_code` を `http.status_code` という「共通の属性」にリマップするのです。こうすることで、異なるマイクロサービス間で「HTTP 500エラー」を一括して横断検索できるようになります。
—
4. 現場で震えるほど役立つ「3つの鉄則」
パース設定を構築する際、以下の3点を意識するだけで、あなたの監視レベルは一段階上がります。
1. 「属性名」を統一せよ
- `user_id`, `request_id`, `duration_ms` など、全サービスで共通の名前を使いましょう。これが後のダッシュボード作成を驚くほど楽にします。
2. 「やりすぎない」パース
- すべてのログをJSONにする必要はありません。頻繁に検索・分析する重要な項目だけをパースしてください。過剰なパースはコスト増につながります。
3. テスト機能を使い倒せ
- Pipelineの設定画面には「Test」ボタンがあります。本番環境に反映する前に、必ずサンプルログを投入して正しくパースされるか確認する癖をつけましょう。
—
まとめ：ログは「未来のあなたへの手紙」
ログをパースして構造化しておくことは、将来トラブルが起きたとき、真っ暗な部屋の中で懐中電灯を照らしてもらうようなものです。
まずは、一つのログソースを完璧にパースすることから始めてみてください。それができるようになったとき、あなたはもう「ログに振り回されるエンジニア」ではなく、「データを自在に操るオブザーバビリティ・エンジニア」への階段を登り始めています。
毎日の運用が、「調査」ではなく「確認」に変わる喜びを、ぜひ体験してください。何か詰まったら、いつでも聞きに来てくださいね。応援しています！