ログ集約

ログ集約とは

ログ集約（Log Aggregation） は、あちこちに散らばったログを1か所に集め、まとめて検索・分析できるようにする 仕組みです。アプリケーション、Webサーバ、データベース、各コンテナ——システムは至るところでログを吐きますが、それらが各マシンのファイルにバラバラに残っているだけでは、横断的に調べられません。

この問題は 分散システムで深刻 になります。

• リクエスト1本が 複数のサービス を通るため、関連ログが 別々のサーバ に散る。
• コンテナは 数分で生まれて消える。落ちた頃には、ログを出した実体ごと消えている。
• 何十台ものサーバに ssh して grep して回るのは、台数が増えると現実的でない。

ログ集約は、各所のログを 発生したそばから中央へ送り、一元的に検索できる状態を作ることで、これを解決します。

構造化ログ：機械が読める形に

ログ集約の効果を最大化する前提が 構造化ログ（Structured Logging） です。これは、ログを 人間向けの文章ではなく、機械が解析できる構造（多くは JSON） で出力することを指します。

従来の素朴なログは、こうした自由なテキストでした。

2026-06-06 12:00:01 ERROR checkout failed for user 1234 (order 9876)

これだと「user が 1234 のものだけ」を正確に絞るのが難しく、正規表現で頑張ることになります。構造化すると、こうなります。

{
  "ts": "2026-06-06T12:00:01Z",
  "level": "error",
  "msg": "checkout failed",
  "user_id": "1234",
  "order_id": "9876",
  "trace_id": "abc123"
}

こうしておけば、level=error AND user_id=1234 のように フィールド単位で検索・集計 でき、ダッシュボード化も容易です。とくに trace_id を全ログに含める と、分散トレーシング（/devops/distributed-tracing/）と突き合わせて「1リクエストに関わる全ログ」を一気に引けます。

集約の流れ：収集 → 保存 → 検索

ログ集約基盤は、おおむね3つの段階で構成されます。

段階	役割	担うものの例
収集（Collect / Ship）	各所からログを拾い、中央へ転送する	Fluentd / Fluent Bit / Filebeat / Promtail
保存（Store / Index）	受け取ったログを保管し、検索できる形にする	Elasticsearch / Loki
検索・可視化（Query）	検索・集計し、ダッシュボードで見せる	Kibana / Grafana

ポイントは 収集を担う軽量なエージェント（log shipper）を各サーバ・各コンテナに置く構成です。アプリは「ログを出す」ことだけに集中し、それを拾って中央へ送る仕事はエージェントに任せます。コンテナ環境では、各ノードに1つエージェントを置いて全コンテナのログを集める形が一般的です。

代表的なスタック：ELK と Loki

ログ集約基盤の代表が ELK（Elastic Stack） と Grafana Loki です。設計思想が対照的で、選択の分かれ目になります。

観点	ELK / Elastic Stack	Grafana Loki
検索方式	ログ本文を 全文インデックス（どんな語でも高速検索）	ラベルで絞り込み、本文はインデックスしない
構成	Elasticsearch + Logstash + Kibana	Loki + Promtail + Grafana
強み	強力で柔軟な全文検索・分析	保存コストが軽い・メトリクスと統合しやすい
トレードオフ	インデックスが重く、ストレージを食う	任意語の全文検索は不得手

• ELK：ログ本文をすべてインデックスするため、どんなキーワードでも高速に検索 できます。分析力が高い反面、インデックスが大きくストレージとリソースを消費します。
• Loki：「ログは ラベル（どのサービス・どの環境か） で絞り、あとは時間で範囲を切る」という Prometheus 流の設計。本文を全文索引しないので 低コスト ですが、任意の単語での横断検索は苦手です。Grafana 上でメトリクスと並べて見られるのが強みです。

運用上の注意

ログ集約は便利ですが、入れっぱなしだとコストとノイズの温床 になります。

• 保持期間（リテンション）を決める：ログは放っておくと無限に増えます。「何日で消す／安いストレージへ移す」を決めないと、ストレージ費が膨張します。
• 出しすぎない：DEBUG ログを本番で出し続けると、量が爆発し、肝心なログが埋もれます。重要度（レベル）で出し分けます。
• 機密情報を残さない：パスワード、トークン、個人情報をログに含めると、集約先が 情報漏えいの的 になります。出力前にマスキングする設計が必須です。

オブザーバビリティの中での位置づけ

ログ集約は、オブザーバビリティ（/devops/observability/）の3本柱のうち ログ を支える基盤です。3本柱はそれぞれ役割が違います。

• メトリクス：「何かおかしい」に気づく（傾向）。
• トレース：「どのサービスのどこで遅い／失敗した」を絞る（横断）。
• ログ：「具体的に何が起きたか」を読む（詳細）。

メトリクスのアラートから trace_id を拾い、その ID でログ集約を検索して詳細を読む——この一連の流れがスムーズに回ることが、調査時間の短縮に直結します。

まとめ

• ログ集約は 散在するログを中央に集め、横断的に検索・分析 できるようにする仕組み。分散・コンテナ環境ほど効く。
• 土台は 構造化ログ（JSON 等）。フィールド検索・集計が可能になり、trace_id でトレースと連携できる。
• 基盤は 収集 → 保存 → 検索 の3段。代表は ELK（全文検索が強力） と Loki（ラベルで絞る・低コスト）。
• 保持期間・出力量・機密マスキング を決めて運用する。オブザーバビリティの「ログ」を担う要。