Grafana Lokiで本番ログ集約基盤を段階構築する｜収集エージェント選択と保持設計・クエリ負荷の確認

なぜ今、Lokiを本番基盤に選ぶのか

ログ管理の選択肢として長らく主流だったElasticsearchスタックは、インデックス設計の複雑さとメモリ要求の大きさが運用コストを押し上げてきました。Grafana Lokiはこの問題を逆転の発想で解決しています。ログ本文をインデックス化せず、ラベルとタイムスタンプだけをメタデータとして保持し、本文はオブジェクトストレージに圧縮して置く設計です。

2026年現在、多くの中規模本番環境でLokiが選ばれる理由は主に3点あります。第一に、Prometheusと同じラベル体系でメトリクスとログを横断検索できること。第二に、S3互換ストレージを使えばストレージコストをElasticsearchの数分の一に抑えられること。第三に、Grafana Alloyの登場によって収集エージェントの選定と設定が以前より整理されてきたことです。

ただし「インデックスを持たない」設計は長所と短所の両面を持ちます。フルテキスト検索はPromQLに似たLogQLのフィルタ式で行うため、ラベルの設計が甘いと全チャンクをスキャンする重いクエリが発生します。基盤を正しく育てるには、エージェント選択・保持設計・クエリ負荷の3軸を最初から意識する必要があります。

収集エージェントの選択基準

2026年時点でLokiへの送信に使える主要エージェントはPromtail、Grafana Alloy、Vectorの3択です。選定はユースケースによって変わります。

Promtailは歴史的にLokiと一体開発されてきた純正エージェントです。設定ファイルが直感的で、systemdジャーナルやDocker/containerdのログをほぼそのまま拾えます。ただし開発の重心はGrafana Alloyへ移行しており、新機能の追加は限定的になっています。既存のPromtail構成がある環境でそのまま使い続けるのは合理的ですが、新規構築ではAlloyを検討する価値があります。

Grafana AlloyはOpenTelemetry Collectorをベースにした次世代エージェントで、ログ・メトリクス・トレースを単一プロセスで収集できます。River（現在はAlloy設定言語）で記述し、Promtailの設定をほぼそのままインポートできる互換ブロックも持っています。observabilityの一元化を目指す環境や、OTELパイプラインとの統合が必要な場面に適しています。

VectorはRustで実装された高スループットエージェントで、変換パイプラインの柔軟性が突出しています。ログの前処理（フィールド抽出・マスキング・ルーティング）を細かく制御したい場合や、Loki以外の複数バックエンドへの同時送信が必要な場合に力を発揮します。反面、設定の学習コストはPromtailより高めです。

現場でよく見られる判断基準をまとめると、既存Promtail環境の移行期はAlloyへの段階移行、新規でOTEL統合が不要なシンプル構成はPromtailまたはAlloy、複雑な変換パイプラインが必要な場合はVector、という棲み分けになります。

段階的な構築手順

本番基盤を一度に本番投入するのではなく、非クリティカルなサービスから段階的にオンボードする進め方が安全です。以下に実践的な3段階を示します。

第1段階：単一ノードでの動作確認
まずDockerまたはdocker composeでLokiとGrafanaを同一ホストに立て、Promtail（またはAlloy）を同じホストのsystemdジャーナルに向けます。ラベルはjobとhostの最小限に絞ります。この段階でLogQLのフィルタ構文に慣れ、保持期間を短く設定（7日程度）して動作を確認するのが目的です。

Loki設定の核心はストレージバックエンドの選択です。単一ノードのテストではfilesystemバックエンドで問題ありませんが、本番ではschema_configのstore: tsdbとS3互換バックエンドを組み合わせるのが2026年の現行標準です。TSDBインデックス（v3）は旧BoltDBシッパーと比べてクエリ性能と圧縮効率が大幅に向上しています。

第2段階：分散構成への移行
ログ量が1日あたり数十GB規模になると、単一ノードでは限界が来ます。Lokiはread・write・backendの3コンポーネントに分離できるsimple-scalableモードを持っており、KubernetesのHelmチャートから比較的容易に展開できます。この段階でS3バケットのライフサイクルポリシーとLoki側のretention_periodを合わせて設定します。

第3段階：本番サービスのオンボード
全サービスを一度にラベル設計なしで流し込むと、後で修正できなくなります。サービス名・環境（prod/stg）・クラスタ名の3ラベルを最低限定義し、カーディナリティが爆発しないようにユーザーIDやリクエストIDはラベルに入れない（ログ本文に含める）ことを徹底します。

