LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Grafana Lokiとログ基盤の全体像

Grafana Lokiとログ基盤導入とは、複数サーバー・複数サービスに分散したログを一箇所に集約し、LogQLというクエリ言語で横断検索できる状態を専門パートナーの支援で構築する取り組みを指します^*1。Lokiは「水平スケール可能で高可用性を持つマルチテナント対応のログ集約システム」であり、Prometheusから設計思想を受け継いでいます^*2。

Lokiが対象とするのは、サーバー・コンテナ・アプリケーションから出力される大量のログを、低コストかつ運用負荷を抑えて集約・検索できる状態にすることです。分散システムが増えるほどログの発生源も分散し、障害調査の初動で「どのサービスの、どの時間帯のログか」を素早く絞り込む仕組みが要ります。

この仕組みを内製で構築するには、収集エージェントの設計・ラベル設計・クエリ言語の運用・ストレージ構成という複数領域の知見が求められます。次章以降で、Lokiの中核となる設計思想から順に整理します。

ラベルインデックスとchunkが生む設計思想

Grafana Lokiの最も大きな特徴は、「ログの内容そのものは索引化せず、ログに付与されたラベルの集合というメタデータだけを索引化する」という設計です^*1。Elasticsearch・OpenSearchのようにログ本文を単語単位で全文索引化する方式とは、思想の起点が異なります。

取り込まれたログデータは圧縮され、Amazon S3やGoogle Cloud Storageのようなオブジェクトストレージ上のchunk（特定のラベルセットと時間範囲に属する複数ログ行をまとめたコンテナ）に格納されます^*1*3。索引側は「特定ラベルセットに対応するログの格納場所を示す目次」としてのみ機能し、TSDBまたはBoltDBという形式が使われます^*3。

圧縮されたchunkと小さな索引、そして低コストなオブジェクトストレージの組み合わせが、Lokiの運用コストを抑える要因になっています^*1。ただし、この設計を活かすにはラベル設計そのものの巧拙が問われます。公式ドキュメントは「ラベル数は10〜15個程度を目安に、できるだけ少なく保つ」「値が長期的に安定したラベルを選ぶ」ことを推奨し、逆に「ユーザーIDのように値の種類が非常に多いラベル」を避けるよう明記しています^*4。

ラベルの組み合わせパターンが際限なく増える状態はハイカーディナリティ（高カーディナリティ）と呼ばれ、タイムスタンプやIPアドレスのように値が実質無限に近いラベルを付けたり、ラベル数自体を増やしすぎたりすると発生します^*4。この状態になるとLoki全体のクエリ性能が大きく落ち、コスト効率も悪化するとされています^*4。ラベル設計を誤ったまま本番運用に入ると、後から大規模な再設計が必要になる点は見落とされがちなリスクです。

LogQLによるログ検索の仕組み

LogQLはLokiのクエリ言語で、Prometheusのクエリ言語であるPromQLをベースにしていますが、LogQLを書くためにPromQLの知識を要するとは限りません^*5。すべてのLogQLクエリは、まずログストリームを絞り込む「ログストリームセレクタ」を含み、その後にオプションで「ログパイプライン」を続けます^*5。

ストリームセレクタはラベルのキーと値のペアをカンマで並べる形で書き、完全一致（=）、不一致（!=）、正規表現一致（=~）、正規表現不一致（!~）の各演算子で対象ラベルを絞り込みます^*5。この段階でヒットするのはラベル索引だけなので、ログ本文への全文検索とは違い、まずラベルで対象範囲を大きく絞ることが検索速度の前提になります。

ストリームセレクタの後ろに続くログパイプラインは、複数のステージ式を左から右へ順に適用する仕組みです^*5。ライン フィルタ（|=は文字列を含む、!=は含まない、|~は正規表現に一致、!~は一致しない）でログ本文を絞り込み、JSON・logfmt・パターン・正規表現・unpackといったパーサーでログ本文からラベルを抽出し、抽出後のラベルに対する条件フィルタも組み合わせられます^*5。

つまりLogQLは「まずラベルで大まかに絞り、次に本文パターンで絞り込む」という二段階の検索モデルです。この特性を理解せずにラベル設計をおろそかにすると、パイプライン側の正規表現処理に負荷が集中し、クエリが遅くなる原因になります^*4。

Promtail終了とGrafana Alloyへの移行

Lokiへログを送るための収集エージェントとして長く使われてきたのがPromtailです。しかし公式ドキュメントは「Promtailは2026年3月2日にEOL（サポート終了）」であり、「商用サポートは終了し、今後の機能追加やアップデートは提供されない」と明記しています^*6。

今後の機能開発はすべてGrafana Alloyで行われる方針が示され、「現在Promtailを使っている場合はAlloy、またはその他のサポート対象クライアントへ移行する必要がある」と案内されています^*6。すでにPromtailで構築済みの収集基盤を持つ企業にとって、これは避けて通れない移行対応です。

Grafana Alloyは「主要な収集ツールの強みを1つにまとめた」ディストリビューションで、OpenTelemetry Collectorと互換性を持つベンダーニュートラルな構成として位置づけられています^*7。メトリクス・ログ・トレース・プロファイリングといった複数のテレメトリ信号にネイティブ対応し、PrometheusやOpenTelemetry、Lokiのようなデータベースに向けたパイプラインを備えます^*7。

Lokiへログを送る手段はAlloyだけでなく、Docker用ログドライバー、Fluent Bit、Fluentd、Logstash、各言語向けのクライアントライブラリなど複数存在します^*8。既存の収集基盤（Fluentdなど）を活かしながら段階的にLokiへ接続する設計も選べますが、収集経路が増えるほどラベル設計の一貫性を保つ工数が増える点は留意が必要です。

