ログ集約 ろぐしゅうやく
ログ管理ELK StackFluentdLokiオブザーバビリティ障害調査
ログ集約って何？ログって普通のファイルじゃないの？
簡単に言うとこんな感じ！
1台のサーバーならログファイルを見ればよかったけど、マイクロサービスやコンテナが100台あったらどうする？ログ集約は「バラバラのログを1箇所に集めて、まとめて検索・分析できるようにする」仕組みだよ。「昨日の12時にエラーが起きた原因を全サービス横断で調べたい」という時に超役立つんだ！
ログ集約とは
ログ集約とは、複数のサーバー・コンテナ・サービスから出力されるログを一箇所に収集・保存し、横断的に検索・分析・可視化できる仕組みのことです。モノリシックなシステムではサーバー上のログファイルを見ればよかった時代もありましたが、マイクロサービス・コンテナ・クラウドの普及により「ログがどこにあるか」が複雑化しました。コンテナは削除されるとログも消えてしまいます。
ログ集約システムは「収集（Collection）→転送（Shipping）→保存（Storage）→検索・可視化（Search/Visualize）」の4段階で構成されます。各コンテナ・サーバーで動くログコレクター（Fluentd・Fluent Bit・Logstash等）がログを収集して中央のストレージに転送します。Elasticsearchなどの全文検索エンジンで保存し、Kibana・Grafanaで可視化・検索します。
構造化ログ（Structured Logging）もログ集約を効果的に使うための重要な実践です。ログをただのテキストではなく{"level":"error","user_id":1234,"service":"order","latency_ms":503}のようなJSON形式で出力することで、特定フィールドでの絞り込み検索が容易になります。
代表的なログ集約スタック
| スタック | 構成 | 特徴 |
|---|---|---|
| ELK Stack | Elasticsearch + Logstash + Kibana | 高機能・大規模向け。検索・可視化が強力 |
| EFK Stack | Elasticsearch + Fluentd + Kibana | LogstashよりFluentdが軽量。Kubernetes向き |
| Grafana Loki | Loki + Promtail + Grafana | ラベルベース。メトリクスと統合しやすく軽量 |
| AWS CloudWatch Logs | マネージド型 | AWSサービスとの統合が容易。追加運用不要 |
| Datadog Logs | マネージドSaaS | APM・メトリクスとの統合が強力 |
歴史と背景
- 2004年：Splunkが商用ログ分析ツールとして登場。ログの中央集中管理の先駆け
- 2010年：ElasticsearchがOSS公開。全文検索エンジンをログ保存に使う ELKスタックの原型が生まれる
- 2011年：LogstashがOSS公開。ELKスタックが完成しログ集約の定番に
- 2014年：FluentdがCNCFに寄贈。コンテナ環境に適した軽量コレクターとして普及
- 2018年：Grafana Lokiが発表。Prometheusとの統合を前提にした「ラベルベースのログ集約」という新アプローチ
- 2020年〜：OpenTelemetry LogsがRCになり、ログ・メトリクス・トレースを統一SDKで扱う方向性が固まる
ログ集約のアーキテクチャ
関連する規格・RFC
| 規格・RFC番号 | 内容 |
|---|---|
| OpenTelemetry Logs（Stable） | ログをトレース・メトリクスと統一して収集・送信するための仕様 |
| RFC 5424 | Syslogメッセージのフォーマット標準 |
関連用語
- オブザーバビリティ — ログはオブザーバビリティの3本柱の一つ
- 分散トレーシング — ログとトレースを組み合わせてリクエストの経路と詳細を把握
- メトリクス・SLO — メトリクスはログと組み合わせてアラートの根拠を補完する
- Kubernetes — コンテナのstdout/stderrをFluentd等が収集するKubernetesのログパターン
- マイクロサービスアーキテクチャ — サービスが分散するほどログ集約の必要性が増す
- SRE — SREがインシデント対応にログ集約を活用し、根本原因分析（RCA）を行う
- カオスエンジニアリング — 意図的障害時の挙動をログで観察して復旧性を検証する