- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
通常の Datadog Agent はノードとアプリケーションポッドに エンドポイントチェックを実行しますが、_クラスターチェックランナー_は内部の Kubernetes サービス、およびマネージドデータベースとネットワークデバイスのような外部サービスを監視するクラスターチェックの実行に特化しています。
注: クラスターチェックランナーを使用する場合、通常の Datadog Agent に対してクラスターチェックを有効化する必要はありません。
まず、Cluster Agent をデプロイします。
次に、Datadog Operator または Helm を使用してクラスターチェックランナーをデプロイします。
Operator を使用することで、単一のマニフェストでこれらのリソースすべてをローンチおよび管理することができます。例:
apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
name: datadog
spec:
global:
credentials:
apiKey: <DATADOG_API_KEY>
appKey: <DATADOG_APP_KEY>
clusterAgentToken: <DATADOG_CLUSTER_AGENT_TOKEN>
features:
clusterChecks:
enabled: true
useClusterChecksRunners: true
override:
clusterAgent:
replicas: 2
リソースをクラスターにデプロイします。
kubectl apply -f datadog-agent-with-dca-clusterchecksrunner.yaml
以下のような結果が表示された場合、コンフィギュレーションは正常に適用されています。
datadogagent.datadoghq.com/datadog created
Datadog Operator についての詳細は Datadog Operator リポジトリを参照してください。
チャートの関連するセクションを更新してクラスターチェック、Cluster Agent, クラスターチェックランナーを同時に有効化することができます。例:
datadog:
clusterChecks:
enabled: true
#(...)
clusterAgent:
enabled: true
#(...)
clusterChecksRunner:
enabled: true
replicas: 2
注: Datadog Operator および Helm チャートは、どちらも podAntiAffinity
を使用して複数のクラスターチェックランナーが同じノードに適用されるのを回避しています。Cluster Agent はノード名でクラスターチェックを識別するため、これは重要です。podAntiAffinity
を使用することで名前の衝突を避けることができます。