Prometheus とは何ですか? なぜ必要なのですか?
Prometheus は、アプリケーションから数値データ (メトリック) を収集して処理する強力な監視システムです。次のような主要な指標を追跡するのに役立ちます。
- サービスによって処理されたリクエストの数。
- 各リクエストの応答時間。
- メモリと CPU の使用率。
- システム内で発生したエラーの数。
Prometheus を使用すると、次のような重要な質問に答えることができます。
「私のサービスは効率的に稼働していますか？」
「パフォーマンスのボトルネックは何ですか？」
「インフラを拡張する必要がありますか？」
Prometheus はどのようにしてメトリックを収集するのでしょうか?
Prometheus がデータを収集する方法は主に 2 つあります。
- プル モデル- Prometheus は、サービスに対してメトリックを積極的に照会します。
- プッシュ モデル (Pushgateway) - サービスはメトリクスを仲介者にプッシュし、Prometheus がそれを収集します。
詳しく見ていきましょう。
プルモデル
プル モデルでは、Prometheus は HTTP (例: http://your-service:8080/metrics ) 経由でアプリケーションからメトリックをアクティブに取得します。
これはデフォルトであり、最も一般的に使用される方法です。
Golang で Prometheus を設定する (プル モデル)
必要なライブラリをインストールします。
go get github.com/prometheus/client_golang/prometheus go get github.com/prometheus/client_golang/prometheus/promhttp
メトリックを定義します(例: HTTP リクエストのカウント)。
import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/promauto" ) var httpRequestsTotal = promauto.NewCounter(prometheus.CounterOpts{ Name: "http_requests_total", Help: "Total number of HTTP requests", })
/metricsエンドポイントを公開します。import ( "net/http" "github.com/prometheus/client_golang/prometheus/promhttp" ) func main() { http.Handle("/metrics", promhttp.Handler()) }
prometheus.ymlで、サービスからメトリックをスクレイピングするように Prometheus を設定します。scrape_configs: - job_name: "example_service" static_configs: - targets: ["localhost:8080"]
これで、Prometheus は数秒ごとにhttp://localhost:8080/metrics自動的にクエリを実行してデータを収集します。
プル モデルが好まれる理由は何ですか?
- シンプルさ- Prometheus はスクレイピングのスケジュールと頻度を制御します。
- 障害点が少ない– メトリックを受信するために追加のサービスは必要ありません。
- 自動クリーンアップ- サービスが応答を停止すると、Prometheus はデータの受信を停止し、古いメトリックを回避します。
プッシュモデル（プッシュゲートウェイアプローチ）
プッシュ モデルでは、サービスはメトリックをPushgatewayと呼ばれる中間サービスに送信し、Prometheus が取得するまでそのメトリックを保存します。
仕組み（プッシュモデル）
アプリケーションはメトリックを Pushgateway にプッシュします。
import ( "github.com/prometheus/client_golang/prometheus" "github.com/prometheus/client_golang/prometheus/push" ) func main() { registry := prometheus.NewRegistry() jobCounter := prometheus.NewCounter(prometheus.CounterOpts{ Name: "job_execution_count", Help: "Number of executed jobs", }) registry.MustRegister(jobCounter) jobCounter.Inc() err := push.New("http://localhost:9090", "my_service_or_job"). Collector(jobCounter). Grouping("instance", "worker_1"). Push() if err != nil { panic(err) } }
Pushgateway からデータを収集するように Prometheus を構成します。
scrape_configs: - job_name: "pushgateway" static_configs: - targets: ["localhost:9091"]
プッシュモデルは実際いつ役立つのでしょうか?
- Prometheus がスクレイピングする前に完了する短命のジョブ (バッチ タスク、cron ジョブ) 。
- Prometheus がサービスに直接アクセスできないネットワーク制限。
- 直接スクレイピングできない外部データ ソース(IoT デバイス、外部 API)。
どのモデルを使用すべきでしょうか?
方法 | 最適な用途... | 長所 | 短所 |
|---|---|---|---|
プル（推奨） | Web サービス、API、長期実行アプリケーション | シンプルなセットアップ、依存関係の少なさ、自動クリーンアップ | 非常に短時間のタスクには適していません |
プッシュ（プッシュゲートウェイ） | バッチジョブ、安定したネットワークアクセスのないタスク | 短命ジョブからデータをプッシュできます | 古いデータ、余分な複雑さ、ボトルネックのリスク |
プッシュモデルが理想的ではない理由
Pushgateway はいくつかの問題を解決しますが (例: Prometheus がスクレイピングする前に終了する短命なプロセス)、いくつかの新しい問題も発生します。
- 古いデータの管理が難しい
サービスが停止した場合、古いメトリックは Pushgateway に残ります。
Prometheus には、サービスがまだ実行されているかどうかを知る方法がありません。
push.Delete(...)を使用して古いメトリックを手動で削除するか、有効期限ポリシーを構成する必要があります。
- さらなる複雑さ
直接のService → Prometheusリンクの代わりに、 Service → Pushgateway → Prometheusが使用されるようになりました。
Pushgateway は追加の依存関係であり、メンテナンスのオーバーヘッドが増加します。
- 潜在的なボトルネック
多くのサービスがメトリックを頻繁にプッシュすると、Pushgateway が過負荷になる可能性があります。
直接の Prometheus スクレイピング (負荷を分散する) とは異なり、すべてのリクエストは単一の Pushgateway インスタンスにヒットします。
- データの一貫性の問題
- 複数のサービスが同じ名前で異なる値を持つメトリックをプッシュすると、データが上書きされ、誤った結果が生じる可能性があります。
結論
Prometheus は、サービスを監視するための強力で信頼性の高いツールです。ほとんどのアプリケーションでは、プル モデルが最適な選択肢です。シンプルで効率的であり、複雑さを増すことなく最新のデータを確保できます。ただし、Lambda 関数やバッチ ジョブなどの短命のプロセスを使用している場合は、プロセスが終了する前にメトリックをキャプチャするために、Pushgateway 経由のプッシュ モデルが役立ちます。
適切なアプローチを選択すると、システムの監視性と保守性が向上します。
気をつけて！
