Lokiのラベル設計でログ検索の形を変える

Prometheusの考え方をログへ持ち込む

grafana/lokiはREADMEで「Prometheus, but for logs」と説明されます。水平方向に拡張できるマルチテナントのログ集約システムで、Prometheusと同じラベルを使ってログストリームを分類します。メトリクスとログを同じラベルで切り替えて調べられることが設計上の中心です。

Lokiはログ本文を全文インデックス化しません。圧縮した非構造化ログを保存し、メタデータだけをインデックスに置くことで、構成を単純にし、運用コストを抑えるという説明です。これはどんな文字列でも高速検索できるという意味ではないため、検索条件をラベルと本文に分けて考えます。

ラベルが検索性能と費用を左右する

同じラベルを持つログストリームをまとめる方式では、サービス、namespace、Podなどの安定したメタデータが入口になります。READMEはKubernetes Podログを特に適した用途として挙げ、Podラベルを自動取得してインデックス化できるとしています。

個々のリクエストIDや高カーディナリティの値を無制限にラベルへ入れると、ストリーム数やインデックス量の設計を損ねる可能性があります。Loki自身が自分のログ形式に合うラベル方針を決めてくれるわけではないため、投入前に代表的なログを選び、クエリ頻度と保持量を測ります。

Lokiスタックの構成を切り分ける

READMEはLokiベースのログスタックを3つのコンポーネントで説明しています。収集側、Loki本体、参照・可視化側の責務を分けて検討できます。KubernetesでPodログを集める構成では、ラベルの生成元とLokiへ送る形式を確認します。

READMEは、Promtailが機能的に完成したため、ログ収集の今後の開発はGrafana Alloyへ移ると告知しています。既存環境がPromtailを使っているなら、単にイメージを交換せず、設定の変換、ラベル、送信エラー、停止時の取りこぼしを比較します。

ソースからローカルバイナリを起動する

READMEには git clone https://github.com/grafana/loki、cd loki、go build ./cmd/loki、./loki -config.file=./cmd/loki/loki-local-config.yaml という流れがあります。設定ファイルを指定して単一バイナリを起動し、収集側からログを送ってクエリを確認するのが最初の試験になります。

実環境では、保存先、テナント、認証、保持期間、ネットワーク境界を運用側で設定します。READMEは各環境の性能基準やサービス保証を示していないため、1台の確認結果をそのまま大規模構成へ拡大しません。

Helm Chartの移行を更新計画に含める

READMEには、2026年3月16日からGrafana LokiのHelm chartをgrafana-community/helm-chartsへ分離する案内があります。KubernetesでHelmを利用している場合、チャートのリポジトリ、依存、values、アップグレード手順がアプリ本体と別の変更になります。

更新前に現在のchart版とvaluesを保存し、テストクラスターでインストール、ログ投入、クエリ、ローリング更新を確認します。移行後にラベルやテナント設定が失われないことを、Grafana画面だけでなくAPIと保存データでも確認します。

AGPL-3.0と運用データの境界

メタデータ上のライセンスはAGPL-3.0です。再配布や変更時の条件はLICENSEを確認する必要があり、ログに含まれる個人情報や認証情報の扱いは別の運用課題です。ログ集約基盤は可視性を高める一方、テナント分離やアクセス制御を誤ると広い範囲の情報を閲覧できてしまいます。

採用判断では、ラベル設計、全文検索の不足、収集エージェントの移行、Helmの取得先を具体的な確認項目にします。READMEの「easy to operate」という説明は方針であり、負荷試験、障害復旧、コスト測定の結果ではありません。

導入判定では、Kubernetesのnamespace、Pod、containerをラベルにした少量のログをLokiへ送り、ラベル検索と本文検索の結果を分けて確認します。高カーディナリティのリクエストIDをラベルにした場合のストリーム数も測ります。PromtailからAlloyへ移す時は同じログを送り、ラベル、送信エラー、再起動時の取りこぼしを比較します。Helmを使う場合はchartの移行先、values、テナント、保持設定を固定し、テストクラスターで更新と復旧を確認します。

Lokiの設定とラベル一覧を保存し、同じログを収集してクエリします。ラベル数、保存量、本文検索の結果、Alloyへの移行後の送信エラーを比較し、テナントごとの閲覧範囲も確認します。

Lokiのラベル設計と保存設定を固定し、Podの再起動と収集エージェントの停止を含むログを確認します。Alloyへの移行前後で検索結果と送信エラーを並べ、Helm更新後のテナント境界も確認します。

Lokiでは収集したログのラベルと本文を分けて確認します。Alloy移行後の送信エラー、Helmのvalues、テナントごとの検索範囲を比較し、保存量と復旧時間も記録します。

編集部の結論

Prometheusと同じラベルでメトリクスとログを行き来し、KubernetesのPodログを集約したい運用チームに向きます。全文インデックスを作らずメタデータ中心で検索するため、ログ本文の検索要件やラベル基数を先に設計する必要があります。まずローカル設定で収集、保存、クエリを試し、Alloyへの移行後もラベル、保持期間、テナント境界、Helmの取得先が変わらないことを確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes