Cluster Agent는 엔드포인트 검사클러스터 검사 이 두 가지 유형의 검사를 발송할 수 있습니다. 두 검사는 약간 다릅니다.

엔드포인트 검사는 애플리케이션 파드 엔드포인트와 동일한 노드에 있는 일반 Datadog Agent로 특별히 발송됩니다. 애플리케이션 엔드포인트와 동일한 노드에서 엔드포인트 검사를 실행하면 메트릭에 적절한 태그를 지정할 수 있습니다.

클러스터 검사는 관리형 데이터베이스 및 네트워크 장치와 같은 외부 서비스뿐만 아니라 내부 Kubernetes 서비스를 모니터링하며 훨씬 더 자유롭게 발송될 수 있습니다. 클러스터 검사 러너 사용은 선택 사항입니다. 클러스터 검사 러너를 사용하면 소규모의 전용 Agent 세트가 클러스터 검사를 실행하고 엔드포인트 검사는 일반 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를 사용하면 이름 충돌이 발생하지 않습니다.

PREVIEWING: rtrieu/product-analytics-ui-changes