ログ収集の仕組み ― アプリの記録はどう集まり、どう活かされるのか

ログはアプリケーションの「行動記録」だよ。大きく4つの目的があるんだ。1つ目はデバッグ――バグが起きたとき何が起きていたか追跡できる。2つ目はモニタリング――システムの健康状態をリアルタイムで把握する。3つ目は監査――誰がいつ何をしたかの証拠を残す。そして4つ目がインシデント対応――障害が起きたときに原因を素早く特定するためだね。

実はログには「レベル」があって、重要度で使い分けるんだ。軽い順に DEBUG・INFO・WARN・ERROR・FATAL の5段階。DEBUGは開発中だけ出す詳細な情報、INFOは「ユーザーがログインしました」みたいな正常な出来事、WARNは「ディスク残量が少ないよ」という注意信号、ERRORは処理が失敗した記録、FATALはシステムが動けなくなる致命的な問題だよ。

本番環境でDEBUGを全開にすると、ログの量が爆発してストレージを圧迫するし、本当に大事なERRORが大量のDEBUGに埋もれちゃうんだ。だから本番ではINFO以上だけ出して、問題調査のときだけ一時的にDEBUGを有効にする、というのが一般的だよ。

最近は「構造化ログ」が主流だよ。従来の `2026-04-04 10:05:32 ERROR 注文処理に失敗` みたいなプレーンテキストだと、後から検索するのが大変なんだ。代わりにJSON形式で `{"timestamp":"2026-04-04T10:05:32Z", "level":"ERROR", "service":"order-api", "user_id":"12345", "message":"注文処理に失敗"}` と出力すると、user_idやserviceでフィルタリングできるようになるんだ。

そこで「ログ集約パイプライン」の出番だよ。流れはこうだ。まず各アプリがログを出力する。次にFluentdやFilebeatといった「コレクター」がログを収集して、KafkaやRedisなどの「トランスポート層」を経由してバッファリングする。最後にElasticsearchやS3などの「ストレージ」に格納される。こうすれば何百台のサーバーのログも一か所で検索できるんだ。

ELK StackはElasticsearch・Logstash・Kibanaの頭文字だよ。Logstashがログを受け取って、フォーマット変換やフィルタリングをする「加工係」。Elasticsearchが加工されたログを保存して全文検索できるようにする「検索エンジン」。Kibanaがブラウザ上でログを可視化する「ダッシュボード」だね。最近はLogstashの代わりに軽量なFilebeatを使って、直接Elasticsearchに送る構成も多いよ。

クラウドにはマネージドなログサービスがあるよ。AWSならCloudWatch Logs、GCPならCloud Logging（旧Stackdriver）、横断的に使えるDatadog Logsなどだね。これらはコレクターやストレージの管理をクラウド側がやってくれるから、自分でELK Stackを運用するより圧倒的に楽なんだ。特にサーバーレスやコンテナ環境では、ログが自動で収集される仕組みが組み込まれていることが多いよ。

いい質問だね。ログの保持期間（リテンション）はコストとコンプライアンスのバランスが重要なんだ。DEBUGログは7日で消す、ERRORログは90日保持、監査ログは法令で7年保存が必要、といった具合にレベルや種類で分ける。古いログはS3 Glacierのような安いストレージに移動する「ローテーション」も定番だよ。大規模サービスだとログのストレージ費用が月に数百万円になることもあるから、何を残して何を捨てるかの設計はとても大事だね。

実は現代の運用では「オブザーバビリティの三本柱」と呼ばれる考え方があるんだ。ログ・メトリクス・トレースの3つだよ。メトリクスはCPU使用率やリクエスト数のような数値データ、トレースはリクエストが複数のマイクロサービスをどう通過したかの経路情報だね。この3つを「コリレーションID」で紐づけると、障害の全体像が一発で分かるようになるんだ。

1つのリクエストに対してユニークなIDを振って、ログにもメトリクスにもトレースにもそのIDを記録する仕組みだよ。例えばユーザーの注文リクエストに `req-abc123` というIDを付けると、API→決済サービス→在庫サービス→通知サービスと渡り歩いても、全部 `req-abc123` で検索すれば一連の流れが追える。これがないと、何十ものサービスのログを目視で時刻を頼りにつなぎ合わせることになって地獄なんだ。

あるある。有名な話だと、ある大規模サービスで深夜に障害が起きて、エンジニアが何時間も原因を追っていたんだけど、ログに「どのテナントのリクエストか」を示すフィールドが入っていなかったんだ。結局、全テナントのログを手作業で突き合わせて原因を特定するのに6時間もかかった。翌日テナントIDをログに追加したら、同種の調査が5分で終わるようになったという話だよ。たった1つのフィールドの有無で障害対応の時間が70倍以上変わる。だからこそ「何をログに含めるか」の設計が本当に大事なんだね。