Datadog Agent กับ Integration

ไอเดียหลักในหนึ่งประโยค

“Agent” ไม่ได้เป็น process เดียว แต่เป็นกลุ่ม process เล็ก ๆ — core Agent, Trace Agent, Process Agent และ Security Agent (optional) — แต่ละตัวเก็บ telemetry คนละแบบ โดยมี checks และ Autodiscovery เป็นตัวตัดสินว่าจะเก็บอะไรจากที่ไหน

process ย่อยของ Agent

เวลาคนพูดว่า “ติดตั้ง Datadog Agent” จริง ๆ แล้วหมายถึง package ที่ยกกลุ่ม process ที่ทำงานร่วมกันขึ้นมา แต่ละตัวมีหน้าที่แคบ ๆ

Core Agent — เก็บ metric ระดับ host/system (CPU, memory, disk, network) และรัน checks กับ integration ที่ตั้งค่าไว้ นี่คือ process ที่อ่าน config ใน conf.d/
Trace Agent — ฟัง span ที่ tracing library ของแอปส่งมาในเครื่อง batch แล้วส่งต่อไปที่ APM intake ของ Datadog แอปของคุณไม่เคยคุยกับ Datadog โดยตรงสำหรับ trace — แต่คุยกับ Trace Agent
Process Agent — เก็บข้อมูลระดับ process แบบ live (อะไรกำลังรันอยู่, ใช้ resource เท่าไหร่) ที่ขับเคลื่อน view Live Processes
Security Agent (optional) — รัน Cloud Security Posture Management กับงาน threat-detection เมื่อเปิด Datadog Cloud Security

process เหล่านี้ถูกติดตั้งเป็นชุดเดียวแต่ข้างใต้เป็น OS process แยกกัน นี่คือเหตุผลที่คำสั่ง status (ด้านล่าง) รายงานแต่ละตัวแยกกัน

flowchart TB
    subgraph Host["Host / Pod"]
      Core["Core Agent
(metrics + checks)"]
      Trace["Trace Agent
(receives spans)"]
      Proc["Process Agent
(live processes)"]
      Sec["Security Agent
(optional)"]
    end
    App["Instrumented app"] -->|spans| Trace
    Core -->|checks read| ConfD["conf.d/*.d/conf.yaml"]
    Core --> Backend["Datadog Backend"]
    Trace --> Backend
    Proc --> Backend
    Sec --> Backend

Agent component processes

Checks กับ integration

check คือโค้ดชิ้นเล็ก ๆ (Python ที่มากับ Agent) ที่รู้วิธีคุยกับ service หนึ่งตัวโดยเฉพาะ — Postgres, Redis, NGINX, Kafka และอีกหลายร้อยตัว — แล้วแปลง state ข้างในของตัวเองเป็น metric ของ Datadog แต่ละ check ถูกตั้งค่าผ่านไฟล์ YAML ใต้ directory conf.d/ ของ Agent ในโฟลเดอร์ที่ตั้งชื่อตาม integration นั้น

init_config:

instances:
  - host: localhost
    port: 5432
    username: datadog
    password: "<PASSWORD>"
    tags:
      - "env:prod"
      - "service:orders-db"

init_config:

instances:
  - host: localhost
    port: 6379
    tags:
      - "env:prod"
      - "service:orders-cache"

พอไฟล์นั้นมีอยู่แล้ว Agent restart (หรือ pick up การเปลี่ยนแปลง) จะเริ่มรัน check postgres หรือ redis ตามตารางเวลา และส่ง metric อย่าง postgresql.connections หรือ redis.mem.used — ที่ถูก tag ตามที่ใส่ไว้ใต้ tags บวกกับ host tag ของ Agent เอง

Autodiscovery

ไฟล์ conf.d/ แบบ static ใช้ได้ดีกับ host ที่รัน service เดิมตลอดไป แต่พังทันทีที่ service เป็น container ที่ start, stop และ reschedule ตลอดเวลา — คุณเขียน config file มือให้ Postgres pod ที่อาจจะไม่มีอยู่แล้วในอีกห้านาทีไม่ได้ Autodiscovery แก้ปัญหานี้ — Agent เฝ้าดู container/pod แล้วจับคู่กับ config template ที่แปะเป็น annotation สร้าง (และรื้อ) check config ให้เองอัตโนมัติตามที่ container ที่ match เข้ามาหรือหายไป

นี่คือสิ่งที่ annotation block แบบนี้กำลังทำอยู่บน Kubernetes Service ที่อยู่หน้า NGINX

apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    ad.datadoghq.com/nginx.checks: |
      {
        "nginx": {
          "init_config": {},
          "instances": [
            {
              "nginx_status_url": "http://%%host%%:81/nginx_status/"
            }
          ]
        }
      }
spec:
  selector:
    app: nginx
  ports:
    - port: 81

Agent อ่าน annotation ad.datadoghq.com/<container-name>.checks แทนที่ template variable อย่าง %%host%% ด้วย pod IP จริงตอน runtime แล้วเริ่มรัน check nginx กับ pod ตัวไหนก็ตามที่ match อยู่ตอนนั้น — ไม่ต้องแก้ conf.d/ มือ ไม่ต้อง restart ทีละ pod นี่คือกลไกเดียวกับไฟล์ YAML แบบ static ด้านบน เพียงแต่ถูก generate แบบ dynamic แทนที่จะเขียนมือ

วิธีติดตั้งกับการ troubleshoot

Agent มีให้ติดตั้งหลายทาง เลือกตามที่ที่ต้องรัน

# Host package install (Debian/Ubuntu, one-line installer)
DD_API_KEY=<API_KEY> DD_SITE="datadoghq.com" bash -c \
  "$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)"

# Docker Agent container
docker run -d --name datadog-agent \
  -e DD_API_KEY=<API_KEY> -e DD_SITE="datadoghq.com" \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  gcr.io/datadoghq/agent:7

# Kubernetes, via the official Helm chart
helm repo add datadog https://helm.datadoghq.com
helm install datadog-agent datadog/datadog \
  --set datadog.apiKey=<API_KEY> --set datadog.site="datadoghq.com"

พอ Agent รันอยู่แล้ว มีสองคำสั่งที่ตอบคำถาม “Agent ทำงานอยู่หรือเปล่า” ได้เกือบทุกครั้ง

# Full status: which checks ran, when, any errors, each component process's health
sudo datadog-agent status

# Run one check once, in the foreground, with verbose output — the fastest
# way to see exactly what a specific integration is doing (or failing to do)
sudo datadog-agent check postgres

status คือคำสั่งแรกที่ควรรันเมื่อ metric ดูเหมือนหายไป — เพราะโชว์เวลารันล่าสุดของทุก check และ error ในการเก็บข้อมูล check <name> คือเครื่องมือสำหรับวน iterate config ของ integration ตัวเดียวโดยไม่ต้องรอรอบถัดไป