Datadog Agent は、オートディスカバリーメカニズムによってコンテナを自動検出し、チェック構成を作成できます。
クラスターチェックは機能を拡張し、次のようなコンテナ化されていないワークロードを監視します。
各チェックのインスタンスが 1 つだけ実行されるように、Cluster Agent は構成を保持し、それをノードベースの Agent に動的にディスパッチします。Agent は 10 秒ごとに Cluster Agent に接続し、実行する構成を取得します。1 つの Agent が報告を停止した場合、Cluster Agent はその Agent をアクティブなプールから削除し、他の Agent に構成をディスパッチします。これにより、クラスターにノードが追加または削除されても、常にインスタンスが 1 つだけ実行されることになります。
クラスターチェックによって収集されたメトリクス、イベント、およびサービスチェックは、ホスト名は関連がないため、それ無しで送信されます。データの絞り込みやスライスを実行できるように、cluster_name タグが追加されます。
この機能は、Kubernetes 上で Agent のバージョン 6.9.0+ および Cluster Agent のバージョン 1.2.0+ でサポートされています。
この機能では、Cluster Agent を実行しておく必要があります。
そして、クラスターチェック機能を有効にします。
バージョン1.2.0より、Datadog Cluster Agentはコンテナ化されていないクラスターリソースに対し、オートディスカバリー機構を拡張しています。有効にするには、Cluster Agentの展開に以下の変更を加える必要があります。
DD_CLUSTER_CHECKS_ENABLED を true に設定します。DD_CLUSTER_NAME とします。メトリクスにスコープを当てるため、Datadog は全ての構成に cluster_name インスタンスタグとしてクラスター名を挿入します。DD_LEADER_LEASE_DURATION で設定できます。datadog-cluster-agent と異なる場合は、サービス名が DD_CLUSTER_AGENT_KUBERNETES_SERVICE_NAME の環境変数に反映されるようにします。現在、以下の二つの構成ソースがサポートされています。オートディスカバリーに関するドキュメントに記載されています。
/conf.d フォルダの ConfigMap から YAML ファイルをマウントできます。画像のエントリーポイントで自動的にインポートされます。DD_EXTRA_CONFIG_PROVIDERS および DD_EXTRA_LISTENERS 環境変数をどちらも kube_services に設定する必要があります。ホスト名は、ホストタグと DD_TAGS の環境変数の使用を制限するクラスターチェックメトリクスにリンクしていません。クラスターチェックメトリクスにタグを追加するには、DD_CLUSTER_CHECKS_EXTRA_TAGS の環境変数を使用します。
Datadog Node Agent で clusterchecks 構成プロバイダーを有効にします。それには 2 つの方法があります。
DD_EXTRA_CONFIG_PROVIDERS の環境変数を設定します。複数の値がある場合には、スペースで区切られたストリングになります。
DD_EXTRA_CONFIG_PROVIDERS="clusterchecks"または、datadog.yaml 構成ファイルに追加します。
config_providers:
- name: clusterchecks
polling: trueAgent を再起動して、コンフィギュレーションの変更を適用します。
注: Datadog Helm Chart により、クラスターチェックのみを実行するように構成された一連の Datadog Agent を clusterChecksRunner フィールドを介してデプロイできます。
全てのノードベースの Agent による実行が可能であれば、クラスターチェックとしての Agent のカスタムチェックの実行がサポートされています。これにより、チェックのコードは以下のようになります。
clusterchecks の構成プロバイダが有効になっている全てのノードベースの Agent にインストールされていること。Cluster Agent はクラスターチェックに対する高度なディスパッチロジックを使用するように構成できます。これには、チェックインスタンスからの実行時間およびメトリクスサンプルが考慮されます。このロジックにより Cluster Agent はクラスターチェックランナー間のディスパッチと分散を最適化できます。
Cluster Agent のセットアップ ドキュメントにある手順に加え、DD_CLUSTER_CHECKS_ADVANCED_DISPATCHING_ENABLED を true とします。
以下の環境変数は、クラスターチェックランナー（またはノード Agent）を構成する際、チェック統計を公開するために必要となります。統計は Cluster Agent によりコンシュームされ、クラスターチェックのディスパッチロジックを最適化するのに使用されます。
env:
- name: DD_CLC_RUNNER_ENABLED
value: "true"
- name: DD_CLC_RUNNER_HOST
valueFrom:
fieldRef:
fieldPath: status.podIPリソースの IP が変わらない場合 (例: 外部サービスエンドポイント、パブリック URL など)、静的構成を YAML ファイルとして Cluster Agent に渡すことができます。ファイル命名規則と構文はノードベースの Agent に対する静的構成と同じですが、cluster_check: true 行が追加されています。
CloudSQL インスタンスと Datadog ユーザーを設定後、/conf.d/mysql.yaml ファイルを以下の内容と共に Cluster Agent にマウントします。
cluster_check: true
init_config:
instances:
- server: '<PRIVATE_IP_ADDRESS>'
port: 3306
user: datadog
pass: '<YOUR_CHOSEN_PASSWORD>'cluster_check のフィールドにより、Cluster Agent にこのチェックを一つのノードベースの Agent に委任するよう知らせます。
Kubernetes ポッドのアノテーションの構文と同様に、以下の構文でサービスをアノテーションできます。
ad.datadoghq.com/service.check_names: '[<INTEGRATION_NAME>]'
ad.datadoghq.com/service.init_configs: '[<INIT_CONFIG>]'
ad.datadoghq.com/service.instances: '[<INSTANCE_CONFIG>]'%%ホスト%% テンプレート変数がサポートされ、これがサービスの IP に置き換えられます。kube_namespace タグと kube_service タグは、自動的にインスタンスに追加されます。
tags.datadoghq.com/env: "<ENV>"
tags.datadoghq.com/service: "<SERVICE>"
tags.datadoghq.com/version: "<VERSION>"tags.datadoghq.com ラベルは、チェックによって生成されたデータのタグとして、env、service、さらには version を設定します。
これらの標準ラベルは、統合サービスタグ付けの一部です。
以下のサービス定義では、my-nginx デプロイからポッドを外部に出し、HTTP チェックを実行させて負荷分散サービスの待ち時間を測定します。
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",
"url": "http://%%host%%",
"timeout": 1
}
]
spec:
ports:
- port: 80
protocol: TCP
selector:
run: my-nginxさらに、各ポッドを NGINX チェックで監視する必要があります。NGINX チェックは、サービス全体だけでなく各ワーカーの監視も可能です。
分散型という性質上、クラスターチェックのトラブルシューティングは多少複雑です。以下のセクションでは、ディスパッチプロセスと関連するトラブルシューティングコマンドについて説明します。
リーダー選択が可能な場合、リーダーだけがクラスターチェック構成をノードベースの Agent に送ります。リーダー名は datadog-leader-election の ConfigMap で見られます。
# kubectl get cm datadog-leader-election -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
annotations:
control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"cluster-agent-rhttz", ...''cluster-agent-rhttz です。
Cluster Agent に構成 (静的またはオートディスカバリー) が分かるよう、Cluster Agent のリーダーの configcheck コマンドを使用します。
# kubectl exec <CLUSTER_AGENT_POD_NAME> agent configcheck
...
=== http_check cluster check ===
Source: kubernetes-services
Instance ID: http_check:My service:6e5f4b16b4b433cc
name: My service
tags:
- kube_namespace:default
- kube_service:my-nginx
timeout: 1
url: http://10.15.246.109
~
Init Config:
{}
Auto-discovery IDs:
* kube_service://751adfe4-1280-11e9-a26b-42010a9c00c8
===clusterchecks コマンドにより、以下を含むディスパッチロジックの状態をチェックできます。
各ノードにどのチェックがディスパッチされているか
# kubectl exec <CLUSTER_AGENT_POD_NAME> agent clusterchecks
=== 3 node-agents reporting ===
Name Running checks
default-pool-bce5cd34-7g24.c.sandbox.internal 0
default-pool-bce5cd34-slx3.c.sandbox.internal 2
default-pool-bce5cd34-ttw6.c.sandbox.internal 1
...
===== Checks on default-pool-bce5cd34-ttw6.c.sandbox.internal =====
=== http_check check ===
Source: kubernetes-services
Instance ID: http_check:My service:5b948dee172af830
empty_default_hostname: true
name: My service
tags:
- kube_namespace:default
- kube_service:my-nginx
- cluster_name:ccheck_testing
timeout: 1
url: http://10.15.246.109
~
Init Config:
{}
===注: configcheck コマンドとはインスタンス ID が異なりますが、インスタンスが変更されてタグとオプションが追加されるためです。
default-pool-bce5cd34-ttw6 ノードにディスパッチされます。
Agent の configcheck コマンドは、cluster-checks ソース付きのインスタンスを表示します。
# kubectl exec <NODE_AGENT_POD_NAME> agent configcheck
...
=== http_check check ===
Source: cluster-checks
Instance ID: http_check:My service:5b948dee172af830
empty_default_hostname: true
name: My service
tags:
- kube_namespace:default
- kube_service:my-nginx
- cluster_name:ccheck_testing
timeout: 1
url: http://10.15.246.109
~
Init Config:
{}
===インスタンス ID は初期のものと一致します。
Agent の status コマンドは、正しく実行されて報告を行っているチェックインスタンスを表示します。
# kubectl exec <NODE_AGENT_POD_NAME> agent status
...
http_check (3.1.1)
------------------
Instance ID: http_check:My service:5b948dee172af830 [OK]
Total Runs: 234
Metric Samples: Last Run: 3, Total: 702
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 1, Total: 234
Average Execution Time : 90msお役に立つドキュメント、リンクや記事:
このページ
