採用に向く条件
選ぶ理由
- プル型で収集がシンプル
- PromQL で柔軟な集計
- クラウドネイティブ/K8s の標準
製品プロフィール
SoundCloud → CNCF / メトリクス監視
時系列メトリクスを収集・保存し、PromQL で問い合わせる監視の定番。プル型で収集し、アラートも備える。
基本情報
選定ガイド
採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。
採用に向く条件
事前に確認する条件
詳しい解説
Prometheus は、システムのメトリクス(数値の指標)を収集・保存・監視するためのツールです。CPU 使用率やリクエスト数といった値を時系列で蓄え、状態の変化を追えるようにします。CNCF 傘下のオープンソースで、クラウドネイティブ監視の定番です。
「結局なに?」を一言でいえば、メトリクスを時系列で集めて監視する仕組みです。
横にスクロール
データは自前の時系列データベース(TSDB)に保存されます。各メトリクスは名前とラベル(key=value)の組で識別され、ラベルの掛け合わせで柔軟に切り分けられます。
収集方式は Pull 型が基本で、Prometheus 側が監視対象(ターゲット)へ定期的にアクセスし、公開されたメトリクスを取りに行きます。
scrape_configs:
- job_name: app
static_configs:
- targets: ['localhost:9090']
| レイヤー | 担当 | 補足 |
|---|---|---|
| メトリクス収集・保存 | Prometheus | Pull+TSDB+PromQL |
| 可視化 | Grafana | ダッシュボード表示 |
| アラート発報 | Alertmanager | 重複排除・通知経路 |
| ログ | 別基盤(Loki 等) | Prometheus の範囲外 |
グラフでの「見える化」は Grafana と組み合わせるのが定番で、Prometheus が収集、Grafana が表示、という分担です。
ユーザー ID やリクエスト ID のような値をラベルに入れると時系列数が爆発し、メモリと性能を圧迫します。ラベルは有限の次元に絞り、識別子は入れないのが鉄則です。長期保存や大規模化は Thanos/Mimir を検討します。
総じて Prometheus は、Pull 型収集・ラベル付き TSDB・PromQL を軸に、クラウドネイティブ環境のメトリクス監視を担う標準ツールです。
実装・運用の視点
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
メトリクス監視/アラート
種別: メトリクス監視 / 提供元: SoundCloud → CNCF / ライセンス: オープンソース(Apache 2.0)
PromQL で柔軟な集計
長期保存は別途(リモートストレージ)
向いている用途