Contents
Grafana LokiとPrometheusの設計思想とデータ形式の違い
Grafana LokiとPrometheusは、監視ツールとして広く利用されていますが、それぞれの設計思想や扱うデータ形式には明確な違いがあります。Lokiはログデータを専門に収集・検索し、Prometheusはメトリクス（時系列データ）を収集するという点で、用途に応じた選定が求められます。
以下では、両者のデータ形式の違いと水平スケーリングにおけるアプローチを比較します。
| 項目 | Loki | Prometheus |
|---|---|---|
| データ形式 | 文字列ベースのログデータ | 時系列メトリクス（数値+タイムスタンプ） |
| ストレージ構造 | ラベルでフィルタリング可能なインデックス付きストレージ | タイムシリーズを圧縮したTSDB形式 |
| クエリパフォーマンス | 高頻度のログ検索に適している | 時系列データの集計・傾向分析に強い |
| ストレージコスト | ログ量が多いとコストが急増 | メトリクス数が多いとコストが高まる |
Lokiは、ログの検索やフィルタリングを効率的に行えるように設計されており、特にサービスの運用日誌やエラーログの管理に適しています。一方でPrometheusは、メトリクスの収集・可視化が専門であり、CPU使用率やネットワーク遅延などの数値データをリアルタイムで監視するのに向いています。
水平スケーリングにおいても両者のアプローチは異なります。Lokiはラベルに基づくシャーディング（Label-based Sharding）を採用し、クエリ負荷を分散しますが、Prometheusはレプリケーションとフェデレーションを使って複数ノード間でデータを共有する方式を取ります。この違いにより、両者はそれぞれの長所と課題を持っています。
Grafanaでのメトリクスとログの統合可視化方法
Grafanaは、Loki（ログ）とPrometheus（メトリクス）のデータを同一ダッシュボードで可視化できるため、運用監視の効率が向上します。このセクションでは、ダッシュボード構成のベストプラクティスと共通ラベルの活用方法について説明します。
ダッシュボード構成のベストプラクティス
GrafanaでLokiとPrometheusを統合する際は、以下の点に注意してください。
- 同一タイムレンジでの比較：メトリクス（CPU使用率など）とログ（エラーメッセージ）を同じ時間軸で表示することで、問題発生時の相関関係を確認できます。
- レイアウトの最適化：メトリクス用にグラフパネルを配置し、Lokiの検索結果はテキストパネルで別画面に表示するなどのセグメンテーションが効果的です。
- 共通ラベルの連携：
jobやinstanceなどのラベルを両データソースで統一することで、条件フィルタリングが容易になります。
共通ラベルの活用事例
共通ラベルは、複数のデータソース（LokiとPrometheus）を連携する際の「橋渡し」になります。例えば、以下の手順でエラー発生時のメトリクス変化とログ内容を同時に追跡できます。
- Prometheusから
job="web-server"というラベルを持つメトリクス（例: HTTPリスポンス時間）を取得 - Lokiの検索条件に同じ
job="web-server"ラベルを指定し、エラーログをフィルタリング - 同じタイムレンジでグラフとログを並べて表示
この方法により、サービスの異常時にメトリクス変化と具体的なログを一括して確認でき、問題の原因特定が迅速になります。
Kubernetes環境でのLoki+Promtail導入手順
Kubernetes環境にLokiとPromtailを導入するには、Helmチャートを利用した手順が効率的です。以下では、ステップバイステップでデプロイの流れを解説します。
Helmチャートによるデプロイ手順
-
Helmリポジトリの追加
bash
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update -
LokiとPromtailのリリース作成
bash
helm install loki grafana/loki-stack \
--set prometheus.enabled=false \
--set loki.storageClassName="ssd" -
ConfigMapの設定確認
Promtailのscraper設定（例:values.yaml）に以下の記述を含める必要があります。
yaml
promtail:
config:
scrape_configs:
- job_name: "kubernetes-pods"
kubernetes_sd_config:
role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
regex: "true"
action: keep
StatefulSet構成とストレージクラス選定
LokiはStatefulSetでデプロイし、ストレージクラスには低レイテンシのSSDを推奨します。ただし、クラウド環境ではmanaged-csiやgp3などのクラウドネイティブなストレージクラスを使用するとコスト効率が良い場合があります。
AlertManagerとの連携設定とアラートルール設計
LokiはAlertManagerと連携することで、ログ量の異常検知や特定条件を満たしたエラーログのアラートを自動で通知できます。
Loki特有のアラートパラメータ
Lokiのアラートルールでは、以下のようなパラメータが重要です。
expr: ログ検索条件（例:level="ERROR" AND job="api-gateway"）for: 条件を満たし続ける時間（例:for=5m）labels: アラートに追加するメタデータ（例:severity="critical"）
マルチアラートの抑制設定
複数の条件で同じアラートが発生すると、大量通知が発生します。以下の抑制ルールをalertmanager.configに記述することで回避できます。
|
1 2 3 4 5 6 7 |
suppressors: - name: "error-rate-limit" expr: | max_over_time( loki_alerts{job="api-gateway", severity="critical"}[5m] ) > 10 |
Prometheusとの連携時は、ラベルのマッピングに注意が必要です。Lokiから送信される__name__やjobラベルは、AlertManager側でalertnameやgroupなどに変換する必要があります。
導入選定時のコスト・運用負荷比較指針
導入時に選択すべきポイントとして、クラウド環境での課金モデルとチームのスキル要件を明確にする必要があります。
クラウド環境での課金モデル比較
| 項目 | Loki | Prometheus |
|---|---|---|
| ストレージコスト | ログ量に比例して増加 | メトリクス数に比例して増加 |
| リソース消費 | 高頻度のログ検索でCPUが高負荷 | 時系列データ集計でメモリを多く使う |
| クラウド提供例 | AWS CloudWatch Logs（$0.50/GB） | AWS CloudWatch Metrics（$0.35/GBに誤りがある） |
注意: AWS CloudWatch Metricsの課金モデルは、メトリクスの数とディメンション数に基づいており、
$0.35/GBという記述は誤りです。正確な料金についてはAWS公式ドキュメントを参照してください。
オンプレミスでのLoki運用では、ストレージの選定がコストに大きく影響します。クラウド環境ではアラート数やログ量で課金されるため、「必要以上に細かいロギングを避ける」ことが重要です。
チームスキル要件
- Loki: ログ処理の知識が必要（例: エラーメッセージのパターンマッチング）
- Prometheus: 時系列データの理解とレギュレーション構築スキルが求められる
実環境導入チェックリストとトラブルシューティング
導入後は以下を確認することで、問題を早期に発見できます。
デプロイ後の検証項目
- Lokiのロギングが正しく収集されているか（
/api/logsエンドポイントで確認） - PrometheusのメトリクスがGrafanaで表示されるか
- AlertManagerにアラートが送信されているか
よくある設定ミスの回避策
- Promtailのscraper設定ミス:
relabel_configsが正しく定義されていない場合、ログが収集されません。 - Lokiのストレージクラス指定忘れ:
values.yamlにstorageClassNameを明示的に記述しないと、デフォルトのストレージが使用されることがあります。 - Grafanaのデータソース設定ミス: LokiとPrometheusを同時に表示する際は、両方のデータソースを正しく登録してください。
トラブルシューティングでは、Grafanaのエラーメッセージ（例: No data found）を確認し、対応するクエリやアラートルールを見直すことが有効です。
要点まとめ
このセクションでは、LokiとPrometheusの導入における主要な比較ポイントと実装時の注意事項を整理します。
比較と導入ポイント
- データ形式: Lokiはログ専用（文字列ベース）、Prometheusはメトリクス専門（数値+タイムスタンプ）
- コスト: ログ量やメトリクス数に応じて課金されるため、クラウド環境ではストレージクラスとロギングの粒度を慎重に設計する必要がある。
- 運用負荷: Lokiはラベル管理が重要、PrometheusはTSDBの圧縮効率に関心を持たなければならない。
ストレージ構成の選定
- オンプレミス環境: 高性能ストレージ（SSDなど）を採用し、コストとパフォーマンスのバランスを取る。
- クラウド環境: クラウドネイティブなストレージクラス（例: AWS EBS gp3）を活用して柔軟性とコスト効率を確保する。
チームスキルとツール選定
- Loki導入: ログ管理の経験が必要で、特にエラーメッセージの抽出やパターンマッチングに精通しているチームが望ましい。
- Prometheus導入: 時系列データの理解（例: レート、傾向分析）と監視ツールの構成スキルが要求される。
実装時のチェックリスト
- クラウド環境における課金モデルを正確に把握する。
- HelmチャートでLokiやPromtailをデプロイする際には、ConfigMap設定を丁寧に確認し、誤った設定がないか検証する。
- Grafanaでの可視化を実施する際に、共通ラベルを統一し、複数データソースの連携をスムーズに行えるようにしておく。
これらのポイントを踏まえ、自社環境でのGrafana LokiとPrometheusの比較検証や導入設計を行ってください。