【要約】PLG Stack — 第1部：Prometheus・Loki・Grafanaを深く理解する [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
[WARN: Partial Data] 本記事は全2回のシリーズの第1部であり、実践編は第2部に続くため。
// Problem
システム運用者が、障害発生時に「何が起きているか」を即座に把握できない問題に直面している。深夜の障害対応において、異常の検知はできても、その詳細な理由が不明なケースは多い。
- ・CPU高負荷などの数値異常は検知できても、具体的なエラー原因が特定できない。
- ・膨大なログの中から、特定のユーザーやエラーに関連する情報を抽出するのに時間がかかる。
- ・メトリクスとログが断絶しており、両者を組み合わせた相関分析が困難である。
// Approach
Observabilityを実現するために、MetricsとLogsを効率的に扱うPLG Stackの導入を提案している。各コンポーネントを組み合わせることで、データの収集から可視化までを一貫して行う。
- ・Prometheusによるプル型のメトリクス収集とPromQLによる時系列データのクエリ。
- ・Lokiによるラベルベースのログ管理とLogQLを用いた効率的なログ検索。
- ・Grafanaによる、メトリクスとログを統合したダッシュボードの構築。
- ・REDメソッドやUSEメソッドを用いた、サービスおよびインフラの監視指標の定義。
// Result
本記事の解説により、PLG Stackの各コンポーネントの役割と、適切な設定・クエリ手法が明確化された。これにより、運用チームは以下の成果を得られる。
- ・ELK Stackと比較して、ストレージやメモリ消費を大幅に抑制できる。
- ・ラベル設計を最適化することで、低コストかつ高速なログ検索が可能になる。
- ・メトリクスとログをGrafana上で統合し、迅速なインシデント調査が可能になる。
- ・第2部で詳述される、Docker ComposeやKubernetesを用いた実践的なデプロイへの準備が整う。
Senior Engineer Insight
> PLG Stackは、リソース制約のあるコンテナ環境において極めて合理的な選択肢である。特にLokiの「ラベルのみをインデックス化する」設計は、運用コストを抑える上で強力な武器となる。ただし、Loki運用における最大の罠は高カーディナリティである。user_idのような一意性の高い値をラベルに含めると、インデックスが爆発しシステムが崩壊する。現場では、ラベルには低カーディナリティなメタデータのみを付与し、詳細情報はログ本文に含める設計を徹底すべきだ。