Autodiscovery によるエンドポイントチェックの実行
Incident Management が一般に使用できるようになりました。 Incident Management が広範に使用できるようになりました。

Autodiscovery によるエンドポイントチェックの実行

オートディスカバリーの動作

クラスターチェックは、負荷分散型のクラスターサービス（Kubernetes サービスなど）でオートディスカバリーを行い、チェックを実行する働きを持ちます。

エンドポイントチェックは機能を拡張し、クラスターサービスのあらゆるエンドポイントを監視します。

クラスター Agent はコンフィギュレーションを保持し、公開することで、ノードベースの Agent がそれを読み込んでエンドポイントチェックに変換できるようにします。

エンドポイントチェックは、監視されるサービスのエンドポイントをホストするポッドと同じノードで動作している Agent によってスケジューリングされます。

Agent は 10 秒おきにクラスター Agent に接続し、チェックを実行するためのコンフィギュレーションを取得します。また、エンドポイントチェックからメトリクスを受け取ると、サービス、ポッド、ホストのタグを付けて転送します。

この機能は、Kubernetes 上で Agent のバージョン 6.12.0+ および Cluster Agent のバージョン 1.3.0+ でサポートされています。

バージョン 1.4.0 より、クラスター Agent は、ポッドにホストされないエンドポイントのチェックをすべて、通常のクラスターチェックに変換するようになりました。この機能を利用するには、クラスターチェック機能を、エンドポイントチェックと合わせて有効にする必要があります。

例: nginx サービスによって公開された 3 つの NGINX ポッド

# kubectl get svc 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 pods --selector app=nginx
NAME                     READY   STATUS    RESTARTS   AGE
nginx-758655469f-59q9z   1/1     Running   0          20h
nginx-758655469f-k8zrc   1/1     Running   0          20h
nginx-758655469f-lk9p6   1/1     Running   0          20h

# kubectl get ep nginx -o yaml
...
- addresses:
  - ip: 10.0.0.117
    nodeName: gke-cluster-default-pool-4658d5d4-k2sn
    targetRef:
      kind: Pod
      name: nginx-758655469f-lk9p6
      ...
  - ip: 10.0.1.209
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-758655469f-59q9z
      ...
  - ip: 10.0.1.210
    nodeName: gke-cluster-default-pool-4658d5d4-p39c
    targetRef:
      kind: Pod
      name: nginx-758655469f-k8zrc
      ...

エンドポイントチェックは、nginx サービスのエンドポイントをホストするポッドと同じノードで動作している Agent によってスケジューリングされます。したがって、この例であれば、gke-cluster-default-pool-4658d5d4-k2sn と gke-cluster-default-pool-4658d5d4-p39c のノードで動作する Agent だけが、nginx ポッドでのチェックをスケジューリングすることになります。

このような仕組みになっているのは、オートディスカバリーを利用するためと、これらのポッドから受け取るメトリクスにポッドとコンテナーのタグを付けるためです。

設定方法

Cluster Agent のドキュメント

Datadog クラスター 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 を再起動して、コンフィギュレーションへの変更を適用します。

Cluster Agent のドキュメント

Datadog ノード 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 を再起動して、コンフィギュレーションへの変更を適用します。

Kubernetes サービスのアノテーションによるチェックコンフィギュレーションの設定

Kubernetes ポッドへのアノテーションと同様に、次の構文でサービスにアノテーションを追加できます。

ad.datadoghq.com/endpoints.check_names: '[<インテグレーション名>]'
ad.datadoghq.com/endpoints.init_configs: '[<初期コンフィギュレーション>]'
ad.datadoghq.com/endpoints.instances: '[<インスタンスコンフィギュレーション>]'
ad.datadoghq.com/endpoints.logs: '[<ログコンフィギュレーション>]'

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

テンプレートソース: 標準ラベル

tags.datadoghq.com/env: "<ENV>"
tags.datadoghq.com/service: "<SERVICE>"
tags.datadoghq.com/version: "<VERSION>"

tags.datadoghq.com ラベルは、チェックによって生成されたデータのタグとして、env、service、さらには version を設定します。 これらの標準ラベルは、統合サービスタグ付けの一部です。