保持設計とストレージコスト試算

保持ポリシーは法的要件と運用要件の両面から設計します。一般的なWebサービスでは30〜90日の保持が求められる場面が多く、金融・医療系では1年以上の長期保持が必要になることもあります。

Lokiの保持はルールベースで設定でき、ラベルの組み合わせごとに異なる保持期間を指定できます。例えば本番環境のアクセスログは90日、デバッグログは7日、といった粒度で管理可能です。compactorコンポーネントが定期的に古いチャンクを削除するため、S3バケットのライフサイクルポリシーと保持期間を必ず合わせておく必要があります。ずれがあると課金上の無駄が生じます。

コスト試算の目安として、平均的なWebアプリケーションのログは圧縮後で1日あたり1GBあたり数円〜十数円（S3標準ストレージ）のオーダーに収まります。ElasticsearchクラスタのEBSコストと比較すると、同規模のデータで数分の一になることが多いです。ただしクエリ頻度が高い場合はGETリクエスト数も無視できないため、Intelligent-Tieringの採用や古いデータのGlacier移行も検討に値します。

クエリ負荷の計測と調整

Lokiのクエリ性能問題は大半がラベルのカーディナリティとクエリのフィルタ設計に起因します。重いクエリが発生したときの診断手順を確認しておきましょう。

Grafana上でクエリが遅い場合、まずLoki自身が公開する/metricsエンドポイントでloki_request_duration_secondsを確認します。次にquery-frontendのログからquery_rangeのレスポンスタイムを絞り込み、どのラベルセレクタが遅いかを特定します。

クエリ最適化の基本原則は「先にラベルで絞り、後にフィルタ式を適用する」です。{app="nginx"} |= "ERROR"のように、波括弧内のラベルセレクタでチャンクを絞ってからパイプフィルタを適用する形が正しく、逆にラベルを広げてフィルタだけで絞ると全チャンクスキャンが発生します。

時間範囲も重要です。過去24時間以内のクエリと過去30日のクエリではスキャン量が桁違いに異なります。Grafanaダッシュボードのデフォルト時間範囲を適切に設定し、アドホック調査でも不必要に長い時間範囲を選ばないよう運用ルールを整備するのが現実的な対策です。

2026年現在、Loki 3.x系ではbloom filters機能が実験的に追加されています。ブルームフィルタを有効にすると非構造化テキストの絞り込み効率が向上し、重い|=フィルタのスキャン量を大幅に削減できる可能性があります。本番適用には十分な検証が必要ですが、注目すべき改善点です。

切り戻し計画と2026年現行環境の注意点

既存のログ収集基盤（Elasticsearch、fluentd等）からLokiへ移行する場合、切り戻しシナリオを事前に定義しておくことが不可欠です。現場での推奨アプローチは、一定期間の並行送信です。エージェントから旧バックエンドとLokiの双方へ同時に送り続け、Lokiでの動作が安定したことを確認してから旧バックエンドへの送信を停止します。

切り戻しのトリガーとなる指標も事前に決めておきます。クエリレスポンスタイムの劣化（例：p99が5秒超）、エージェントの送信失敗率上昇（例：1%超）、Lokiのdistributorエラー増加などが目安になります。

2026年現行環境として押さえておきたい差分を以下に整理します。スキーマバージョンはv13（TSDBインデックス）が推奨であり、旧v11（BoltDB）は非推奨です。新規構築でv11を選ぶ理由はありません。Promtailは機能追加が停止しており、Grafana公式のロードマップではAlloyへの集約が明確に示されています。helmチャートのデフォルト値も頻繁に変わっているため、アップグレード時は必ずリリースノートのBreaking Changesセクションを確認する習慣が必要です。

認証まわりでは、Loki 3.x系からmulti-tenancyがより厳格に扱われるようになっています。シングルテナント構成ではauth_enabled: falseのままで問題ありませんが、マルチテナント構成（SaaS基盤など）ではX-Scope-OrgIDヘッダの扱いを慎重に設計する必要があります。エージェント側での設定漏れがテナント混在につながるリスクがあります。

ログ集約基盤は一度構築して終わりではなく、ラベル設計の見直しや保持ポリシーの調整を継続的に行うことで真に運用に役立つものになります。Lokiの設計思想を理解した上で段階的にオンボードすることで、コストを抑えながら観測性を高める基盤が実現できます。