このセクションでは、NSX Advanced Load Balancer と Prometheus の統合、および Prometheus の取得要求を認証する方法について説明します。

Prometheus は、2016 年に Cloud Native Computing Foundation (CNCF) に参加したオープンソースのシステム モニタリングおよびアラート ツールキットです。他の一般的なモニタリング ソリューションとは異なり、Prometheus メトリックの収集では HTTP を使用したプル メソッドが使用されます。Prometheus の詳細については、Prometheus のホーム ページを参照してください。

Prometheus API の仕様

NSX Advanced Load Balancer Controller は、次のメトリック（Prometheus によって取り込み可能な形式のデータ）をプルするための、ファースト クラスの REST API を提供します。

  • Controller クラスタ

  • 仮想サービス

  • サービス エンジン

  • プール

Prometheus メトリックを取得するための GET API

Prometheus メトリックを取得するための GET API は次のとおりです。

GET /api/analytics/prometheus-metrics/{entity_type}/?{query_params}

ここで、entity_type は、controller、virtualservice、serviceengine、または pool です。

有効なクエリ パラメータは次のとおりです。

entity_id

エンティティ タイプに応じて、コントローラ ノード ID、プール UUID、サービス エンジン UUID、仮想サービス UUID のカンマ区切りのリストを使用できます。

entity_name

entity_type に応じて、entity_name は有効なプール、仮想サービス、またはサービス エンジン オブジェクト名のカンマ区切りのリストになります。

metric_id

メトリックのサブセットが返されるリアルタイム パラメータが true でない限り、有効なメトリック ID のカンマ区切りのリストは、デフォルトで、使用可能なすべてのメトリック ID に設定されます。API GET/api/analytics/metric_id を使用して、有効なメトリック ID を検索します。メトリックの完全なセットは、ここで提供されます。

tenant

テナント名のカンマ区切りのリスト。デフォルトでは admin に設定されます。

description

すべてのメトリックの前に説明の行をコメントとして添付します。デフォルトでは、このパラメータは false に設定されます。

realtime

5 秒の平均でエンティティ メトリックを取得するには、オブジェクトでリアルタイム メトリックが有効になっている必要があります。このパラメータはデフォルトで false に設定されています。

Prometheus での API の使用

Prometheus は、メトリック収集に HTTP を使用するプル メソッドを使用します。ユーザーは、データを取得するための HTTP エンドポイントや、スクレイピング間隔、追加のクエリ パラメータ、ポート、認可の詳細などのその他のパラメータを提供します。

Prometheus には、HTTP 取得要求を承認するための 2 つの方法があります。

  • 基本認証

  • ベアラー トークン/ベアラー トークン ファイル

コントローラから API として公開される Prometheus エンドポイントには、他のすべての既存のコントローラ API と同様に認証が必要です。NSX Advanced Load Balancer には、コントローラへの Prometheus 取得要求を認証する 2 つの方法があります。

  1. コントローラ API の基本認証の設定：

    1. クライアントから NSX Advanced Load Balancer Controller への API 呼び出しは、コントローラ API の認証メカニズムとして基本認証を使用するように設定できます。コントローラで基本認証を有効にする方法については、『VMware NSX Advanced Load Balancer 構成ガイド』の「API クエリの HTTP 基本認証」のトピックを参照してください。

    2. scrape_config の basic_auth パラメータを使用して、prometheus.yml ファイルで Prometheus 取得要求の基本認証を設定します。basic_auth が有効なコントローラ設定を使用した prometheus.yml ジョブ構成の例を次に示します。

       job_name: 'avi_vs'
    scrape_interval: 60s
    metrics_path: '/api/analytics/prometheus-metrics/virtualservice'
    params:
      entity_name: ['prod-vs1,prod-vs2']
      tenant: ['admin,tenant1']
    scheme: 'https'
    tls_config:
      insecure_skip_verify: true
    basic_auth:
      username: '[username]'
      password: '[password]'
    static_configs:
      - targets: ['[avi_controller_cluster]']
      注：

      Prometheus を使用すると、ユーザーは、TLS 構成の CA ファイル パス、クライアント証明書、およびキー ファイルを tls_config パラメータで渡すことができます。サンプル構成では、insecure_skip_verify を使用して証明書チェックをスキップしています。

  2. avi-api-proxy の使用：

    avi-api-proxy は、NSX Advanced Load Balancer の SDK 上に構築された Docker 化されたプロキシ コンテナで、NSX Advanced Load Balancer Controller の API サーバでの認証とセッション管理を処理します。avi-api-proxy へのすべての HTTP REST API 呼び出し（GET、POST、PUT、DELETE）は、有効な認可ヘッダーと Cookie を使用してコントローラ API サーバに転送されます。コントローラからの応答は、要求元のクライアント アプリケーション（この場合は Prometheus セットアップ）に返されます。

    次に、avi-api-proxy を使用した prometheus.yml ジョブ構成の例を示します。

    - job_name: 'avi_vs'
    scrape_interval: 60s
    metrics_path: '/api/analytics/prometheus-metrics/virtualservice'
    scheme: 'http'
    params:
      entity_name: ['prod-vs1,prod-vs2']
      tenant: ['admin,tenant1']
    static_configs:
      - targets: ['127.0.0.1:8080']

    avi-api-proxy が起動して実行されると、Prometheus 構成ファイルに API 認証の詳細が提供されません（avi-api-proxy を使用したサンプル prometheus.yml ジョブ構成を参照）。NSX Advanced Load Balancer Controller API サーバへの認証は、avi-api-proxy によって完全に管理されます。

    注：

    ここで指定した取得要求のターゲットは、avi-api-proxy が実行されているアドレスとポートです。指定されたサンプルで、avi-api-proxy は Prometheus セットアップと同じネットワーク ネームスペース上のポート 8080 で実行されるため、ターゲットは 127.0.0.1:8080 になります。



詳細については、「avi-api-proxy Docker コンテナ」の説明を参照してください。

注：

コンテナを起動するには、NSX Advanced Load Balancer Controller クラスタ アドレス、ユーザー名、およびパスワードが必要です。

パラメータを使用したメトリックのフィルタリング

次のいずれかを使用して、Prometheus の構成 yaml に API エンドポイントのクエリ パラメータを追加します。

  • metrics_pathfield：たとえば、metrics_path はクエリ パラメータを使用して次のように指定できます。

    /api/analytics/prometheus-metrics/pool/?tenant=admin,default&metric_id=l4_server.avg_bandwidth,l4_server.avg_connections_dropped

  • params key：キー値 yaml 形式で指定されたクエリ パラメータに対する読みやすい代替方法です。

API の応答時間を最小限に抑えるには、指定されたフィルタを使用することをお勧めします。パラメータが指定されていない場合、API は、説明文字列なしで、すべてのメトリック ID で構成される管理テナントに属するすべてのエンティティ オブジェクトのデータを取得します。

クエリ パラメータの使用方法を示す Prometheus ジョブ構成の例を次に示します。次のジョブ構成では、管理およびデフォルトのテナント ネームスペース内のすべてのプール オブジェクトに対する l4_server.avg_bandwidth および l4_server.avg_connections_dropped メトリックが取得され、メトリック データの前にメトリックの説明行が追加されます。

- job_name: 'avi_pool'
    scrape_interval: 60s
    metrics_path: '/api/analytics/prometheus-metrics/pool'
    scheme: 'http'
    params:
      tenant: ['admin,default']
      metric_id: ['l4_server.avg_bandwidth,l4_server.avg_connections_dropped']      
      description: 'true'
    static_configs: 
      - targets: ['127.0.0.1:8080']

また、管理テナントとデフォルト テナント内の特定のプール オブジェクトのメトリックを取得するには、次のように entity_name または entity_id パラメータを使用します。

params:
      entity_name: ['vs1-pool1,vs1-pool2,vs2-pool1']
      tenant: ['admin,default']
      metric_id: ['l4_server.avg_bandwidth,l4_server.avg_connections_dropped']      
      description: 'true'
注：

NSX Advanced Load Balancer は、仮想サービス、プール、および SE オブジェクトに関連する包括的なメトリック セットを提供します。このようなオブジェクトの数が多い場合、NSX Advanced Load Balancer Controller が分析データを計算して応答を返すのに時間がかかる場合があります。scrape_interval 値を低く設定すると、API タイムアウトが発生する可能性があります。このような場合は、フィルタ パラメータを使用して関連データを取得し、Prometheus 構成 yaml で scrape_interval 値を最小の 60 秒に設定します。

プロキシの利点

基本認証を許可するようにシステム設定を変更すると、すべてのコントローラ API で基本認証が有効になります。これは、一部のシナリオでは意図した動作ではない場合があります。アプリケーションは、NSX Advanced Load Balancer Controller で提供されているものと同様に、標準の HTTP REST プロトコルを介してプロキシと通信します。プロキシは、Cookie ベースの認証とセッション管理を提供するために、NSX Advanced Load Balancer の go SDK と統合されています。プロキシは、NSX Advanced Load Balancer Controller 認証情報と、プロキシを実行しているアプリケーションを使用して（可能であれば同じネットワーク ネームスペースで）インスタンス化され、avi-api-proxy を介して NSX Advanced Load Balancer Controller と通信できる必要があります。

プロキシには次の利点があります。

  • セッション管理 - プロキシは、NSX Advanced Load Balancer の go SDK を使用してセッション Cookie の管理、認証ヘッダーの設定、トークンの更新、TLS 接続の再利用を行い、TLS ハンドシェイクを減らします。

  • 再試行要求 - サーバ エラーが発生した場合、SDK は失敗した要求を再試行します。

  • 使いやすさ - システム設定の変更は必要ありません。

avi-api-proxy とアプリケーション（この場合は Prometheus）間の接続は開いている接続です。したがって、ローカルホストを介して通信を行うために、アプリケーションと同じネットワーク ネームスペースで avi-api-proxy を実行することをお勧めします。