例: NGINX によってホストされるサービスの、NGINX チェックによるエンドポイントの HTTP チェック

次のサービス定義は、my-nginx デプロイからポッドを公開します。続いて、HTTP チェックを実行して負荷分散型サービスのレイテンシーを測定し、サービスのエンドポイントをホストするポッド上で NGINX チェックを実行して NGINX のメトリクスを収集し、ポッドレベルでサービスチェックを実行します。

apiVersion: v1
kind: Service
metadata:
    name: my-nginx
    labels:
        run: my-nginx
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "my-nginx"
        tags.datadoghq.com/version: "1.19.0"
    annotations:
        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%%",
                "timeout": 1
              }
            ]            
        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/endpoints.logs: '[{"source":"nginx","service":"webapp"}]'
spec:
    ports:
        - port: 80
          protocol: TCP
    selector:
        run: my-nginx

トラブルシューティング

エンドポイントチェックのトラブルシューティングは、クラスターチェックのトラブルシューティングと似ています。唯一の違いは、クラスターチェックと同時にエンドポイントチェックをスケジューリングするノードベースの Agent に対して行われる点です。

注: エンドポイントチェックは、監視されるサービスのエンドポイントをホストするポッドと同じノードで動作している Agent によってスケジューリングされます。エンドポイントがポッドをホストしない場合は、クラスター Agent がエンドポイントチェックをクラスター チェックに変換します。このクラスターチェックは、どのノードの Agent でも実行できます。

ノードベースの Agent 内のオートディスカバリー

Agent の configcheck コマンドは、endpoints-checks ソースを付けてインスタンスを表示します。

# kubectl exec <ノードの Agent のポッド名> agent configcheck
...
=== nginx check ===
Configuration provider: endpoints-checks
Configuration source: kube_endpoints:kube_endpoint_uid://default/nginx/
Instance ID: nginx:My Nginx Service Endpoints:2f7fd6b090782d6b
name: My Nginx Endpoints
nginx_status_url: http://10.0.0.75/nginx_status/
tags:
- pod_phase:running
- kube_deployment:nginx
- kube_service:nginx
- kube_namespace:default
- kube_endpoint_ip:10.0.0.75
- cluster_name:cluster
~
Init Config:
{}
Auto-discovery IDs:
* kube_endpoint_uid://default/nginx/10.0.0.75
* kubernetes_pod://4e733448-f57e-11e9-8123-42010af001ed
State: dispatched to gke-cluster-default-pool-4658d5d4-qfnt
===

Agent のステータス

Agent の status コマンドは、正しく実行されて報告を行っているチェックインスタンスを表示します。

# kubectl exec <ノードの Agent のポッド名> agent status
...
    nginx (3.4.0)
    -------------
      Instance ID: nginx:My Nginx Service Endpoints:2f7fd6b090782d6b [OK]
      Configuration Source: kube_endpoints:kube_endpoint_uid://default/nginx/
      Total Runs: 443
      Metric Samples: Last Run: 7, Total: 3,101
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 443
      Average Execution Time : 5ms

Cluster Agent 内のオートディスカバリー

Agent の configcheck コマンドは、kubernetes-endpoints ソースを付けてインスタンスを表示します。

# kubectl exec <クラスター AGENT のポッド名> agent clusterchecks
...
===== 3 Pod-backed Endpoints-Checks scheduled =====

=== nginx check ===
Configuration provider: kubernetes-endpoints
Configuration source: kube_endpoints:kube_endpoint_uid://default/nginx/
Instance ID: nginx:My Nginx Service Endpoints:f139adc46c81828e
name: My Nginx Endpoints
nginx_status_url: http://10.0.0.75/nginx_status/
tags:
- kube_service:nginx
- kube_namespace:default
- kube_endpoint_ip:10.0.0.75
- cluster_name:cluster
~
Init Config:
{}
Auto-discovery IDs:
* kube_endpoint_uid://default/nginx/10.0.0.75
* kubernetes_pod://4e733448-f57e-11e9-8123-42010af001ed
State: dispatched to gke-cluster-default-pool-4658d5d4-qfnt
===
...

その他の参考資料

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

クラスターチェックのドキュメントドキュメント more more Cluster Agent のドキュメントドキュメント more more
edit 編集

このページ