オブジェクトストレージ活用とコスト構造

Lokiのデータはすべて、S3・GCS・Azure Blob Storageなどの単一のオブジェクトストレージバックエンドに保存する設計です^*3。ログ本文を全文索引化しないため、索引そのもののサイズを小さく保てる点が、ストレージコストを左右する要因になります^*1。

この設計を機能させるには、書き込み経路（Distributor・Ingester）と読み取り経路（Query Frontend・Query Scheduler・Querier）というマイクロサービス構成を理解した上でのキャパシティ設計が必要です^*3。単一バイナリでの起動から、コンポーネントを分割してスケールさせる「シンプルスケーラブルデプロイメント」まで複数の運用形態があり、ログ量とアクセス頻度に応じた選択が求められます^*3。

マルチテナント機能も備え、HTTPリクエストのX-Scope-OrgIDヘッダーからテナントIDを取り出し、メモリ上のデータと長期保存データの双方をテナント単位で分離します^*3。複数事業部・複数システムのログを1つのLoki基盤に統合したい場合、このテナント分離の設計判断が運用ルール全体に影響します。

Prometheus・Grafanaとの統合運用

Lokiは名称・設計思想の両面でPrometheus（サーバー監視のためのオープンソースのメトリクス収集・アラートシステム）を強く意識して作られています^*1。メトリクスの異常を検知したら同じGrafana画面上でログへドリルダウンする、という運用フローを組みやすいのが両者を組み合わせる利点です。

ただし、この統合運用を機能させるには、PrometheusのメトリクスラベルとLokiのログラベルの命名規則を揃える設計が欠かせません。ラベル名がシステムごとに揺れていると、メトリクスの異常時刻からログへ横断的にジャンプする操作がうまく機能しなくなります。

Grafana上でのダッシュボード構築・アラート設定・LogQLクエリの保存といった運用ルールの整備にも工数がかかります。監視基盤全体をPrometheus・Grafana・Lokiの三点構成で刷新する場合、既存の監視設計をどこまで引き継ぐかの整理が導入初期の主要な論点になります。

Elasticsearch・OpenSearch型との考え方の違い

Elasticsearch・OpenSearch（オープンソースの検索・分析エンジン）は、ログ本文の単語を単位として転置索引（全文検索用のインデックス）を構築する方式です。任意の単語・フレーズで高速に全文検索でき、構造化された分析やダッシュボード集計にも強みがあります。

一方Lokiは、ラベルという限られた種類のメタデータだけを索引化し、ログ本文はchunkとして圧縮格納する設計です^*1。全文索引を持たない分、索引の維持にかかる計算資源とストレージ容量を抑えられる反面、ラベルに含まれない語句での自由な全文検索には向きません。

言い換えると、両者は「何を索引化するか」という前提が異なるため、単純にどちらが優れているかを比較することはできません。ラベルで絞り込める運用ログ・アプリケーションログの集約にはLokiの設計が合い、監査ログの詳細な全文検索やセキュリティ分析のように任意語句での横断検索が中心の要件では、全文索引型の基盤の方が適する場面があります。

外注と内製の判断軸

Grafana Lokiの導入を誤ると、ラベル設計の失敗によるカーディナリティ問題や、Promtailからの移行対応漏れによって、本番運用開始後にクエリ性能の劣化や収集エージェントの保守停止といったリスクが生じます^*4*6。設計フェーズで踏むべき手順を飛ばすと、後から索引・ラベル体系を作り直す手戻りが発生しかねません。

内製でLoki基盤を構築するには、ラベル設計とLogQLパイプラインの知識、Grafana Alloyまたは代替クライアントの選定・移行スキル、オブジェクトストレージとマイクロサービス構成のキャパシティ設計スキルが必要です。これらを兼ね備えた担当者を確保し、Prometheus・Grafanaとの統合設計まで一貫して進めるには相応の体制が求められます。

専門パートナーに外注する場合は、既存の監視・ログ運用の課題整理からラベル体系の設計、Alloyへの移行計画、Grafana側のダッシュボード・アラート設計までを一括して依頼できる点が内製との違いです。特に複数システムが混在する環境では、ラベル命名規則を横断的に統一する設計力が問われるため、複数システムの監視基盤を扱った経験を持つパートナーの知見が生きる場面です。

まとめ：Grafana Loki導入で押さえる3つの判断軸

本稿ではGrafana Lokiによるログ集約・検索基盤の設計思想と導入時の論点を整理しました。要点を3つに集約すると、第一にLokiはログ本文でなくラベルだけを索引化する設計であり、ラベル設計の巧拙が性能とコストを左右します。第二に、収集エージェントはPromtailの終了に伴いGrafana Alloyへの移行設計が必須の検討事項になっています。第三に、Elasticsearch・OpenSearch型とは索引の前提が異なるため、自社のログ活用目的に照らして採否を判断する必要があります。これらの設計判断を自社だけで担うか、専門知見を持つ外部パートナーと進めるかが、導入後の運用負荷を大きく左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Grafana Labs「Loki overview」（Grafana Loki公式ドキュメント）
2. *3　出典：Grafana Labs「Loki architecture」（Grafana Loki公式ドキュメント）
3. *4　出典：Grafana Labs「Best practices for labels」（Grafana Loki公式ドキュメント）
4. *5　出典：Grafana Labs「Log queries」（Grafana Loki公式ドキュメント）
5. *6　出典：Grafana Labs「Promtail」（Grafana Loki公式ドキュメント）
6. *7　出典：Grafana Labs「Grafana Alloy documentation」（Grafana Alloy公式ドキュメント）
7. *8　出典：Grafana Labs「Send data to Loki」（Grafana Loki公式ドキュメント）

Tweet