Prometheusは2012年、SoundCloudで開発が始まったオープンソースの監視・メトリクス収集システムです。Googleの内部監視システムBorgmonにインスパイアされ、後にCloud Native Computing Foundation（CNCF）に寄贈、Kubernetesに次ぐ「CNCFの卒業プロジェクト第2号」となりました。現在ではKubernetes環境の事実上の標準メトリクス基盤として、ほぼ必須のインフラになっています。
この記事の目次
- Prometheusの設計の特徴
- 代表的なExporter
- アラートと監視運用
- Prometheus単体の弱点
- まとめ
Prometheusの設計の特徴
Prometheusの最大の特徴は「Pull型」のメトリクス収集です。監視対象が /metrics エンドポイントを公開し、Prometheusが定期的に取りに行くモデル。Push型のサービスより設定がシンプルになり、対象側の負荷も予測しやすい設計です。
収集したメトリクスはすべて時系列データとして内部TSDBに保存。PromQLという独自クエリ言語で、サーバ単位の集計や、増加率、サービス間の相関などを柔軟に取り出せます。Grafanaと組み合わせて可視化するのが定番構成です。
代表的なExporter
PrometheusはExporterと呼ばれる中継プログラムで、既存システムのメトリクスを公開します。node_exporterはLinuxホストのCPU・メモリ・ディスクI/O、blackbox_exporterはHTTP監視、MySQL/Postgres exporter はDBの状態、というように対象別に多数のExporterが用意されています。
Kubernetes環境では kube-state-metrics や cAdvisor が必須で、Pod・Deployment・Nodeの状態を細かく収集できます。「いつ・どのPodが落ちたか」「リソース使用率の傾向」などを把握する基盤として、もはや不可欠です。
アラートと監視運用
PrometheusはAlerting Ruleで「メトリクスがある閾値を超えたらアラート」を定義できます。発火したアラートは別コンポーネントの Alertmanager がグルーピング・重複排除・通知先振り分けを担当。
通知先はSlack、PagerDuty、メール、Webhook（独自API）等が選べます。「ノード停止＋ディスクFULL＋10分以上→PagerDutyで起こす」「Webサーバ全体エラー率2%超→Slackに警告」といった運用ルールがYAML一発で記述できる柔軟さも、Prometheusが愛される理由です。
Prometheus単体の弱点
Prometheus単体はシングルノード前提で、大規模環境では水平分散・長期保存に課題があります。これを解決するのが Thanos、Cortex、Mimir、VictoriaMetrics などの拡張プロジェクトで、「複数Prometheusを束ねて長期保存・横断検索する」用途に発展しています。
また Prometheus はメトリクスのみ扱うので、ログ（Loki）、分散トレース（Tempo / Jaeger）と組み合わせてObservabilityスタックを構築するのが現代的。全部マネージドで楽したい場合は Datadog、New Relic、Grafana Cloud などの選択肢もあります。
まとめ
PrometheusはKubernetes時代の監視のデファクトとして、Webサービス・SaaS運用の中核を担っています。PromQL とExporter周りのノウハウは、SREやインフラエンジニアにとって基礎中の基礎と言える領域です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント