オートディスカバリーによるエンドポイントチェック

概要

クラスターチェック機能は、Kubernetes サービスなど、負荷分散型のクラスターサービスを自動検出してチェックを実行する機能を提供します。_エンドポイントチェック_はこのメカニズムを拡張し、Kubernetes サービスによって管理される各エンドポイントを監視します。

Cluster Agent は、Kubernetes サービス上のオートディスカバリーアノテーションに基づいてエンドポイントチェック構成を検出します。その後、Cluster Agent はこれらの構成をノードベースの Agent にディスパッチし、個別に実行させます。エンドポイントチェックは、監視対象の Kubernetes サービスのエンドポイントの背後にあるポッドと同じノード上で実行される Agent にディスパッチされます。このディスパッチロジックにより、Agent は、それぞれのポッドに対して既に収集したポッドおよびコンテナタグを追加することができます。

ノートベースの Agent は 10 秒ごとに Cluster Agent に接続し、実行するチェックの構成を取得します。エンドポイントチェックで取得したメトリクスは、サービスタグ、Kubernetes タグ、ホストタグ、そして評価対象の IP アドレスに応じた kube_endpoint_ip タグを付けて送信されます。

バージョニング: この機能は、Kubernetes for Datadog Agent v6.12.0 以上および Datadog Cluster Agent v1.3.0 以上でサポートされています。v1.4.0 以上の Cluster Agent では、配下にポッドを持たないエンドポイントに対するエンドポイントチェックが、すべて通常のクラスターチェックに変換されます。この機能を利用するには、(エンドポイントチェック機能に加えて) クラスターチェック機能を有効にしてください。

注: サービスの背後にあるポッドが静的なものである場合、アノテーション ad.datadoghq.com/endpoints.resolve を追加する必要があります。Datadog Cluster Agent は、エンドポイントチェックとしてチェックをスケジュールし、クラスターチェックランナーにディスパッチします。Kubernetes API サーバーでこのアノテーションを使用した例を参照してください。

例: エンドポイントを持つサービス

以下の例では、NGINX 用の Kubernetes デプロイメントが 3 つのポッドで作成されています。

kubectl get pods --selector app=nginx -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE
nginx-66d557f4cf-m4c7t   1/1     Running   0          3d    10.0.0.117   gke-cluster-default-pool-4658d5d4-k2sn
nginx-66d557f4cf-smsxv   1/1     Running   0          3d    10.0.1.209   gke-cluster-default-pool-4658d5d4-p39c
nginx-66d557f4cf-x2wzq   1/1     Running   0          3d    10.0.1.210   gke-cluster-default-pool-4658d5d4-p39c

サービスも作成されました。この 3 つのエンドポイントを通じてポッドにリンクしています。

kubectl get service nginx -o wide
NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE   SELECTOR
nginx   ClusterIP   10.3.253.165   <none>        80/TCP    1h    app=nginx

kubectl get endpoints nginx -o yaml
...
- addresses:
  - ip: 10.0.0.117
    nodeName: gke-cluster-default-pool-4658d5d4-k2sn
    targetRef:
      kind: Pod
      name: nginx-66d557f4cf-m4c7t
      ...
  - ip: 10.0.1.209
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-66d557f4cf-smsxv
      ...
  - ip: 10.0.1.210
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-66d557f4cf-x2wzq
      ...

サービスベースのクラスターチェックでは、サービスの単一の IP アドレスをテストしますが、エンドポイントチェックは、このサービスと関連付けられた 3 つのエンドポイントの各々に対してスケジュールされます。

設計上、エンドポイントチェックは、この nginx サービスのエンドポイントの背後にあるポッドと同じノードで動作する Agent にディスパッチされます。この例では、 gke-cluster-default-pool-4658d5d4-k2sn と gke-cluster-default-pool-4658d5d4-p39c というノード上で動作する Agent が、これらの nginx ポッドに対してチェックを実行します。

エンドポイントチェックのディスパッチを設定する

    エンドポイントチェックのディスパッチは、Cluster Agent の Operator デプロイメントで features.clusterChecks.enabled 構成キーを使用して有効にします。

    kind: DatadogAgent
apiVersion: datadoghq.com/v2alpha1
metadata:
  name: datadog
spec:
  features:
    clusterChecks:
      enabled: true

    この構成では、Cluster Agent と ノードベースの Agent との間で、クラスターチェックとエンドポイントチェックの両方のディスパッチが可能です。

    Cluster Agent の Helm デプロイメントでは、datadog.clusterChecks.enabled 構成キーにより、エンドポイントチェックのディスパッチがデフォルトで有効になっています。

    datadog:
  clusterChecks:
    enabled: true
  # (...)
clusterAgent:
  enabled: true
  # (...)

    この構成では、Cluster Agent と Agent との間で、クラスターチェックとエンドポイントチェックの両方のディスパッチが可能です。

    Cluster Agent の設定

    Datadog Cluster Agent で、kube_endpoints コンフィギュレーションプロバイダーとリスナーを有効にします。環境変数 DD_EXTRA_CONFIG_PROVIDERS と DD_EXTRA_LISTENERS を設定します。

    DD_EXTRA_CONFIG_PROVIDERS="kube_endpoints"
DD_EXTRA_LISTENERS="kube_endpoints"

    注: 監視するエンドポイントの配下にポッドが存在しない場合は、クラスターチェックを有効にする必要があります。kube_services コンフィギュレーションプロバイダーとリスナーを追加します。

    DD_EXTRA_CONFIG_PROVIDERS="kube_endpoints kube_services"
DD_EXTRA_LISTENERS="kube_endpoints kube_services"

    Agent を再起動して、構成の変更を適用します。

    Agent の設定

    ノードベースの Agent で endpointschecks コンフィギュレーションプロバイダーを有効にします。これには 2 つの方法があります。

    • 環境変数 DD_EXTRA_CONFIG_PROVIDERS を設定します。複数の値がある場合は、スペース区切りの文字列で指定します。

      DD_EXTRA_CONFIG_PROVIDERS="endpointschecks"

    • または、datadog.yaml 構成ファイルに追加します。

      config_providers:
    - name: endpointschecks
      polling: true

    注: 監視するエンドポイントの配下にポッドが存在しない場合は、クラスターチェックを有効にする必要があります。それには clusterchecks コンフィギュレーションプロバイダーを追加します。

    DD_EXTRA_CONFIG_PROVIDERS="endpointschecks clusterchecks"

    Agent を再起動して、構成の変更を適用します。

    チェック構成の設定

    静的なコンフィギュレーションファイルからの構成

    Cluster Agent v1.18.0 からは、Kubernetes エンドポイントを対象としたチェック構成で、advanced_ad_identifiers とオートディスカバリーテンプレート変数を使用できます (例をご参照ください)。

    例: Kubernetes エンドポイントでの HTTP チェック

    Kubernetes サービスのエンドポイントに対して HTTP チェックを実行する場合

      clusterAgent.confd フィールドを使用して、チェックの構成を定義します。

      #(...)
clusterAgent:
  confd:
    <INTEGRATION_NAME>.yaml: |-
      advanced_ad_identifiers:
        - kube_endpoints:
            name: "<ENDPOINTS_NAME>"
            namespace: "<ENDPOINTS_NAMESPACE>"
      cluster_check: true
      init_config:
      instances:
        - url: "http://%%host%%"
          name: "<EXAMPLE_NAME>"

      Cluster Agent コンテナに以下の内容で /conf.d/http_check.yaml ファイルをマウントします。

      advanced_ad_identifiers:
  - kube_endpoints:
      name: "<ENDPOINTS_NAME>"
      namespace: "<ENDPOINTS_NAMESPACE>"
cluster_check: true
init_config:
instances:
  - url: "http://%%host%%"
    name: "<EXAMPLE_NAME>"

      Kubernetes のサービスアノテーションからの構成

        注: AD Annotations v2 は、インテグレーション構成を簡素化するために、Datadog Agent 7.36 で導入されました。Datadog Agent の以前のバージョンでは、AD Annotations v1 を使用してください。

        サービスにアノテーションするための構文は、Kubernetes ポッドにアノテーションするのと同様です。

        ad.datadoghq.com/endpoints.checks: |
  {
    "<INTEGRATION_NAME>": {
      "init_config": <INIT_CONFIG>,
      "instances": [<INSTANCE_CONFIG>]
    }
  }  
ad.datadoghq.com/endpoints.logs: '[<LOGS_CONFIG>]'

        この構文は %%host%% テンプレート変数をサポートしており、この変数が各エンドポイントの IP に置き換えられます。インスタンスには kube_namespace、 kube_service、kube_endpoint_ip のタグが自動的に追加されます。

        注: カスタムエンドポイントのログ構成は、Docker ソケットのログ収集時のみサポートされ、Kubernetes のログファイル収集はサポートされません。

        例: NGINX を使ったサービスに対する HTTP チェックと、サービスのエンドポイントに対する NGINX チェック

        このサービスは nginx デプロイメントのポッドに関連付けられています。この構成に基づき:

        • このサービスの背後にある各 NGINX ポッドに対して、nginx ベースのエンドポイントチェックがディスパッチされます。このチェックは、NGINX ポッドと同じそれぞれのノード上の Agent によって実行されます (ポッドの IP を %%host%% として使用します)。
        • http_check ベースのクラスターチェックは、クラスター内の 1 つの Agent にディスパッチされます。このチェックはサービスの IP を %%host%% として使用し、自動的にそれぞれのエンドポイントに負荷が分散されます。
        • チェックは、統合サービスタグ付けラベルに対応する env:prod、service:my-nginx、version:1.19.0 のタグでディスパッチされます。
        apiVersion: v1
kind: Service
metadata:
    name: nginx
    labels:
        app: nginx
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "my-nginx"
        tags.datadoghq.com/version: "1.19.0"
    annotations:
      ad.datadoghq.com/service.checks: |
        {
          "http_check": {
            "init_config": {},
            "instances": [
              {
                "url": "http://%%host%%",
                "name": "My Nginx",
                "timeout": 1
              }
            ]
          }
        }        
      ad.datadoghq.com/endpoints.checks: |
        {
          "nginx": {
            "init_config": {},
            "instances": [
              {
                "name": "My Nginx Service Endpoints",
                "nginx_status_url": "http://%%host%%:%%port%%/status/"
              }
            ]
          }
        }        
      ad.datadoghq.com/endpoints.logs: '[{"source":"nginx","service":"webapp"}]'
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        app: nginx

        サービスにアノテーションするための構文は、Kubernetes ポッドにアノテーションするのと同様です。

        ad.datadoghq.com/endpoints.check_names: '[<INTEGRATION_NAME>]'
ad.datadoghq.com/endpoints.init_configs: '[<INIT_CONFIG>]'
ad.datadoghq.com/endpoints.instances: '[<INSTANCE_CONFIG>]'
ad.datadoghq.com/endpoints.logs: '[<LOGS_CONFIG>]'

        この構文は %%host%% テンプレート変数をサポートしており、この変数が各エンドポイントの IP に置き換えられます。インスタンスには kube_namespace、 kube_service、kube_endpoint_ip のタグが自動的に追加されます。

        注: カスタムエンドポイントのログ構成は、Docker ソケットのログ収集時のみサポートされ、Kubernetes のログファイル収集はサポートされません。

        例: NGINX を使ったサービスに対する HTTP チェックと、サービスのエンドポイントに対する NGINX チェック

        このサービスは nginx デプロイメントのポッドに関連付けられています。この構成に基づき:

        • このサービスの背後にある各 NGINX ポッドに対して、nginx ベースのエンドポイントチェックがディスパッチされます。このチェックは、NGINX ポッドと同じそれぞれのノード上の Agent によって実行されます (ポッドの IP を %%host%% として使用します)。
        • http_check ベースのクラスターチェックは、クラスター内の 1 つの Agent にディスパッチされます。このチェックはサービスの IP を %%host%% として使用し、自動的にそれぞれのエンドポイントに負荷が分散されます。
        • チェックは、統合サービスタグ付けラベルに対応する env:prod、service:my-nginx、version:1.19.0 のタグでディスパッチされます。
        apiVersion: v1
kind: Service
metadata:
    name: nginx
    labels:
        app: nginx
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "my-nginx"
        tags.datadoghq.com/version: "1.19.0"
    annotations:
        ad.datadoghq.com/endpoints.check_names: '["nginx"]'
        ad.datadoghq.com/endpoints.init_configs: '[{}]'
        ad.datadoghq.com/endpoints.instances: |
            [
              {
                "name": "My Nginx Service Endpoints",
                "nginx_status_url": "http://%%host%%:%%port%%/nginx_status"
              }
            ]            
        ad.datadoghq.com/service.check_names: '["http_check"]'
        ad.datadoghq.com/service.init_configs: '[{}]'
        ad.datadoghq.com/service.instances: |
            [
              {
                "name": "My Nginx Service",
                "url": "http://%%host%%"
              }
            ]            
        ad.datadoghq.com/endpoints.logs: '[{"source":"nginx","service":"webapp"}]'
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        app: nginx

        その他の参考資料

        お役に立つドキュメント、リンクや記事:

        Cluster Agentドキュメント more more クラスターチェックドキュメント more more エンドチェックのトラブルシューティングドキュメント more more