Prometheus が NAT 経由でメトリックをスクレイピングできるようにするツール - PushProx

Prometheus は Pull モードを使用して監視インジケーターをプルすることがわかっていますが、直接アクセスできないシナリオでは、追加のメソッドが必要になります。このシナリオでは PushProx が使用されます。 PushProx は、メトリックをプルするための Pull モデルに従いながら、Prometheus が NAT やその他の同様のネットワークトポロジを通過できるようにするクライアントおよびプロキシです。

建築

PushProx は主にプロキシとクライアントの 2 つの部分で構成されます。プロキシは、Prometheus サーバーからメトリック要求を受信する役割を担い、要求情報をクライアントにプロキシします。クライアントはローカルデバイスからメトリックを取得した後、その結果をプロキシに返します。プロキシは Prometheus がアクセスできる場所にデプロイする必要があり、クライアントは収集が必要なノードが配置されているネットワークにデプロイされます。

以下のネットワーク環境に適用可能です。

Prometheus はクライアント ECS に直接アクセスできません。
Prometheus は、クライアントが配置されている VPC 内の ECS (PushProx プロキシ) にアクセスでき、イントラネットを貫通するかパブリックネットワークを公開することで PushProx プロキシに到達できます。
顧客 EC と PushProx エージェントは同じ VPC 内にあります。

各クライアントには FQDN 識別子があります。 Prometheus は PushProx を通じてターゲット fqdn-x を取得すると、次の操作を実行します。

クライアントはプロキシにフェッチ要求をポーリングし、そのポーリングに FQDN を含めます (1)。クライアントはプロキシに POST リクエストを送信しますが、プロキシは応答しません。
Prometheusはプロキシ（2）を介してホスト名fqdn-xを持つターゲットをクロールしようとします。 Prometheus は GET リクエストをプロキシに送信し、プロキシはそれを fqdn-x に基づいて正しいクライアントにルーティングします。現時点ではプロキシは応答しません。
フェッチ要求は、ステップ 1 (3) のクライアント POST 要求に応答してプロキシがクライアントに送信する応答メッセージに含まれています。
フェッチ要求はクライアントによって実行されます（4）。
キャプチャされたデータにはインジケーター（5）の応答が含まれており、エージェント（6）に公開されます。
プロキシは、Prometheusがステップ2でGETリクエストを送信すると、それを応答メッセージとしてPrometheus（7）に返します。

PushProx はすべての HTTP ヘッダーを透過的に渡し、圧縮や accept-encoding などの機能はスクレイピング Prometheus サーバーに依存します。

テスト

ここでは、テストに次のコンポーネントを使用する必要があります。

node_exporter はノードのいくつかの基本的なメトリックを公開します。
pushprox-client と node_exporter は、データを収集する必要がある NAT 環境のノードに一緒にデプロイされます。
pushprox-proxy と prometheus は両方とも外部ネットワークにデプロイされます。 prometheus は pushprox-proxy サービスにアクセスできます。

プロキシはクライアント上でTLS認証を実行します

プロキシとクライアントの間に認証がなく、クライアントの IP アドレスが不確かで、プロキシがクライアントのファイアウォールポリシーを構成できないため、プロキシとクライアントの間に認証を追加する必要があります。

tls を使用してクライアントを検証します。 Pushprox-proxy は tls をサポートしていないため、pushprox-proxy へのリバースプロキシとして nginx が必要であり、次に tls が nginx で構成され、ssl_verify_client が nginx で有効になります。 pushprox-client は、nginx への TLS クライアント接続をサポートします。 pushprox-client では、SSL 標準 x509 で定義された拡張機能である SAN (Subject Alternative Name) をサポートするために tls が必要です。したがって、自己署名証明書を生成するときは SAN をサポートする必要があります。ここで、https://github.com/ljq/gen-tlsv3-san-ca を参照して自己署名証明書を生成できます。

pushprox-proxyを起動する

pushprox-proxy はパブリックネットワーク上のサーバーに展開する必要があり、各クライアントとの長い接続を維持する必要があります。クライアントが多数ある場合、プロキシは負荷分散を考慮する必要があります。

 ./pushprox-プロキシ

nginxの設定

nginx リバースプロキシを pushprox-proxy に接続し、nginx で tls を設定します (pushprox.conf):


 アップストリームプロキシバックエンド{
 サーバー127.0.0.1 : 8080 ;
 }
 サーバー{
 443 ssl をリッスンします。
 サーバー名promprox .k8s .local ;
 ssl オン;
 ssl_certificate / opt / xk-self-cert / server .crt ; #証明書の場所を設定する
ssl_certificate_key / opt / xk-self-cert / サーバー.key ; #キーの場所を設定する
ssl_client_certificate / opt / xk-self-cert / ca .crt ; #双方向認証
ssl_verify_client オン; #双方向認証
ssl_session_timeout 5分;
 ssl_プロトコルSSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 ; # このプロトコルに従って設定する
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256 : HIGH : !aNULL : !MD5 : !RC4 : !DHE ; #このスイートに従って構成する
ssl_prefer_server_ciphers オン;
 位置/ {
 proxy_pass http :// prox-backend /;
 }
 }

クライアントを起動する

pushprox-client は、自己署名証明書の ca とクライアント crt を構成する必要があります。

 ./ pushprox-client --proxy-url = https :// promprox .k8s .local --tls .cacert =/ opt / xk-self-cert / ca .crt --tls .cert =/ opt / xk-self-cert / client .crt --tls .key =/ opt / xk-self-cert / client .key

プロメテウスを起動

 ./ prometheus --config .file = prometheus-prox .yml

設定ファイルは次のようになります。

 # プロメテウスprox.yml
 グローバル:
 スクレイプ間隔: 15秒
評価間隔: 15秒
# スクレイピングするエンドポイントを1 つだけ含むスクレイピング設定:
 # ここはプロメテウスそのものです。
 scrape_configs : スクレイプ設定:
 - ジョブ名: ノード
proxy_url : http : //xx.xx.xx.xx :8080 / # プロキシアドレスとして設定
静的構成:
 - ターゲット: [ ' ceph-local:9100' ] # クライアントのFQDN が「client」 であると想定します。