Prometheus とは何ですか? なぜ必要なのですか? Prometheus は、アプリケーションから数値データ (メトリック) を収集して処理する強力な監視システムです。次のような主要な指標を追跡するのに役立ちます。 サービスによって処理されたリクエストの数。 各リクエストの応答時間。 メモリと CPU の使用率。 システム内で発生したエラーの数。 Prometheus を使用すると、次のような重要な質問に答えることができます。 「私のサービスは効率的に稼働していますか？」 「パフォーマンスのボトルネックは何ですか？」 「インフラを拡張する必要がありますか？」 Prometheus はどのようにしてメトリックを収集するのでしょうか? Prometheus がデータを収集する方法は主に 2 つあります。 - Prometheus は、サービスに対してメトリックを積極的に照会します。 プル モデル - サービスはメトリクスを仲介者にプッシュし、Prometheus がそれを収集します。 プッシュ モデル (Pushgateway) 詳しく見ていきましょう。 プルモデル では、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 はデータの受信を停止し、古いメトリックを回避します。 自動クリーンアップ プッシュモデル（プッシュゲートウェイアプローチ） では、サービスはメトリックを と呼ばれる中間サービスに 、Prometheus が取得するまでそのメトリックを保存します。 プッシュ モデル Pushgateway 送信し 仕組み（プッシュモデル） アプリケーションは 。 メトリックを 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、長期実行アプリケーション シンプルなセットアップ、依存関係の少なさ、自動クリーンアップ 非常に短時間のタスクには適していません プッシュ（プッシュゲートウェイ） バッチジョブ、安定したネットワークアクセスのないタスク 短命ジョブからデータをプッシュできます 古いデータ、余分な複雑さ、ボトルネックのリスク プッシュモデルが理想的ではない理由 いくつかの問題を解決しますが (例: Prometheus がスクレイピングする前に終了する短命なプロセス)、 。 Pushgateway は いくつかの新しい問題も発生します 古いデータの管理が難しい サービスが停止した場合、古いメトリックは Pushgateway に残ります。 Prometheus には、サービスがまだ実行されているかどうかを知る方法がありません。 を使用して古いメトリックを手動で削除するか、有効期限ポリシーを構成する必要があります。 push.Delete(...) さらなる複雑さ 直接の リンクの代わりに、 が使用されるようになりました。 Service → Prometheus Service → Pushgateway → Prometheus Pushgateway は追加の依存関係であり、メンテナンスのオーバーヘッドが増加します。 潜在的なボトルネック 多くのサービスがメトリックを頻繁にプッシュすると、Pushgateway が過負荷になる可能性があります。 直接の Prometheus スクレイピング (負荷を分散する) とは異なり、すべてのリクエストは単一の Pushgateway インスタンスにヒットします。 データの一貫性の問題 複数のサービスが同じ名前で異なる値を持つメトリックをプッシュすると、データが上書きされ、誤った結果が生じる可能性があります。 結論 Prometheus は、サービスを監視するための強力で信頼性の高いツールです。ほとんどのアプリケーションでは、 が最適な選択肢です。シンプルで効率的であり、複雑さを増すことなく最新のデータを確保できます。ただし、Lambda 関数やバッチ ジョブなどの を使用している場合は、プロセスが終了する前にメトリックをキャプチャするために、Pushgateway 経由の が役立ちます。 プル モデル 短命のプロセス プッシュ モデル 適切なアプローチを選択すると、システムの監視性と保守性が向上します。 気をつけて！
