プロメテウスとグラファナ__HTMLTAG_66___
Prometheus と Grafana は、Kubernetes エコシステムにおいて切り離せないコンビです。 Prometheus はメトリクスの収集、保存、クエリを担当し、Grafana は強力な視覚化レイヤーを提供します。 Prometheus Operator の導入により、Kubernetes での Prometheus の管理が宣言的かつ完全に自動化されました。
Prometheus データ モデル
Prometheus Operator に入る前に、効果的なクエリを作成するには Prometheus のデータ モデルを理解する必要があります。
時系列とラベル__HTMLTAG_74___
Prometheus のすべてのデータは 時系列 です。これは、メトリクス名と一連の Key-Value ラベルによって一意に識別される、時系列の一連の値 (float64) です。例:
コードブロック_0
Labels は、PromQL でデータをフィルター、集計、結合するための主要なツールです。適切なラベル設計が重要です。カーディナリティの高いラベル (ユーザー ID やリクエスト ID など) は使用しないでください。使用すると、数百万の時系列が作成され、Prometheus の速度が低下します。
指標タイプ
Prometheus は、次の 4 つの基本タイプのメトリクスを定義します。
- Counter: 値は増加するだけで減少しません (再起動すると 0 にリセットされます)。用途: リクエストの合計、エラーの合計、送信されたバイト数。
rate()またはincrease(). でよく使用されるクエリ
- ゲージ: 値は自由に増減できます。使用目的: 現在のメモリ使用量、現在のポッド数、キュー サイズ。
- ヒストグラム: 観測値の分布 (通常はリクエスト期間、レスポンス サイズ) を測定します。サフィックス
_bucket、__HTMLTAG_103____sum、__HTMLTAG_105____count の時系列を作成します。histogram_quantile(). でパーセンタイルを計算するために使用されます。
- 概要: ヒストグラムと似ていますが、クライアント側でパーセンタイルを計算します。ヒストグラムよりも柔軟性が低いため、新しい指標には推奨されません。
プロメテウス オペレーター
Prometheus Operator は、Kubernetes 上の Prometheus と AlertManager を宣言的な方法で管理するのに役立ちます。構成ファイルを作成して Prometheus を手動でリロードする代わりに、Kubernetes リソースを作成すると、Operator が構成を自動的に更新します。
Prometheus Operator の CRD
Prometheus Operator は次の CRD を提供します:
- Prometheus: Prometheus インスタンスを定義
- AlertManager: AlertManager クラスター定義
- ServiceMonitor: サービスからメトリクスを取得する方法を定義
- _PodMonitor: ポッドからメトリクスを取得する方法を定義
- PrometheusRule: アラートと記録のルールを定義
- Probe: ブラックボックス監視ターゲットを定義
プロメテウス CRD
コードブロック_1
Prometheus Operator は、ラベル セレクターに基づいて ServiceMonitor と PodMonitor を自動的に検出します。新しいターゲットを追加するときに Prometheus を再起動またはリロードする必要はありません。
ServiceMonitor — サービスからメトリクスを収集
ServiceMonitor は、Prometheus にスクレイピング ターゲットを追加する最も一般的な方法です。これは、Prometheus がサービスのグループからメトリクスを見つけて取得する方法を定義します。
コードブロック_2
サービスは正しい名前でメトリクス ポートを公開する必要があります:
コードブロック_3
PodMonitor — ポッドから直接メトリクスを収集
PodMonitor は、サービスを経由せずに Pod から直接スクレイピングする場合、または各 Pod を個別にスクレイピングする必要がある場合 (たとえば、各 Pod が異なるメトリクスを公開する場合) に使用されます。
コードブロック_4
PromQL — Prometheus クエリ言語
PromQL (Prometheus Query Language) は、時系列データをクエリするための強力なツールです。以下は最も一般的なパターンです。
レートと増加
カウンター メトリクスでは、意味のある値を取得するには、常に rate() または increase() を使用する必要があります:
コードブロック_5
ヒストグラムのパーセンタイル__HTMLTAG_176___
コードブロック_6
Kubernetes 固有のクエリ
コードブロック_7
Grafana ダッシュボード__HTMLTAG_180___
_Grafana は視覚化レイヤーであり、Prometheus (および Loki、Tempo) と接続してリッチなダッシュボードを作成します。
Grafana.com からダッシュボードをインポート
Grafana.com には何千ものコミュニティ ダッシュボードがあります。 Kubernetes の重要なダッシュボードのいくつか:
- ID 315: Kubernetes クラスター監視 (基本)
- ID 12740: Kubernetes モニタリング (高度な、kube-state-metrics が必要)
- ID 15661: Kubernetes ノードの概要
- ID 15760: Kubernetes ビュー — グローバル
- ID 14205: Kubernetes — ポッドの概要
インポートするには: Grafana UI → ダッシュボード → インポート → ID を入力 → Prometheus データ ソースを選択します。
ダッシュボード変数
Variables は、ダッシュボードを対話型ツールに変えます。 Kubernetes の共通変数:
コードブロック_8
この変数を使用すると、ユーザーはクラスター→名前空間→ポッドを選択でき、その選択に従ってダッシュボード内のすべてのパネルが自動的にフィルターされます。
重要なパネル
完全な Kubernetes ダッシュボードには次のものが必要です:
- ノードの概要: ノードごとの CPU 使用率、メモリ使用量、ディスク I/O、ネットワーク I/O
- ポッド メトリクス: CPU/メモリ リクエスト、制限、実際の使用量
- 展開ステータス: 必要なレプリカと利用可能なレプリカ
- コンテナの再起動: 1 時間、24 時間の再起動数
- エラー率: サービスあたりのHTTP 5xx率
- レイテンシ P50/P95/P99: リクエスト期間のパーセンタイル
アラートマネージャー
AlertManager は Prometheus からアラートを受信し、それらを処理します。正しい受信者へのルーティング、ノイズを低減するためのグループ化、アラート ストームを回避するための抑制、およびメンテナンス中のサイレンシングを行います。
ルーティング ツリー
AlertManager ルーティングは階層ツリーで構成されます。各ルートはアラートのラベルと一致し、対応する受信者に送信します:
コードブロック_9
禁止ルール__HTMLTAG_256___
抑制ルールは、別のアラートがアクティブなときにアラートが送信されないようにします。たとえば、クラスター全体がダウンしている場合、各サービスにアラートを送信する必要はありません:
___コードブロック_10___PrometheusRule — アラート ルール__HTMLTAG_260___
PrometheusRule は、アラート ルールと記録ルールを定義します。 Prometheus Operator は、これらのルールを Prometheus に自動的にロードします。
コードブロック_11
記録ルール — 高価なクエリの事前計算
記録ルールは複雑なクエリを事前計算し、結果を新しい時系列として保存します。これにより、大量のクエリを使用するダッシュボードとアラートのパフォーマンスが大幅に向上します。
コードブロック_12
記録ルールのベスト プラクティス:
- 名前の形式
level:metric:operations(例:job:http_requests:rate5m) - 複数の場所で使用されるクエリの記録ルールのみを作成__HTMLTAG_277___
- 記録ルールの評価間隔はスクレイピング間隔より小さくする必要があります
- 使い捨てクエリの記録ルールを作成しない
本番環境のベスト プラクティス
プロメテウスのサイズ
_Prometheus のメモリ使用量は、アクティブな時系列の数に比例します。推定: サンプルあたり 1 ～ 2 バイト、15 秒のスクレイピング間隔で、10,000 時系列は約 1 GB の RAM を使用します。 100 ノードと数百のサービスからなるクラスターでは、50 万から 100 万の時系列が予想されます。
高可用性
同じ構成で 2 つの Prometheus インスタンスを実行します。 Grafana はクエリ時に重複を排除します。 AlertManager を使用して、クラスター モードで 3 つのインスタンスを実行して、アラートが失われないようにします。
長期保管_
Prometheus はデータを 2 ～ 4 週間のみ保持する必要があります。長期ストレージ (月/年) の場合は、Thanos または Grafana Mimir を使用してください。どちらも、Prometheus ローカル ストレージよりもはるかに低コストでオブジェクト ストレージ バックエンド (S3、GCS) をサポートしています。
概要
Prometheus Operator は、Kubernetes での監視管理方法に革命をもたらしました。 ServiceMonitor と PodMonitor を使用すると、新しいターゲットの追加は完全に宣言的であり、手動介入は必要ありません。 PrometheusRule は、アラート ルールをコードとして (GitOps フレンドリーに) 管理するのに役立ち、柔軟なルーティング ツリーを備えた AlertManager は、適切なユーザーが適切なアラートを確実に受信できるようにします。
次のレッスンでは、可観測性スタックの残りの部分を具体化します。ログの場合は Loki、分散トレースの場合は Tempo です。