Production Rollout Checklist

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

การ go-live ด้วย Datadog คือ checklist ไม่ใช่สวิตช์ตัวเดียว และทุกข้อใน checklist ย้อนกลับไปหาการตัดสินใจที่คอร์สนี้สอนไว้แล้ว — ตั้งแต่ tagging ใน Foundations, Infrastructure & Metrics, Log Management, APM & Distributed Tracing, Monitors/Alerting/SLOs ไปจนถึง Correlating Signals

🐶 Proof: อะไรที่รันจริงและอะไรที่ไม่ได้รันในบทนี้

รันในเครื่อง ไม่มีอะไรถูกส่งไป Datadog (key ปลอม, DD_DD_URL=http://127.0.0.1:1, Mac): Datadog Agent 7.83.3 (agent version จาก datadog/agent:7) อ่าน environment variable ของ container ผ่าน Docker socket แบบ read-only แล้วพิมพ์ด้วย agent tagger-list; helm template ของ chart datadog/datadog 3.250.3; JSON schema ของ DatadogAgent ใน repo DataDog/datadog-operator ที่ tag v1.30.0 (chart Operator datadog/datadog-operator 2.27.0 มี app version 1.30.0) ใช้เป็น JSON Schema validator; JSON schema deployment-apps-v1 ของ Kubernetes upstream (v1.33 standalone-strict) สำหรับ fence ของ Deployment ที่ไม่ได้รัน มีแค่ docs: Kubernetes cluster จริง (โหมด --k8s ของ harness ต้องมี cluster kind-verify-k8s ซึ่ง session นี้ไม่มี), Bits AI และทุกอย่างที่ต้องมี Datadog org

Tagging และ ownership ก่อน เพราะทุกอย่างพึ่งมัน

• Unified service tagging สม่ำเสมอทุกที่ env, service และ version ถูกใช้แบบเดียวกันทั้งใน Agent configuration, การตั้ง APM tracer และทุก logs: source — นี่คือ tagging model จากโมดูล Foundations ที่ทำให้ log line, trace และ metric ย้อนกลับไปหา deployable unit เดียวกันได้ แก้ทีหลัง go-live แปลว่า dashboard และ monitor ทุกตัวที่สร้างระหว่างนั้นพลาด telemetry ของคุณบางส่วนแบบเงียบ ๆ
• มี Service Catalog entry และถูกต้อง ทุก service ที่จะ page คนต้องมี entry พร้อม ownership จริง: ทีมไหน, escalation path ไหน, runbook อยู่ที่ไหน นี่คือสิ่งที่โมดูล Correlating Signals ตั้งไว้ และคือความต่างระหว่าง alert ที่ถึง on-call กับ alert ที่ไปถึง mailing list ที่ไม่มีใครดูแล

Unified tagging checklist ทีละข้อ

จาก https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging/

1. reserved tag สามตัวคือ env, service และ version map กับ DD_ENV, DD_SERVICE และ DD_VERSION
2. “In containerized environments, env, service, and version are set through the service’s environment variables or labels (for example, Kubernetes deployment and pod labels, Docker container labels). The Datadog Agent detects this tagging configuration and applies it to the data it collects from containers.”
3. บน Kubernetes “To get the full range of unified service tagging in Kubernetes, add the following labels to both the parent workload and the pod template”: tags.datadoghq.com/env, tags.datadoghq.com/service, tags.datadoghq.com/version ส่วนแบบ pod-level metrics บอกให้เพิ่ม label “to the pod spec, as well as optionally to the parent workload”
4. DD_ENV/DD_SERVICE/DD_VERSION บน application “only required if you are using APM in your applications”
5. กับ Docker “make sure the Agent can access your container’s Docker socket”
6. “On ECS Fargate, you must add these tags to your application container, not the Datadog Agent container.”
7. version “is expected to change with each new application deployment”
8. global env tag บน Agent ร่วมกับ env ที่ ต่างกัน บน pod หมายความว่า “that pod’s data contains both env tags” (หน้าเดียวกัน) เลือกเจ้าของ env เพียงที่เดียว

ข้อ 2 คือข้อที่พิสูจน์ได้โดยไม่ต้องมี cluster ผมรัน Agent โดย mount Docker socket แบบ read-only (-e DD_ENV=prod -e DD_TAGS=team:checkout บนตัว Agent เอง) กับ container ทิ้งสองตัว ตัวหนึ่งมีครบสามตัวแปร อีกตัวสะกด DD_SERVICE ผิดเป็น DD_SERVCE

$ docker exec dd-production agent status | grep -A3 "host tags"
  host tags:
    env:prod
    team:checkout

$ docker exec dd-production agent tagger-list     # container_id shortened
Tags: [container_id:<id> container_name:dd-production-good docker_image:busybox env:prod image_name:busybox service:checkout-api short_image:busybox version:1.4.2]
Tags: [container_id:<id> container_name:dd-production-partial docker_image:busybox env:prod image_name:busybox short_image:busybox]

ได้สองข้อเท็จจริง ข้อแรก Agent แปลง DD_ENV/DD_SERVICE/DD_VERSION ภายใน container เป็น tag env:/service:/version: โดยไม่มี tracer เกี่ยวข้องเลย ข้อสอง DD_SERVCE ที่สะกดผิดไม่ทำให้เกิด error, warning หรือ tag service: เลย container แค่โผล่มาแบบ tag ไม่ครบ DD_ENV ของตัว Agent เองกลายเป็น host-level tag แต่ไม่มี DD_SERVICE ระดับ Agent ที่เป็น host tag ใน agent status — service และ version เป็นของ workload ไม่ใช่ของ host

บน Kubernetes ข้อมูลเดียวกันมาทาง pod label และ env ของ container Deployment ที่ตรงกับ “full configuration” ของ docs (validate ผ่านกับ Kubernetes schema upstream)

k8s/checkout-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
  labels:
    tags.datadoghq.com/env: "prod"
    tags.datadoghq.com/service: "checkout-api"
    tags.datadoghq.com/version: "1.4.2"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: checkout-api
  template:
    metadata:
      labels:
        app: checkout-api
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "checkout-api"
        tags.datadoghq.com/version: "1.4.2"
    spec:
      containers:
        - name: checkout-api
          image: registry.example.com/checkout-api:1.4.2
          env:
            - name: DD_ENV
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['tags.datadoghq.com/env']
            - name: DD_SERVICE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['tags.datadoghq.com/service']
            - name: DD_VERSION
              valueFrom:
                fieldRef:
                  fieldPath: metadata.labels['tags.datadoghq.com/version']

env var แบบ fieldRef อ่านจาก label ของ pod เอง จึงแก้ค่าได้ที่เดียว นี่คือ pattern ของ docs เอง การที่ Agent อ่าน label เหล่านั้นในระดับ pod ต้องมี cluster จริงและไม่ได้รันที่นี่

ติดตั้งบน Kubernetes: Datadog Operator หรือ Helm

หน้า install (https://docs.datadoghq.com/containers/kubernetes/installation/) ลิสต์สามวิธีและติดเครื่องหมายไว้หนึ่งอัน: “Datadog Operator (recommended): a Kubernetes operator that you can use to deploy the Datadog Agent on Kubernetes and OpenShift. It reports deployment status, health, and errors in its Custom Resource status, and it limits the risk of misconfiguration thanks to higher-level configuration options.” อีกสองวิธีคือ Helm และติดตั้ง DaemonSet เอง โปรดสังเกตว่าคำสั่งติดตั้ง Operator เองก็ใช้ Helm (helm install datadog-operator datadog/datadog-operator) — ทางเลือกคือจัดการ Agent ด้วย resource DatadogAgent หรือด้วย values ของ chart datadog/datadog ไม่ใช่ “Helm กับไม่ใช้ Helm” docs ไม่มีตารางเทียบ feature ระหว่างสองแบบ และบทนี้ไม่แต่งขึ้นเอง

เจตนาเดียวกัน ทำสองแบบ แบบ Operator (DatadogAgent เป็น k8s fence ที่ถูกเก็บ)

k8s/datadog-agent.yaml

apiVersion: datadoghq.com/v2alpha1
kind: DatadogAgent
metadata:
  name: datadog
spec:
  global:
    clusterName: checkout-prod
    site: datadoghq.com
    credentials:
      apiSecret:
        secretName: datadog-secret
        keyName: api-key
    tags:
      - "env:prod"
    podLabelsAsTags:
      app.kubernetes.io/team: team
  features:
    apm:
      enabled: true
    logCollection:
      enabled: true
      containerCollectAll: true

แบบ Helm (values ของ chart datadog/datadog ไม่ใช่ Kubernetes object จึงตั้งใจไม่ทำเป็น fence k8s/ ที่ถูกเก็บ)

# helm values for datadog/datadog (not collected by the k8s harness)
datadog:
  apiKeyExistingSecret: datadog-secret
  clusterName: checkout-prod
  site: datadoghq.com
  tags:
    - "env:prod"
  podLabelsAsTags:
    app.kubernetes.io/team: team
  apm:
    portEnabled: true
  logs:
    enabled: true
    containerCollectAll: true

helm template datadog datadog/datadog --version 3.250.3 -f values.yaml exit 0 และ DaemonSet ของ Agent ที่ render ออกมามี DD_CLUSTER_NAME=checkout-prod, DD_TAGS=["env:prod"], DD_KUBERNETES_POD_LABELS_AS_TAGS={"app.kubernetes.io/team":"team"}, DD_APM_ENABLED=true และ DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true fence DatadogAgent validate ผ่านกับ schema v2alpha1 จาก repo Operator ที่ v1.30.0 (schema ตั้ง additionalProperties: false จึงปฏิเสธ key ที่ไม่รู้จัก)

ทีนี้ความต่างที่สำคัญตอน review สะกด key ผิดสองตัวในแต่ละแบบ (clusterName เป็น cluster_name, containerCollectAll เป็น collectAll)

# DatadogAgent, validated against the v2alpha1 schema
ERR spec/features/logCollection - Additional properties are not allowed ('collectAll' was unexpected)
ERR spec/global - Additional properties are not allowed ('cluster_name' was unexpected)

# Helm values, helm template datadog/datadog 3.250.3
exit code 0
DD_CLUSTER_NAME occurrences in rendered output: 0
DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL: "false"

ฝั่ง Operator ปฏิเสธทั้งสอง typo ฝั่ง Helm รับทั้งสอง ทิ้งชื่อ cluster ไปเลย และปล่อยให้ container log collection อยู่ที่ค่า default ของ chart คือ "false" ขณะที่ logs.enabled ยังเป็น true — Agent ที่ดูเหมือนกำลังเก็บ log แต่ไม่เก็บอะไรเลย นี่เป็นคุณสมบัติของสอง artifact นี้ที่เวอร์ชันเหล่านี้ (values.schema.json ของ chart ไม่ปฏิเสธ key ที่ไม่รู้จัก) ไม่ใช่ข้อสรุปทั่วไป แต่เป็น bug ประเภทที่ values file ที่ AI เขียนมักมี

สรุป trade-off: Operator ให้ resource ที่มี type และรายงานสถานะ และปฏิเสธ field ที่ไม่รู้จักตอน admission; Helm มีฐานผู้ใช้กว้างกว่าและ workflow แบบ plain values ที่ GitOps repo ส่วนใหญ่ใช้อยู่แล้ว ไม่ว่าเลือกแบบไหน ให้รัน manifest ที่ render หรือ apply ผ่าน schema check ใน CI docs ยังระบุว่าตั้งแต่ Operator chart version 2.19.0 registryMigrationMode ของ Agent Helm chart ใช้กับ Agent image ที่ Operator จัดการด้วย ดังนั้นการตั้งค่า image registry ไหลข้ามกันได้

ต้นทุน log และ metric: ตัดสินใจอย่างตั้งใจ ไม่ใช่ปล่อยตาม default

• ขนาด log index กำหนดอย่างตั้งใจ retention และ daily quota ต่อ index สะท้อนคุณค่าจริงของ log stream นั้น ไม่ใช่ “index ทุกอย่างแล้วค่อยหาทางแก้” — ประเด็นทั้งหมดของโมดูล Log Management
• มี exclusion filter สำหรับ log ปริมาณมากคุณค่าต่ำ ก่อนที่ volume จะโตใน production ไม่ใช่มาเสริมทีหลังบิลแรกที่น่าตกใจ
• ตั้ง log-based metric สำหรับทุกอย่างที่จะ exclude ถ้ายังต้องการ count หรือ trend จาก log stream ที่กำลังจะกรองทิ้ง ให้ตั้ง log-based metric ก่อน — การ exclude log ดิบต้องไม่ทำให้คุณมองไม่เห็น trend ที่สนใจโดยไม่รู้ตัว
• ตรวจ tag ของ custom metric โดยคำนึงถึง cardinality tag cardinality สูงอย่าง pod_name ยังส่งได้; Metrics without Limits คุมว่าอันไหนถูก index และ query ได้จริง และการเลือกนั้นควรตั้งใจก่อน go-live ไม่ใช่ไปเจอจาก cost spike

APM sampling และ retention: ตรวจเป็นสองชั้นแยกกัน

• ตั้ง ingestion sampling อย่างตั้งใจ ชั้นนี้ตัดสินว่า trace volume ทั้งหมดเข้าถึง Datadog เท่าไร — ควรเป็นอัตราที่ตั้งใจ ไม่ใช่ค่า default ที่บังเอิญเป็น
• ตรวจ retention filter แยกจาก sampling ยืนยันว่า trace ไหนถูกเก็บระยะยาวโดยไม่ขึ้นกับ sampling เช่น ทุกอันที่มี error หรือทุกอันที่ latency เกิน threshold และไม่มีใครในทีมสับสนระหว่าง “เรา sample น้อยลง” กับ “เราเก็บน้อยลง” สองอย่างเป็นคนละ knob จากโมดูล APM & Distributed Tracing และ go-live คือเวลาเช็กทั้งสองตัว ไม่ใช่แค่ตัวเดียว

Alerting ผูกกับสิ่งที่สำคัญจริง

• นิยาม SLO ให้ service ไม่กี่ตัวที่ธุรกิจพึ่งพาจริง — ไม่ใช่ metric ประดับที่ copy ไปทุก service เพราะเพิ่มง่าย
• ผูก burn-rate alert กับ SLO เหล่านั้น ทีมจะได้รับแจ้งตอนที่ยังมี error budget เหลือให้ตอบสนอง ไม่ใช่หลังหมดไปแล้ว นี่คือกลไกแกนของโมดูล Monitors, Alerting, and SLOs และทำงานได้ก็ต่อเมื่อเชื่อมจริงก่อน go-live
• เช็ก notification target ของทุก monitor กับ owner ใน Service Catalog จากขั้น tagging ข้างบน เพื่อให้ page ถึงทีมที่ลงมือได้จริง

จัดการทั้งหมดเป็น code และ review เหมือน code

• Monitor, dashboard และ SLO เป็น Terraform resource — datadog_monitor, datadog_dashboard, datadog_service_level_objective — แทนการคลิกทำเอง ตามที่ครอบคลุมไว้ก่อนหน้าในโมดูลนี้ ให้ validate ทุก HCL block ด้วย terraform validate บน provider ที่ pin ไว้ใน CI
• terraform plan รันโดยเปิด query validation เป็นส่วนของ review pull request ปกติ ก่อนที่การเปลี่ยน monitor หรือ dashboard ใด ๆ จะถึง production — มาตรฐาน review เดียวกับ infrastructure change อื่น
• ตรวจ RBAC — ดูบทก่อนหน้า: logs_modify_indexes เป็น global, แจก Logs Read Index Data และ Logs Write Exclusion Filters ต่อได้ และ managed Standard role ถือเป็น default ดังนั้น “เฉพาะทีม platform” ต้องทำให้เป็นจริงด้วย custom role
• มี cost alert monitor ของ Cloud Cost Management สำหรับ service หรือ account ที่ rollout นี้กระทบ เพื่อให้ cost spike ได้รับการเตือนแบบเดียวกับ latency spike ไม่ใช่เซอร์ไพรส์ปลายเดือน

Bits AI อยู่ตรงไหน (quote จาก docs ไม่ได้รันอะไร)

ทุกอย่างใน section นี้มาจาก docs ไม่ได้ใช้ feature ของ Bits AI จริง และราคากับสถานะการ rollout ของ Datadog เปลี่ยนได้ ควรอ่านหน้าที่ลิงก์ไว้ตอน go-live

• คืออะไร: “Bits AI is your agentic teammate in Datadog, built to automate development, security, and operational workflows. You can chat and collaborate with Bits in real time, or delegate full tasks—like alert investigations, code fixes, or security triage—and let it take care of the details.” (https://docs.datadoghq.com/bits_ai/)
• docs ลิสต์เจ็ด feature ที่นั่น: Bits Investigation, Bits Code, Bits Security Analyst, Bits Chat, Bits Data Analysis, Bits Detection และ Bits Remediation หน้าของ Bits Investigation อยู่ที่ path เก่า bits_ai/bits_ai_sre และลิงก์ blog ยังเรียก “Bits AI SRE” — กับดักด้านชื่อเวลาอ่านโพสต์เก่า
• Bits Investigation: “an autonomous AI agent that investigates production issues end to end. It iteratively forms hypotheses, gathers relevant telemetry, and uses data-based reasoning to help on-call engineers pinpoint root causes.” (https://docs.datadoghq.com/bits_ai/bits_ai_sre/)
• ความพร้อมใช้งาน: docs แสดงคำเตือนว่า “This product is not supported for your selected Datadog site” สำหรับ app.ddog-gov.com และ us2.ddog-gov.com
• ค่าใช้จ่าย: “Learn about Bits AI pricing on AI Credits” (https://docs.datadoghq.com/account_management/billing/ai_credits/) ไม่ quote ราคาที่นี่
• การเชื่อมต่อ: หน้า integrations ระบุว่าเชื่อมกับ GitHub, Grafana, Dynatrace, Splunk, Sentry และ ServiceNow, การตั้งค่า GitHub รวมถึง “Tag your APM telemetry with Git information” และสำหรับ monitor alert ถ้า monitor มี notification @slack, @case หรือ @oncall อยู่แล้ว “Bits automatically posts its findings to those destinations” (https://docs.datadoghq.com/bits_ai/bits_investigation/configure/) การรองรับ Microsoft Teams ระบุว่าเป็น Preview ที่นั่น

ความหมายต่อ checklist: Bits AI อ่าน telemetry ที่คุณส่งอยู่แล้ว จึงอยู่ปลายน้ำของทุกข้อข้างบน อย่าเอามันไว้บน critical path ของ go-live; ตัดสินใจรายฟีเจอร์ว่าค่า AI Credits และสิทธิ์เข้าถึง code กับ telemetry เข้ากับ data policy ของคุณหรือไม่ และทำหลังจาก tagging, ownership และ monitor routing ถูกต้องแล้ว เพราะสิ่งเหล่านั้นคือวัตถุดิบที่ investigation ใช้

Go-Live Checklist
1. Unified tagging (env/service/version) verified across Agent, APM, logs; pod template labels present
2. Service Catalog ownership accurate for every paging service
3. Kubernetes install method chosen (Operator or Helm) and the manifest/values schema-checked in CI
4. Log indexes and exclusion filters sized deliberately; log-based metrics set up first
5. Custom metric tag cardinality reviewed via Metrics without Limits
6. APM ingestion sampling and retention filters reviewed as two separate layers
7. SLOs and burn-rate alerts wired to business-critical services only
8. Monitor notification targets checked against Service Catalog owners
9. Monitors/dashboards/SLOs as Terraform code, reviewed via PR with query validation on
10. RBAC checked: logs_modify_indexes and exclusion/archive rights on custom roles, read access broad
11. Cloud Cost Management cost alert in place for the affected services/accounts
12. Optional: Bits AI features evaluated against cost (AI Credits) and data policy

flowchart LR
  A[Tagging and ownership] --> K["Kubernetes install: Operator or Helm"]
  K --> B[Log and metric cost decisions]
  B --> C[APM sampling and retention review]
  C --> D[SLOs and burn-rate alerting]
  D --> E[Infrastructure as code review]
  E --> F[Go-live]
  F -.optional.-> I["Bits AI evaluation"]
  A -.Service Catalog owner.-> D
  B -.cost alert monitor.-> E

Production rollout checklist ทีละเฟส

🐶 สรุปหนึ่งบรรทัด

production rollout checklist ของ Datadog ไม่ใช่สวิตช์ตัวเดียว — เริ่มที่ unified tagging (label ต้องอยู่ที่ pod template, ตัวแปรที่สะกดผิดพังแบบเงียบ) และ Service Catalog ownership, ตรวจ schema ของการติดตั้งผ่าน Operator หรือ Helm, ตัดสินใจ cost ของ log/metric อย่างตั้งใจ, ตรวจ APM sampling กับ retention filter เป็นสองชั้นแยกกัน, ผูก SLO และ burn-rate alert กับ service ที่สำคัญต่อธุรกิจ, จัดการทั้งหมดเป็น Terraform code ที่ review แล้วพร้อมตรวจ RBAC และ cost alerting ก่อน go-live และมอง Bits AI เป็นชั้นเสริมด้านบน

Reading AI-generated code

🐛 หา bug ในโค้ดนี้

# AI comment: "Unified service tagging for checkout-api"
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-api
labels:
  tags.datadoghq.com/env: "prod"
  tags.datadoghq.com/service: "checkout-api"
  tags.datadoghq.com/version: "1.4.2"
spec:
replicas: 2
selector:
  matchLabels:
    app: checkout-api
template:
  metadata:
    labels:
      app: checkout-api
  spec:
    containers:
      - name: checkout-api
        image: registry.example.com/checkout-api:1.4.2

เฉลย

นี่คือ Deployment ที่ valid — ผ่าน Kubernetes schema — และดูเหมือน tag แล้ว แต่ label อยู่แค่ที่ metadata ของตัว Deployment เอง docs ของ Datadog ขอให้ใส่ “on both the parent workload and the pod template” สำหรับ full configuration และสำหรับ pod-level path label ต้องอยู่ที่ pod spec ส่วน parent workload เป็น optional label ใน metadata.labels ของ Deployment ไม่ถูกคัดลอกไปที่ pod ดังนั้น pod ที่ Agent เห็นจริงจึงไม่มี label tags.datadoghq.com/* (เป็นพฤติกรรมมาตรฐานของ Kubernetes ไม่ใช่สิ่งที่บทนี้รันกับ cluster) วิธีแก้คือ manifest ที่แสดงไว้ก่อนหน้าในบทนี้: label สามตัวเดียวกันใต้ spec.template.metadata.labels พร้อม DD_ENV/DD_SERVICE/DD_VERSION จาก fieldRef ถ้า app ใช้ APM

k8s/checkout-deployment-fixed.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout-api
  labels:
    tags.datadoghq.com/env: "prod"
    tags.datadoghq.com/service: "checkout-api"
    tags.datadoghq.com/version: "1.4.2"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: checkout-api
  template:
    metadata:
      labels:
        app: checkout-api
        tags.datadoghq.com/env: "prod"
        tags.datadoghq.com/service: "checkout-api"
        tags.datadoghq.com/version: "1.4.2"
    spec:
      containers:
        - name: checkout-api
          image: registry.example.com/checkout-api:1.4.2

Mental Model

go-live checklist คือ dependency graph ไม่ใช่ to-do list Tag คือ join key ของ log, trace และ metric จึงมาก่อน; ownership คือ join key ของ alert กับคน; วิธีติดตั้งกำหนดว่า Agent ได้ tag เหล่านั้นอย่างไร; cost และ sampling กำหนดว่าคุณเก็บอะไร; SLO และ alert กำหนดว่าใครถูกปลุก; Terraform และ RBAC กำหนดว่าใครเปลี่ยนอะไรได้ Bits AI อยู่ด้านบน: มันบริโภคสิ่งที่ชั้นล่างผลิต จึงรับทั้งคุณภาพและช่องโหว่ของชั้นเหล่านั้นมาด้วย

Trade-offs

• Operator เทียบกับ Helm — docs แนะนำ Operator และในการตรวจข้างบนมันปฏิเสธ field ที่ไม่รู้จัก; Helm เป็น workflow ที่พบมากกว่า และที่ chart 3.250.3 ละเลย key ที่ไม่รู้จักแบบเงียบ การย้ายมีต้นทุนของ install path จึงควรเลือกก่อน go-live ไม่ใช่หลัง
• Label ทั้ง workload และ pod template เทียบกับ pod template อย่างเดียว — ทั้งสองคือ “full configuration” ของ docs; pod อย่างเดียวคือขั้นต่ำของ docs สำหรับ pod-level metrics label เพิ่มอีกไม่กี่บรรทัดและทำให้ query Deployment ด้วย tag เดียวกันได้
• เริ่มใช้ Bits AI เร็วเทียบกับช้า — เร็วกว่าให้ช่วย on-call เร็วกว่า แต่เพิ่มบรรทัดต้นทุน AI Credits และให้สิทธิ์เข้าถึง code กับ telemetry (ตาม docs ของ integration) ช้ากว่าให้แก้ tagging และ routing ก่อน docs ไม่ quote ราคา ฝั่งต้นทุนจึงไม่ทราบจนกว่าจะดู account
• Schema-check manifest ใน CI เทียบกับเชื่อคำสั่งติดตั้ง — schema check เสียหนึ่งขั้นใน pipeline และจับ silent-typo class ที่ทั้งการรัน Helm และ container DD_SERVCE ที่สะกดผิดแสดงให้เห็น

Common Misconceptions

• “ถ้า Deployment มี label แล้ว pod ก็ถูก tag” docs ต้องการที่ pod template; label ของ Deployment ไม่ใช่ pod label
• “Helm จะเตือนถ้าพิมพ์ key ใน values ผิด” ที่ chart 3.250.3 helm template exit 0 และทิ้ง key ที่พิมพ์ผิด; schema ของ Operator ปฏิเสธ
• “Operator มาแทน Helm” คำสั่งติดตั้ง Operator ตาม docs เองรัน helm install datadog-operator datadog/datadog-operator; มันแทน values ของ chart datadog/datadog ด้วย resource DatadogAgent
• “ตั้ง DD_ENV บน Agent แล้ว tag ทุกอย่างถูกต้อง” มันกลายเป็น host-level tag (agent status แสดง env:prod) และ docs เตือนว่า env ที่ต่างกันบน pod ทำให้ข้อมูลของ pod นั้นมี tag ทั้งสองตัว
• “Bits AI SRE เป็น product แยกจาก Bits Investigation” หน้า docs ชื่อ Bits Investigation อยู่ที่ path bits_ai_sre; โพสต์เก่าใช้ชื่อก่อนหน้า

ทำไมต้องตรวจ ingestion sampling กับ retention filter แยกกันก่อน go-live

เป็นการตั้งค่าเดียวกันสองชื่อ ตรวจอันเดียวก็ครอบคลุมอีกอัน เป็นสองชั้นแยกกัน — sampling คุมว่า trace volume เข้ามาเท่าไร retention filter คุมว่าเก็บอะไรระยะยาวโดยไม่ขึ้นกับ sampling retention filter สำคัญกับ log เท่านั้น ไม่ใช่ trace ingestion sampling ถูก deprecate แล้วและตั้งค่าไม่ได้

ก่อน exclude log stream ปริมาณมากคุณค่าต่ำ ควรตั้งอะไรก่อน

ไม่ต้องทำอะไร — exclusion filter ไม่กระทบการมองเห็น trend log-based metric ถ้ายังต้องการ count หรือ trend จาก stream นั้น Service Catalog entry ใหม่ cost alert monitor เฉพาะ log stream นั้น

Deployment มี label tags.datadoghq.com/env|service|version เฉพาะใต้ metadata.labels ของตัวมันเอง ตาม docs ของ unified service tagging อะไรขาดไป

ไม่ขาดอะไร — label ของ Deployment propagate ไปที่ pod label ชุดเดียวกันบน pod template ซึ่ง docs ต้องการสำหรับ full configuration (ทั้ง parent workload และ pod template) ตัวแปร DD_HOSTNAME Service Catalog entry

container เริ่มด้วย DD_ENV=prod และ DD_SERVCE=checkout-api ที่สะกดผิด agent tagger-list แสดงอะไรให้ container นั้นในบทนี้

error ที่ระบุชื่อตัวแปรที่ไม่รู้จัก env:prod แต่ไม่มี tag service: — ไม่มี error หรือ warning service:checkout-api เพราะ Agent แก้ typo ให้ ไม่มี tag เลย

คุณพิมพ์ containerCollectAll เป็น collectAll ใน manifest DatadogAgent และแยกต่างหากใน Helm values สำหรับ chart 3.250.3 การตรวจในบทนี้แสดงอะไร

ทั้งสองพังเสียงดัง schema check ของ DatadogAgent ปฏิเสธ ("Additional properties are not allowed"); helm template exit 0 และ DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL ค้างที่ "false" ทั้งสองสำเร็จแบบเงียบ Helm ปฏิเสธ Operator ยอมรับ

docs ของ Bits AI พูดอะไรเรื่องราคา และบทนี้จัดการอย่างไร

ระบุราคารายเดือนคงที่และบทนี้ quote ชี้ไปหน้า AI Credits; บทนี้ไม่ quote ตัวเลขและให้เช็กที่ account ของคุณ Bits AI ฟรีสำหรับทุก site ราคามีเฉพาะ gov site

Submit

Mark as complete