Prometheusメトリクス：アプリのパフォーマンスを監視する
Prometheusメトリクス：アプリのパフォーマンスを監視する
Prometheusとは？
Prometheusは、ソフトウェアシステムのパフォーマンスと健全性を追跡するオープンソースツールです。メトリクスとして知られるデータポイントを収集し、システムがどの程度うまく稼働しているかについての洞察を提供します。これらのメトリクスは、問題を早期に検出し、システムの挙動を分析するのに役立ちます。Prometheusを使用することで、チームはユーザーに影響が及ぶ前に問題を発見し、信頼性が高く効率的なサービスを維持できます。
Prometheusにおけるメトリクスとは？
Prometheusにおいて、メトリクスとは、システムの挙動やパフォーマンスの特定の側面を時間の経過とともに追跡する数値です。これらのメトリクスは、さまざまな条件下でシステムがどの程度うまく機能しているかを理解するのに役立ち、またトラフィックの急増やシステムパフォーマンスの低下など、問題を示す可能性のある状況でアラートを提供します。Webサイト上のアクティブユーザー数から、アプリケーションが使用するメモリ量まで、幅広いデータを監視できます。
Prometheusにおけるメトリクス形式
Prometheusのメトリクスは時系列形式で保存され、各メトリクスはその名前と、ラベルと呼ばれる任意のキーと値のペアによって識別されます。ラベルは、サービス名やエラーの種類などの追加コンテキストを提供します。Prometheusにおけるメトリクスデータの主要な形式は、Prometheus Exposition Formatです。このプレーンテキスト形式は生成と解析が容易で、メトリクス名、任意のラベル、メトリクス値、タイムスタンプを含むデータ行で構成されます。
Prometheusにおける4種類のメトリクス
Prometheusはメトリクスを、カウンター、ゲージ、ヒストグラム、サマリーの4つの主な種類に分類します。各種類は監視において特定の機能を果たし、システムの挙動について異なる洞察を提供します。
カウンターメトリクス
Prometheusのカウンターメトリクスは、特定のイベントが発生した回数を記録します。時間の経過とともに増加するだけで、プロセスが再起動するとゼロにリセットされます。そのため、処理されたリクエスト数、完了したタスク数、記録されたエラー数などの累積量を追跡するために使用されます。
サーバーが受信したリクエスト数を追跡するカウンターを実装するには、次のコードスニペットを使用できます。この例では、受信したHTTPリクエストの総数を監視するカウンターを設定します。handle_request関数が呼び出されるたびに、カウンターが増加します。
from prometheus_client import Counter
# Create a counter metric for tracking received requests
request_counter = Counter('http_requests_received_total', 'Total HTTP requests received')
def handle_request(request):
# Process the request
# ...
# Increment the counter by 1 each time this function is called
request_counter.inc()
カウンターを使用する際のベストプラクティス
リセットの認識：プロセスが再起動すると、カウンターはゼロにリセットされることに注意してください。これらのリセットを考慮するように監視を設計してください。
ラベルの使用：さまざまな種類のエラーやリクエストを区別するなど、より詳細な洞察を提供するために、カウンターでラベルを使用してください。
一貫したインクリメント：追跡しているイベントを正確に反映するように、コード内の正しい場所でカウンターがインクリメントされていることを確認してください。
リセットの監視：クエリでrate関数を使用して、カウンターの1秒あたりの平均増加率を計算します。これにより、リセットがあっても傾向を理解し、問題を検出するのに役立ちます。
ゲージメトリクス
Prometheusのゲージメトリクスは、CPU温度、現在実行中のプロセス数、空きメモリ量など、増減する可能性のある値を測定します。増加するだけのカウンターとは異なり、ゲージは特定の時点におけるシステムの現在の状態を反映するため、変動するメトリクスを追跡するうえで不可欠です。
システム内の空きメモリ量を監視するゲージを実装するには、次のコードスニペットを使用できます。この例では、空きメモリを監視するゲージを設定し、システムの変更を反映するためにトリガーされるべき update_free_memory() 関数を呼び出してゲージの値を更新します。
from prometheus_client import Gauge
# Create a gauge metric to track free memory
free_memory_gauge = Gauge('system_free_memory_bytes', 'Amount of free memory in bytes')
def update_free_memory():
# Assume get_free_memory() is a function that fetches the current free memory
free_memory = get_free_memory()
free_memory_gauge.set(free_memory)
# Update gauge regularly or upon specific system events
update_free_memory()
ゲージを活用するためのヒント
定期的な更新: ゲージがシステムの現在の状態を正確に反映するよう、定期的に更新されていることを確認してください。
文脈に応じた使用: 負荷平均や利用可能なシステムリソースなど、時間の経過に伴う増減を追跡する必要があるメトリクスにはゲージを使用します。
誤用の回避: カウンターやヒストグラムの方が適している可能性がある、増加または減少のみすべきメトリクスにゲージを使用しないよう注意してください。
ヒストグラムメトリクス
Prometheus のヒストグラムは、事前定義された一連のバケットにわたって数値データの分布を要約します。各バケットは値の範囲を表し、ヒストグラムは各バケットに入る値の数をカウントします。このメトリクスタイプは、リクエストのレイテンシやレスポンスサイズなどの測定値を追跡するのに役立ちます。分布を理解することで、単に平均を知るよりも多くの洞察を得られるためです。
HTTP リクエストのレイテンシを追跡するヒストグラムを実装するには、次のコードスニペットを使用できます。この例では、各 HTTP リクエストの処理にかかる時間を測定するために、複数のバケットを持つヒストグラムを設定します。with ブロックは、リクエスト処理の時間を自動的に測定し、適切なバケットに記録します。
from prometheus_client import Histogram
# Define a histogram with buckets for request latency
request_latency_histogram = Histogram('http_request_latency_seconds', 'HTTP request latencies', buckets=[0.1, 0.2, 0.5, 1, 2, 5])
def handle_request(request):
with request_latency_histogram.time():
# Process the request
# This automatically measures the time taken by this block and records it in the histogram
pass
ヒストグラムのバケットとその重要性
バケット設計: 有用なヒストグラムを作成するには、適切なバケットを選択することが重要です。バケットは、アプリケーションのパフォーマンス目標やしきい値に合わせる必要があります。たとえば、0.1 秒かかるリクエストと 1 秒かかるリクエストを区別することが重要な場合、バケットはこれらの間隔を反映すべきです。
粒度: バケットを増やすとヒストグラムの粒度は高くなりますが、メモリ使用量も増加します。詳細さとリソース効率のバランスを取ってください。
累積カウント: Prometheus のヒストグラムは累積的です。つまり、各バケットはその範囲およびそれ以前のすべての範囲に入る観測値の総数をカウントします。これによりパーセンタイルが計算され、平均よりもデータ分布に関して有益な情報が得られます。
クエリでの使用: ヒストグラムをクエリする際、histogram
_quantile()のような関数は累積バケットから分位数を計算でき、システムのパフォーマンス特性に関する強力な洞察を提供します。
サマリーメトリクス
Prometheus のサマリーメトリクスは、リクエストレイテンシの 90 パーセンタイルなど、観測値の分位数をクライアント内で直接計算する方法を提供します。データを収集してバケットに分類するヒストグラムとは異なり、サマリーは事前定義されたバケットなしでストリーミング分位数を計算します。これにより、正確な分位数計算が必要な状況、特にサービスレベル契約（SLA）の報告など、正確なしきい値が重要な場合にサマリーが理想的になります。
データベースクエリのレイテンシを測定するサマリーを実装するには、次のコードスニペットを使用できます。この例では、データベースクエリにかかる時間を監視するサマリーを設定します。with ブロックはクエリの所要時間を測定し、この新しい観測値でサマリーを更新することで、分位数の計算を容易にします。
from prometheus_client import Summary
# データベースクエリのレイテンシを測定するサマリーを作成する
db_query_latency = Summary('db_query_latency_seconds', 'Database query latencies')
def query_database(query):
with db_query_latency.time():
# データベースクエリを実行する
# このブロックにかかった時間は自動的に記録され、サマリーで計算される
pass
ヒストグラムとサマリーの違い
分位数の計算: ヒストグラムは定義されたバケットに基づいて分位数を推定するため、バケット設定によっては不正確さが生じる可能性があります。サマリーは観測データから直接分位数を計算するため、より高い精度を提供できる可能性があります。
クライアント側の負荷: サマリーはクライアント側で分位数を計算するため、特に観測数が多い場合に計算負荷が増加する可能性があります。事前定義されたバケットを持つヒストグラムは、クライアント側の計算を削減できます。
設定: ヒストグラムでは、適切なバケットを設定するために分布に関する事前知識が必要です。サマリーではバケット設定は不要なため、初期導入は容易ですが、リソース消費がより大きくなる可能性があります。
ユースケース: 重要なメトリクスについて正確なリアルタイム分位数が必要な場合はサマリーが好まれます。一方、正確なしきい値がそれほど重要でないメトリクスのより広範な分布を捉えるには、ヒストグラムの方が適していることが多いです。
ラベル付けとメトリクスのグループ化のベストプラクティス
ラベルの適切な使用
Prometheus のラベルは、より詳細で対象を絞ったクエリのためにメトリクスにメタデータを付加するキーと値のペアです。サービス名、ホスト名、エラータイプなどの次元にわたってメトリクスを整理および識別するうえで重要です。ラベルを使用する際のベストプラクティスを以下に示します。
説明的で一貫性があること: 目的を明確に説明するラベル名を選び、メトリクス全体で一貫性を維持します。たとえば、所属するサービスを識別するすべてのメトリクスに service を使用します。
必要な粒度: ラベルはメトリクスに重要な詳細を追加できますが、ラベルが多すぎるとストレージコストが増加し、クエリ性能が低下する可能性があります。粒度と性能のバランスを取るために、ラベルは慎重に使用してください。
高カーディナリティを避ける: 個々のユーザーやメールアドレスすべてにラベルを付ける可能性があるような高カーディナリティのラベルは、データサイズを増加させ、性能を低下させる可能性があります。妥当な数の個別値を持つラベルにとどめてください。
この例では、詳細な分析と監視のために、異なる HTTP メソッドとステータスを区別するラベルを使用するカウンターを示しています。
from prometheus_client import Counter
# HTTP メソッドとレスポンスステータス用のラベルを持つカウンターを作成する
http_requests_total = Counter('http_requests_total', 'Total HTTP requests',
['method', 'status'])
def handle_request(request):
# 適切なラベルでカウンターをインクリメントする
http_requests_total.labels(method=request.method, status=request.response.status_code).inc()
メトリクスをグループ化するための戦略
メトリクスを論理的にグループ化すると、明確さが向上し、監視システムの性能を改善できます。以下にいくつかの戦略を示します。
タイプ別に分類: エラー、トラフィック、レイテンシなどのタイプ別にメトリクスをグループ化すると、関連するメトリクスを見つけて分析しやすくなります。
サービスベースのグループ化: 測定対象のサービス別にメトリクスを整理します。これにより、特定のサービス内の問題を迅速に切り分けるのに役立ちます。
階層的な命名を使用する: メトリクスに名前を付ける際は、
service_database_queries_totalまたはservice_http_requests_totalのように、グループ化を反映した階層構造を検討してください。
効果的なグループ化のメリット
クエリパフォーマンスの向上: 論理的なグループ化により、各クエリでスキャンする必要があるメトリクスの数を減らせるため、より効率的なクエリにつながります。
アラート管理の容易化: 類似したメトリクスをグループ化すると、アラートルールの作成が簡素化され、システムのさまざまな部分にまたがるアラートを管理しやすくなります。
より優れた可視化: グループ化されたメトリクスはダッシュボードで可視化しやすく、関連するメトリクスをまとめて表示できるため、システムパフォーマンスの一貫したビューを提供できます。
PromQLによるメトリクスのクエリ
PromQLの基本とその構文
PromQL、つまりPrometheus Query Languageは、Prometheusがデータを探索し、アラートを生成するために使用する強力なクエリ言語です。PromQLでは、メトリクスから必要な正確なデータを計算するために、単純なクエリから複雑なクエリまで実行できます。PromQLの構文は、メトリクス名、ラベル、時間間隔に基づいて時系列データを選択および集約することをサポートしています。
PromQLの主な機能:
インスタントクエリと範囲クエリ: インスタントクエリは特定の時点における時系列の現在値を提供し、範囲クエリは一定期間にわたる時系列の値を返します。
関数と演算子: PromQLには、レート、平均、メトリクス間の算術演算を計算するためのさまざまな組み込み関数と演算子が含まれています。
コードスニペット: 各メトリクスタイプの一般的なクエリ
カウンターメトリクス
このクエリは、過去5分間のHTTPリクエストの1秒あたりの平均レートを計算し、サーバー上のトラフィック負荷を監視するのに役立ちます。
rate(http_requests_total[5m])
ゲージメトリクス
このインスタントクエリは現在の空きメモリ量を取得し、システムリソースのスナップショットを提供します。
node_memory_MemFree_bytes
ヒストグラムメトリクス
次のクエリは、過去10分間のリクエストレイテンシの95パーセンタイルを計算し、Webサーバーのパフォーマンスにおける外れ値を特定するのに役立ちます。
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[10m]))
サマリーメトリクス
以下のクエリは、処理済みイベントのレイテンシの中央値を計算します。これは、イベント処理システムのパフォーマンスを評価するうえで重要です。
quantile(0.5, rate(processed_events_latency_seconds_sum[5m]) / rate(processed_events_latency_seconds_count[5m]))
PromQLで効果的にクエリするためのヒント:
適切な時間範囲を使用する: 長期間の履歴データクエリでシステムに過負荷をかけることなく、有意義な洞察を提供する時間範囲を選択してください。
ラベルフィルタリングを活用する: ラベルを使用して結果をフィルタリングおよび絞り込み、特定のデータサブセットに焦点を当てます。
パフォーマンスを最適化する: 特にダッシュボードやアラート向けにクエリを作成する際は、そのパフォーマンスへの影響を考慮し、効率的に実行されるよう最適化してください。
PrometheusによるMilvusベクトルデータベースのパフォーマンス監視
Milvusは、オープンソースで高性能かつ高スケーラビリティなベクトルデータベースであり、高次元のベクトル埋め込みを通じて、10億規模の非構造化データを保存、インデックス化、検索できます。検索拡張生成（RAG）、セマンティック検索、マルチモーダル検索、レコメンデーションシステムなどの最新のAIアプリケーションを構築するのに最適です。Milvusは、ノートPCやエッジデバイスから大規模分散システムまで、さまざまな環境で効率的に動作します。
Prometheus は、Milvus ベクトルデータベースのパフォーマンスを監視するための包括的な機能を提供します。Milvus は以下を通じて Prometheus とシームレスに統合されます。
Prometheus Endpoint: さまざまなエクスポーターからデータを収集します。
Prometheus Operator: Prometheus 監視設定の管理を効率化します。
Kube-Prometheus: 堅牢な運用のために、Kubernetes クラスター全体の監視を簡素化します。
Prometheus を利用することで、クエリ応答時間やリソース使用量（CPU、GPU、メモリ）など、Milvus のパフォーマンスに関する重要なメトリクスを追跡でき、問題の事前解決とシステム最適化が可能になります。さらに、Prometheus を Grafana と統合することで、監視フレームワークがさらに強化され、GenAI および similarity search アプリケーション向けに調整された Milvus デプロイメントの詳細な分析と効率的な保守のための詳細なダッシュボードが提供されます。
Milvus 向けに Prometheus を設定し、Grafana でメトリクスを可視化するための包括的なガイダンスについては、以下のリソースをご覧ください。
結論
結論として、Prometheus はシステムの健全性とパフォーマンスを反映するさまざまなメトリクスを監視するための有用なツールです。Prometheus の機能を使用して重要な運用データを追跡、分析、可視化することで、チームは監視の実践を強化し、システムが安定しているだけでなく効率性のために最適化されていることを確実にできます。潜在的な問題を早期に検出するためのアラート設定であれ、システムメトリクスを明確に把握するための詳細なダッシュボードの使用であれ、Prometheus は開発者と管理者が高性能で信頼性の高いサービスを維持できるようにします。
FAQs
- Prometheus における 4 種類のメトリクスとは何ですか？
Prometheus はメトリクスを、カウンター、ゲージ、ヒストグラム、サマリーの 4 種類に分類します。それぞれの種類は、イベントの発生回数のカウントから、時間の経過に伴う測定値の分布の取得まで、特定の監視目的に役立ちます。
- ヒストグラムとサマリーのどちらを使うべきか、どのように選べばよいですか？
分布を取得する必要があり、意味のあるバケットを事前に定義できる場合は、ヒストグラムを選択してください。正確な分位数計算が必要で、事前定義されたバケットを必要としない場合は、サマリーを使用してください。選択は、具体的なユースケースとパフォーマンス上の考慮事項によって異なります。
- PromQL とは何で、Prometheus でどのように使用されますか？
PromQL、または Prometheus Query Language は、Prometheus でメトリクスをクエリするために使用される強力な言語です。ユーザーは時系列データを選択および集計し、計算を実行し、特定の条件や時間範囲に基づいてメトリクスから洞察を導き出すことができます。
- マイクロサービスアーキテクチャで構築されていないアプリケーションの監視に Prometheus を使用できますか？
はい、Prometheus は、マイクロサービスアーキテクチャを使用して構築されているか、より従来型のモノリシックなアプローチで構築されているかにかかわらず、幅広いアプリケーションを監視できる柔軟性があります。Prometheus Exposition Format でデータを公開するほぼあらゆるソースからメトリクスをスクレイプするように設定できます。
- Prometheus でメトリクスにラベルを付けたりグループ化したりする際のベストプラクティスにはどのようなものがありますか？
メトリクスにラベルを付けてグループ化する際は、ラベルが説明的であり、メトリクス全体で一貫していることを確認してください。パフォーマンスを低下させる可能性のある高カーディナリティのラベルは避けてください。明確性を高め、クエリ効率を向上させるために、種類やサービスごとにメトリクスを論理的にグループ化します。これにより、クエリと管理が容易な整理された監視システムを維持できます。