อภิธานศัพท์

คำศัพท์ของ Datadog ครอบคลุมหลายชั้นพร้อมกัน: Agent ที่เก็บข้อมูล (core Agent, Trace Agent, check, DogStatsD, aggregator และ forwarder), โมเดลการ tag (env, service, version) ที่ทำให้ metric, log และ trace join กันได้, APM ที่มี sampling สองชั้นซ้อนกัน, pipeline ของ log ที่แยก ingestion ออกจากการ index, monitor และ SLO ที่แปลง telemetry เป็นการแจ้งเตือน และชั้น Terraform กับ API client ที่ทำให้ทั้งหมดเป็นโค้ดที่รีวิวได้ เมื่อบทเรียนใช้คำที่ไม่แน่ใจ หรือสงสัยว่าคำตอบของ AI ใช้ชื่อที่ล้าสมัย (CSPM, LLM Observability, log_injection) ให้มาดูที่นี่ ทุกนิยามด้านล่างอ้างอิงจากบทเรียนที่พิสูจน์กับ Agent, tracer หรือ model จริง หรือยกจาก URL ของเอกสารที่บทเรียนอ้าง ไม่มีส่วนไหนมาจากความจำหรือจาก account Datadog จริง

A

Term	ความหมาย	บทเรียน
Agent	โปรแกรมเล็ก ๆ ที่รันบน host, container หรือเป็น DaemonSet บน Kubernetes เก็บข้อมูลในเครื่องแล้วส่งไป backend ของ Datadog ผ่าน HTTPS โดยไม่ได้เรนเดอร์ dashboard ประเมิน monitor หรือเก็บประวัติเอง จริง ๆ เป็นกลุ่ม process ที่ทำงานร่วมกัน (core Agent, Trace Agent, Process Agent, Security Agent ที่เป็นทางเลือก และ Cluster Agent บน Kubernetes) ไม่ใช่ binary เดียว	Datadog คืออะไร, Datadog Agent กับ Integration, สถาปัตยกรรมของ Agent
agent analyze-logs	รัน config logs: กับ Agent ที่ทำงานอยู่แล้วพิมพ์สิ่งที่จะถูกส่งออกไป ใช้ตรวจ rule exclude_at_match, mask_sequences และ multi_line ก่อน deploy ข้อควรระวัง: ค่าเริ่มต้น -t 1s อาจทำให้ event multi-line ตัวสุดท้ายหาย เพราะกลุ่มจะถูกส่งออกเมื่อเจอบรรทัดเริ่มต้นถัดไปหรือ timeout เท่านั้น	Processor ใน Log Pipeline
agent configcheck / agent status	คำสั่ง CLI ของ Agent สองตัวที่คอร์สใช้เป็นหลักฐานจริง configcheck แสดงว่า config ของ check ตัวไหนถูกโหลดจริง (พร้อม error จริงเมื่อเขียนผิด เช่น instances: เป็น mapping) ส่วน status คือ dump ของ pipeline ทีละ section (Collector, Aggregator, DogStatsD, Forwarder, Logs Agent, OTLP) ข้อควรระวัง: ไฟล์ config ที่อยู่บนดิสก์ไม่ได้พิสูจน์อะไร จนกว่า configcheck จะแสดงมันออกมา	Datadog Agent กับ Integration, สถาปัตยกรรมของ Agent, AI bug catalog
agent dogstatsd-stats	คำสั่งของ Agent ที่แสดง context และจำนวนของ DogStatsD ที่เห็น ต้องตั้ง DD_DOGSTATSD_METRICS_STATS_ENABLE=true บทเรียนใช้พิสูจน์ว่า datagram แบบ h กับ d ถูกรับเหมือนกัน (ตัวละ 20) และแต่ละคู่ชื่อบวก tag ที่ไม่ซ้ำคือหนึ่ง context	DogStatsD กับ Aggregation, Verification tools
Agent Observability	ชื่อผลิตภัณฑ์ปัจจุบันของสิ่งที่เอกสารเก่า (และ output ของ AI รุ่นเก่า) เรียกว่า LLM Observability คือการ monitor, troubleshoot และประเมินแอปที่ขับเคลื่อนด้วย LLM เป็นผลิตภัณฑ์เดียวกันที่เปลี่ยนชื่อ ไม่ใช่ตัวใหม่	Datadog คืออะไร
agent tagger-list	คำสั่งที่ dump ทุก tag ที่ tagger ของ Agent resolve ได้ต่อ entity ใช้พิสูจน์ว่า container ได้ env / service / version จริง	Unified Service Tagging ในทางปฏิบัติ, Production Rollout Checklist
aggregator	ขั้นตอนใน core Agent ที่ sample จาก check และ DogStatsD มารวมกันก่อน flush ไปยัง serializer และ forwarder flush ราวทุก 15 วินาที (11 ครั้งใน 180 วินาทีบน container ที่วัด) จึงเป็นเหตุผลหนึ่งที่ค่าไม่โผล่ใน Datadog ทันทีที่ส่ง	สถาปัตยกรรมของ Agent, DogStatsD กับ Aggregation
AI bug catalog	ข้อผิดพลาด 27 ข้อที่ config ของ Datadog ที่ AI สร้างมักทำซ้ำ ๆ (Agent, dd-trace, ddtrace, RUM, metric, Terraform, monitor) พร้อม output จริงและวิธีแก้ บางข้อ เช่น ไม่มี init_config: เป็น bug ลวงที่ Agent จริงยอมรับได้	AI bug catalog
allowedTracingUrls	option ของ RUM SDK ที่ระบุ origin ฝั่ง first-party ที่แอปบน browser เรียก สำหรับ URL เหล่านั้น SDK จะแนบ header ของ trace context เพื่อให้ span ฝั่ง backend เชื่อมกลับมาที่ RUM view ได้ และยังต้องตั้ง service ให้ชัดเจนด้วย ข้อควรระวัง: ถ้าไม่ตั้ง (หรือใช้ allowedTracingOrigins ที่เลิกใช้แล้ว) RUM กับ APM จะเป็นสอง view ที่ไม่เชื่อมกัน	RUM และ Real User Context, AI bug catalog
API key vs. Application key	API key อนุญาตให้ส่งข้อมูลเข้า (สิ่งที่ Agent ถือ) และผูกกับ organization ส่วน Application key อนุญาตให้ทำงานในฐานะ user ผ่าน API อ่าน/จัดการ (query, dashboard, monitor, Terraform) และรับสิทธิ์ของ user คนนั้น ข้อควรระวัง: Terraform provider ต้องใช้ทั้งสองตัว และถ้า user ถูกปิดหรือเสียสิทธิ์ Application key ก็เสียสิทธิ์ตามไปด้วย	Datadog คืออะไร, จัดการ Datadog เป็น Code ด้วย Terraform
API test	Synthetics test ที่ยิง request เดียวแบบ HTTP, TCP, DNS หรือ ICMP แล้วตรวจ assertion เช่น status code, response time หรือ body จับกรณีหน้าเว็บตอบ 200 แต่แสดงผลพังไม่ได้ ซึ่งเป็นหน้าที่ของ Browser test	Synthetics และ Uptime Check
assertion (Synthetics)	สามส่วน type / operator / target ที่ Synthetics test ตรวจทุกครั้งที่รัน คำศัพท์ operator จริงมาจาก enum ของ client (is, isNot, contains, matches, lessThan, moreThan ฯลฯ) จึงควรเทียบ operator ที่ดูแต่งขึ้นกับ model จริง	Synthetics และ Uptime Check
Autodiscovery	Agent เฝ้าดู container และ pod แล้วจับคู่กับ config template ที่แนบเป็น annotation ของ Kubernetes หรือ label ของ Docker สร้างและลบ config ของ check ตามที่ workload เกิดและหายไป ข้อควรระวัง: annotation ต้องอยู่ที่ .spec.template.metadata ไม่ใช่ที่ Deployment และ key ต้องใช้ชื่อ check (redisdb) ถ้าเขียน redis จะถูก discover แต่ไม่เคยรัน	Datadog Agent กับ Integration, AI bug catalog
auto-instrumentation	tracing library ที่ hook framework, HTTP client และ database driver เพื่อสร้าง span โดยไม่ต้องเขียนโค้ด tracing เอง แต่จะหยุดที่ขอบของ business logic ของคุณ ซึ่งต้องเพิ่ม manual span เอง ทั้งสองแบบรวมเป็น tree เดียวกัน	Traces, Spans, and the Service Map

B

Term	ความหมาย	บทเรียน
Browser test	Synthetics test ที่รัน user journey บน browser หลายขั้นตามสคริปต์ (โหลด, คลิก, assert) เพื่อทดสอบ flow จริงแบบ end to end model ต้องมี message และ steps และตรวจตามตารางเวลา ต่างจาก RUM ที่สังเกตผู้เข้าชมจริง	Synthetics และ Uptime Check, RUM และ Real User Context
burn rate	อัตราที่ error budget ถูกใช้ เทียบกับจังหวะที่จะใช้หมดพอดีเมื่อจบ window ของ SLO สูตรจากเอกสาร: ความยาวเป้า SLO เป็นชั่วโมง คูณเปอร์เซ็นต์ budget ที่ใช้ไป หารด้วย long window เป็นชั่วโมงคูณ 100 ข้อควรระวัง: burn rate 1 คือเป็นไปตามกำหนด ส่วน 14.4 บน long window 1 ชั่วโมงคือใช้ 2% ของ budget 30 วัน	SLO, Error Budget และ Burn Rate Alert
burn_rate() query	รูปแบบ query ของ monitor แบบ burn-rate: burn_rate("<slo_id>").over("30d").long_window("6h").short_window("30m") > 10 ต้องมีครบทั้งสามส่วน .over() คือเป้า 7d, 30d หรือ 90d ของ SLO เอง ไม่ใช่ window ของการแจ้งเตือน และ short window ประมาณ 1/12 ของ long window	SLO, Error Budget และ Burn Rate Alert, AI bug catalog

C

Term	ความหมาย	บทเรียน
cardinality	จำนวนชุดค่า tag ที่ต่างกันบน metric (หรือค่า facet บน log) custom metric ระบุด้วยชื่อร่วมกับค่า tag รวม tag ของ host ดังนั้น cardinality ไม่ใช่ปริมาณ data point คือตัวขับค่าใช้จ่าย ข้อควรระวัง: tag รายต่อ request เช่น request_id สร้าง time series ใหม่ถาวรทุกครั้งที่เรียก (30 ครั้งได้ 30 แถวใน dogstatsd-stats)	Tag กับ Unified Service Tagging, Custom Metrics ด้วย DogStatsD, Metrics without Limits และ Tag Cardinality
Category Processor	processor ของ log pipeline ที่กำหนดค่าให้ attribute ใหม่โดยจับคู่ log กับ query ตามลำดับ วิธีแก้ในบทเรียนสำหรับชื่อ level ที่ให้ผลไม่คาดคิด (SEVERE ของ Java กลายเป็น OK, E ตัวเดียวกลายเป็น info) คือ normalise level ด้วย category processor ก่อนถึง Status Remapper	Processor ใน Log Pipeline
check	โค้ด Python ชิ้นเล็กที่มากับ Agent ใช้คุยกับ service หนึ่งตัว (Postgres, Redis, NGINX ฯลฯ) แล้วแปลงสถานะเป็น metric ตั้งค่าที่ conf.d/<name>.d/conf.yaml ส่วน core check (cpu, memory, disk, network) ถูก compile อยู่ใน Go binary ของ Agent	Datadog Agent กับ Integration, Agent-Collected Metrics และ Checks
check API (gauge, count, monotonic_count, rate, histogram)	คำสั่งส่ง metric ห้าแบบของ check ใน Agent gauge, count และ histogram ส่งค่าตั้งแต่รันครั้งแรก แต่ rate กับ monotonic_count ต้องรันครั้งที่สองจึงคำนวณ delta ได้ ทำให้ agent check ครั้งเดียวดูเหมือนพัง (ใช้ --check-rate) การเรียก histogram ครั้งเดียวแตกเป็น metric ที่ derive ออกมาห้าตัว	Agent-Collected Metrics และ Checks
check scheduler / runner	scheduler จัดคิว check instance ตามช่วงเวลา (collector-queue-15s, -60s, -900s) แล้วส่งให้ runner worker ในพูลขนาดคงที่ check_runners ค่าเริ่มต้นคือ 4 check ที่ช้าจะกิน worker หนึ่งตัวตลอดการรัน และช่วงเริ่มต้นราว 15 วินาที เว้นแต่ตั้ง min_collection_interval	สถาปัตยกรรมของ Agent, Agent-Collected Metrics และ Checks
CI Visibility	ผลิตภัณฑ์สำหรับ observability ของ pipeline และการรันเทสต์ เชื่อม flaky test และ build ที่ช้ากลับไปยัง service เดียวกัน กล่าวถึงในฐานะส่วนหนึ่งของแผนที่ผลิตภัณฑ์เท่านั้น	Datadog คืออะไร
Cloud Cost Management	นำบิล cloud เข้ามาใน Datadog เป็น metric ที่ query และตั้ง monitor ได้ (เช่น aws.cost.amortized เทียบกับ aws.cost.unblended ซึ่งตรงกับ invoice) ข้อควรระวัง: monitor ต้นทุนสองตัวบน metric ต่างกันจะให้ค่าไม่ตรงกันโดยออกแบบ ให้เลือก metric ตามคำถาม ข้อมูล AWS อาจใช้ 48 ถึง 72 ชั่วโมงกว่าจะขึ้น ตามเอกสาร	Cost Governance และ Cloud Cost Management
Cloud Security (CSM, CSPM)	กลุ่มผลิตภัณฑ์ด้านความปลอดภัย: Misconfigurations, Identity Risks และ Vulnerabilities โดยการตรวจจับขณะรันอยู่ใต้ Workload Protection ชื่อ Cloud Security Management (CSM) เป็นชื่อร่มที่ยังพบทั่วไป ส่วน CSPM หมายถึงแค่ครึ่ง posture และเป็นคำที่ล้าสมัยในบทเรียนและ output ของ AI รุ่นเก่า	Security และ Compliance เบื้องต้น, Datadog คืออะไร, Datadog Agent กับ Integration
Cluster Agent	image แยกต่างหาก (datadog/cluster-agent) ที่ deploy หนึ่งตัวต่อ cluster ไม่ใช่ต่อ node ทำงานระดับ cluster (core check ของ Kubernetes State Metrics, External Metrics Provider สำหรับ HPA, Admission Controller, ประสานงาน cluster check) เพื่อไม่ให้ Agent ทุก node ยิง API server	Datadog Agent กับ Integration, สถาปัตยกรรมของ Agent
collected fence / @expect-error	code fence ที่บรรทัดแรกเป็น comment บอก path (# datadog.yaml, // monitors/<name>.json, # terraform/<name>.tf ฯลฯ) จะถูก harness ของคอร์สเก็บไปตรวจ ถ้าบรรทัดแรกมี @expect-error แปลว่าตั้งใจให้ล้มเหลวและถูกข้าม fence อื่นเป็นแค่ fragment ที่โหมดเข้มงวดไม่แตะ	Verification tools, AI bug catalog
Collector status (OTLP)	บรรทัดใน section OTLP ของ agent status ที่บอกว่า pipeline ของตัวรับยังทำงานอยู่หรือไม่: Running คือใช้งานได้ Closed คือ pipeline ตายตอน startup แยกจาก Status: Enabled ซึ่งแค่บอกว่ามี setting อยู่ การสะกด protocol แทน protocols ทำให้เห็น Enabled กับ Closed พร้อมกัน	OTLP กับมาตรฐานเปิด
composite monitor	monitor ที่รวม ID ของ monitor ที่มีอยู่ด้วย AND (&&), OR และ NOT (!) เพื่อแจ้งเตือนตามการผสมของสถานะ เช่น monitor error-rate ลั่นในขณะที่ monitor ของ upstream ไม่ลั่น ข้อควรระวัง: สูตรรับ ID ของ monitor ชื่อสมมติไม่ใช่ ID	Composite Monitor และ Notification Workflow, AI bug catalog
conf.d	ไดเรกทอรีของ Agent ที่มีหนึ่งโฟลเดอร์ต่อ integration (conf.d/<check>.d/conf.yaml) โฟลเดอร์ตั้งชื่อตาม check (redisdb ไม่ใช่ redis) instances: ต้องเป็น list แม้มีตัวเดียว ส่วน init_config: เขียนตามธรรมเนียมแต่ Agent ยอมให้ไม่มี	Datadog Agent กับ Integration, Agent-Collected Metrics และ Checks, AI bug catalog
core check	check ที่ถูก compile อยู่ใน Go binary ของ Agent (cpu, memory, disk, network, io) รันได้โดยไม่ต้องตั้งค่าและให้ metric system.* ต่างจาก integration ตรงที่ติดตั้งหรืออัปเกรดแยกไม่ได้ ต้องอัปเกรดทั้ง Agent	Agent-Collected Metrics และ Checks
COUNT	type ของ DogStatsD (c) และคำสั่งของ check: บวกตัวนับตามค่าที่ให้ ตอบคำถามว่า X เกิดกี่ครั้ง ตอน Agent flush ตัวนับจะกลายเป็น rate ต่อวินาทีบน bucket 10 วินาที (บวก 5 ครั้งได้ 0.5)	Custom Metrics ด้วย DogStatsD, DogStatsD กับ Aggregation
critical / warning thresholds	เส้นทริกเกอร์ใน options.thresholds: เมื่อข้าม critical metric alert เข้าสถานะ Alert ข้าม warning ที่ต่ำกว่าเข้า Warn ตอบเพียงว่าเมื่อไรถือว่าเป็นปัญหา ส่วน recovery เป็นอีกคู่หนึ่งต่างหาก	Monitor Types และ Thresholds
custom check (checks.d)	ไฟล์ Python 3 ใน checks.d/ ที่สืบทอด AgentCheck คู่กับ conf.d/<name>.d/conf.yaml __NAMESPACE__ จะเติม prefix ให้ทุกชื่อ metric และ service check อัตโนมัติ ถ้าชื่อมี prefix อยู่แล้วก็จะซ้ำสองชั้น	Agent-Collected Metrics และ Checks
custom metric	metric ที่คุณส่งเอง (DogStatsD, custom check, API) ไม่ใช่ metric ที่ integration มีมาให้ คิดเงินตามจำนวนชุดชื่อบวกค่า tag ที่ไม่ซ้ำ เอกสารระบุโควตาต่อ host (Pro 100, Enterprise 200) จึงควรประเมิน cardinality ก่อนขึ้นจริง	Custom Metrics ด้วย DogStatsD, Metrics without Limits และ Tag Cardinality, Cost Governance และ Cloud Cost Management

D

Term	ความหมาย	บทเรียน
Dashboard (ordered vs. free)	ชุด widget ที่บันทึกไว้ layout_type เป็น field บังคับ: ordered เรียง widget ให้อัตโนมัติ (ค่าเริ่มต้นที่เหมาะ) ส่วน free วางแต่ละอันด้วย x, y, width, height เอง ข้อควรระวัง: JSON ที่มีแค่อาร์เรย์ widgets จะเกิด error ว่าขาดอาร์กิวเมนต์ layout_type	Dashboard กับทัวร์ Datadog UI, สร้าง Dashboard และ Notebook
Datadog connector (trace metrics)	connector ของ OpenTelemetry Collector ที่แปลง span เป็น trace metric มันเป็น exporter ของ pipeline traces และ receiver ของ pipeline metrics ถ้าไม่ต่อครบสองฝั่ง trace metric จะหายไป (validate ของ Collector ปฏิเสธไฟล์ที่ต่อผิดด้วย exit 1) สูตรใหม่ในเอกสารใช้ connector span_metrics คู่กับ exporter otlp_http แทน	OTLP กับมาตรฐานเปิด
datadog_dashboard vs. datadog_dashboard_json	Terraform resource สองตัวที่ต่างกัน datadog_dashboard ใช้ block ของ HCL โดย request ของ widget ต้องเป็น query { metric_query { ... } } พร้อม block formula การเขียน name / data_source / query แบบแบนใน query จะถูก terraform validate ปฏิเสธ ส่วน datadog_dashboard_json รับ body ทั้งก้อนเป็น JSON string	จัดการ Datadog เป็น Code ด้วย Terraform, สร้าง Dashboard และ Notebook, AI bug catalog
Datadog Exporter	component ใน OpenTelemetry Collector (otel/opentelemetry-collector-contrib) ที่ส่ง telemetry ไป intake ของ Datadog โดยไม่ผ่าน Agent key ต้องซ้อน (api.key) ถ้าเขียน apikey: แบบแบน คำสั่ง validate ของ Collector จะปฏิเสธ	Datadog คืออะไร
datadog_monitor / datadog_monitor_json	datadog_monitor ระบุ monitor ด้วย attribute ที่มี type (monitor_thresholds, notify_no_data, no_data_timeframe) ส่วน datadog_monitor_json รับ body ทั้งก้อนเป็น JSON query เป็นไวยากรณ์ API ดิบที่ต้องเขียนเอง ไม่ใช่สิ่งที่ตัวสร้าง query ใน UI แสดง	จัดการ Datadog เป็น Code ด้วย Terraform, Monitor Types และ Thresholds
Datadog Operator / DatadogAgent CRD	วิธีติดตั้งบน Kubernetes ที่แนะนำ: Operator ทำ reconcile custom resource DatadogAgent และรายงานสุขภาพใน status ส่วน Helm chart (datadog/datadog) render manifest ให้ schema ของ CRD จะปฏิเสธ key ที่สะกดผิด ซึ่งค่าใน Helm values อาจปล่อยผ่านเงียบ ๆ	Datadog Agent กับ Integration, Production Rollout Checklist
Date Remapper / Status Remapper / Message Remapper	processor ใน pipeline ที่ยกระดับ attribute ที่ parse แล้วให้เป็น timestamp ทางการ, ระดับ status หรือข้อความหลักของ log ทำให้ query และ facet ตามระดับความรุนแรงใช้ข้ามหลาย service ที่ตั้งชื่อ field ต่างกันได้ ข้อควรระวัง: remapper ที่วางก่อน parser ที่สร้าง attribute ของมัน จะไม่มีอะไรให้ remap	Log Collection and Processing Pipelines, Structured Logging and Log Facets
date() matcher (Grok)	matcher ของ Grok date("pattern"[, "timezoneId"[, "localeId"]]) pattern ไม่มี zone ในตัว ถ้าไม่ส่งมา log ที่เขียนเป็นเวลาท้องถิ่น (เช่น Asia/Bangkok, UTC+7) จะถูกอ่านเป็น UTC และตกไปอยู่ในอนาคตเจ็ดชั่วโมง เกินหน้าต่างอนาคตสองชั่วโมงตามเอกสาร ควรส่ง zone เสมอ	Processor ใน Log Pipeline
DD_CHECKS_TAG_CARDINALITY	ตัวปรับของ Agent ว่าจะแนบ tag กับ metric ของ check มากแค่ไหน: low (ค่าเริ่มต้น: cluster, host, image), orchestrator (เพิ่ม pod หรือ task), high (เพิ่ม container รายตัว, user ID) การปรับขึ้นเป็นการตัดสินใจเรื่องต้นทุนโดยตั้งใจ ตัวคู่สำหรับ DogStatsD คือ DD_DOGSTATSD_TAG_CARDINALITY	Tag กับ Unified Service Tagging
DD_ENV / DD_SERVICE / DD_VERSION	environment variable ที่พา unified service tagging เข้า tracer (จำเป็นเฉพาะเมื่อใช้ APM) และใน container Agent จะแปลงเป็น tag env: / service: / version: ข้อควรระวัง: DD_SERVCE ที่สะกดผิดไม่มี error แค่ container ได้ tag ไม่ครบ และค่าไม่ถูกแปลงเป็นตัวพิมพ์เล็กฝั่ง client ดังนั้น DD_ENV=Prod ไม่ใช่ค่าเดียวกับ prod	Unified Service Tagging ในทางปฏิบัติ, Production Rollout Checklist, AI bug catalog
dd.* log fields	ข้อมูลตัวตนที่ถูกฉีดลงบรรทัด log: dd.trace_id กับ dd.span_id เป็น key ที่ใช้กระโดด และ dd.env, dd.service, dd.version ทำให้จากบรรทัด log เปิดไปยัง trace ที่ตรงกันได้ในคลิกเดียว	เชื่อม Log เข้ากับ Trace, Structured Logging and Log Facets
DD_LOGS_INJECTION / logInjection	วิธีที่ tracer ใส่ field dd.* ลงในบรรทัด log Node ใช้ option logInjection ส่วน Python ใช้ DD_LOGS_INJECTION ร่วมกับ ddtrace-run หรือ patch_all() ข้อควรระวัง: log_injection (snake_case) ถูก dd-trace ละเว้นเงียบ ๆ และที่ดูเหมือนใช้ได้เพราะค่าเริ่มต้นเป็น true อยู่แล้ว	เชื่อม Log เข้ากับ Trace, AI bug catalog
DD_SITE	การตั้งค่าของ Agent หรือ tracer ที่ระบุ site ของ Datadog เป็นโดเมน เช่น datadoghq.com ไม่ใช่ URL ถ้าชี้ไป intake ของ site ผิดจะไป authenticate กับ backend ผิดตัว	Datadog คืออะไร, AI bug catalog
dd_url and per-writer URLs	dd_url (DD_DD_URL) ย้ายเฉพาะ forwarder ของ core Agent ส่วน writer ของ Trace Agent, Logs Agent และ process ยังใช้ค่าเริ่มต้น และแต่ละตัวมี setting ของตัวเอง: apm_config.apm_dd_url, logs_config.logs_dd_url, process_config.process_dd_url Agent ที่ใช้ key ปลอมและเปลี่ยนแค่ dd_url ยังไปถึง intake จริงและได้ HTTP 403	สถาปัตยกรรมของ Agent
DDSketch	quantile sketch ของ Datadog ที่ merge ได้ (Masson, Rim, Lee, VLDB 2019) พร้อมการรับประกัน relative error การ merge sketch ของสามเครื่องคลาดเคลื่อน 0.5% ที่ p99 ขณะที่เฉลี่ยค่า p99 ของแต่ละเครื่องคลาดเคลื่อน 46% ใช้เป็นฐานของ percentile ความหน่วงของ trace และ metric แบบ DISTRIBUTION	Trace Metrics และ DDSketch, DogStatsD กับ Aggregation
DD_SPAN_SAMPLING_RULES	ตั้งค่า single-span sampling ซึ่งเก็บ span ที่เลือก (เช่น การเรียก database ที่ช้า) ไว้ แม้การตัดสินใจระดับ trace จะทิ้งทั้ง trace ค่าเพดาน max_per_second กันไม่ให้ operation ที่มีปริมาณสูงทำลายจุดประสงค์ของ ingestion sampler	Ingestion Sampling เทียบกับ Retention Filters
DD_TAGS	ตัวแปรสภาพแวดล้อมของรายการ tags: ในไฟล์ของ Agent เป็นลิสต์คั่นด้วยช่องว่าง ดังนั้น team:payments api จะกลายเป็นสอง tag (team:payments กับ api เปล่า ๆ) ต่างจากรายการ tags: ใน YAML ที่เป็น string เดียว	Tag กับ Unified Service Tagging
DD_TRACE_PROPAGATION_STYLE	รูปแบบ trace context ที่ tracer ใส่และอ่าน: datadog, tracecontext (W3C), b3, b3multi, baggage, none ข้อควรระวัง: สอง service ที่ไม่มีรูปแบบร่วมกันจะแยกหนึ่ง trace เป็นสองอันตรงจุดนั้นโดยไม่มี error ทำให้ Service Map มีช่องว่าง	Traces, Spans, and the Service Map, เชื่อม Log เข้ากับ Trace
DD_TRACE_RATE_LIMIT	เพดานของ tracer ว่า head sampler เก็บ trace ได้กี่อันต่อวินาที (100 เมื่อไม่ตั้ง) ใช้หลังจากคำนวณ sampling rate แล้ว trace ที่มี _dd.rule_psr=1 คู่กับ priority -1 ถูก limiter ตัวนี้ทิ้ง และ _dd.limit_psr บันทึกอัตราจริงที่ใช้	Pipeline การ Sampling ของ Trace, Ingestion Sampling เทียบกับ Retention Filters
DD_TRACE_SAMPLING_RULES / DD_TRACE_SAMPLE_RATE	ตัวควบคุม head sampling ใน tracer rule จับคู่ตาม service, name, resource หรือ tag ส่วน sample rate รวมถูก implement เป็น rule ลำดับความสำคัญคือ rule, อัตราจาก Agent, แล้วค่าเริ่มต้น ข้อควรระวัง: DD_TRACE_SAMPLE_RATE ไม่ได้ deprecated — dd-trace (Node) ทำตาม แต่ ddtrace (Python) 4.15.2 เมินเงียบ ๆ ให้ใช้ DD_TRACE_SAMPLING_RULES เพื่อพฤติกรรมข้ามภาษา	Pipeline การ Sampling ของ Trace, Ingestion Sampling เทียบกับ Retention Filters, AI bug catalog
decision mechanism (_dd.p.dm)	tag _dd.p.dm บันทึกว่ากลไก sampling ใดตัดสิน trace: เครื่องหมาย - ตามด้วยรหัส ค่าคงที่ของ tracer (dd-trace 6.17.0): 0 default, 1 อัตราจาก Agent, 3 rule, 4 manual, 5 App and API Protection, 8 span rule, 11 remote user rule, 12 remote dynamic rule, 13 AI Guard ส่วน -9 คือ probabilistic sampler ของ Agent ซึ่งไม่อยู่ในค่าคงที่ของ tracer trace ที่ถูก reject ไม่มี dm	Pipeline การ Sampling ของ Trace
DISTRIBUTION	type ของ DogStatsD (d) ที่ส่งค่าดิบเพื่อให้ backend คำนวณ percentile แบบ global Agent ส่ง DDSketch ไปที่ /api/beta/sketches ไม่ใช่ series percentile นอกจาก count, min, max, sum, avg ต้องเปิดเอง (include_percentiles) ข้อควรระวัง: รวมล่วงหน้าฝั่ง client ไม่ได้ ต่างจาก counter และ gauge	Custom Metrics ด้วย DogStatsD, DogStatsD กับ Aggregation, Metrics without Limits และ Tag Cardinality
DogStatsD	daemon ที่มากับ Agent รับ datagram ของ custom metric ผ่าน UDP (พอร์ต 8125) หรือ Unix domain socket ข้อควรระวัง: agent dogstatsd-stats นับ context ที่เป็นชื่อบวก tag ที่ไม่ซ้ำ ซึ่งเป็นหน่วยเดียวกับที่ใช้คิดเงิน custom metric	Custom Metrics ด้วย DogStatsD, DogStatsD กับ Aggregation
DogStatsD datagram	ข้อความหนึ่งบรรทัด: name:value ตามด้วยรหัส type (c, g, h, d, s, ms) sample rate แบบ @ (ไม่บังคับ) และ #tag1,tag2 การ buffer รวมหลายบรรทัดในแพ็กเก็ตเดียว ส่วน client-side aggregation จะยุบ counter, gauge และ set ก่อนส่ง	Custom Metrics ด้วย DogStatsD, DogStatsD กับ Aggregation
Downtime	ช่วงปิดเสียงที่ระงับการแจ้งเตือนของ monitor ระหว่างงานบำรุงรักษาที่วางแผนไว้ โดยการประเมินและประวัติสถานะยังดำเนินต่อ และการแจ้งเตือนกลับมาเองเมื่อสิ้นสุด	Composite Monitor และ Notification Workflow

E

Term	ความหมาย	บทเรียน
error budget	ปริมาณเวลาหรือเหตุการณ์เสียที่เป้าหมายยอมให้ เช่น 99.9% ใน 30 วันคือ budget 43.2 นาที เมื่อเหลือ 0% แปลว่า window นั้นต่ำกว่าเป้าไปแล้ว	SLO, Error Budget และ Burn Rate Alert
error budget alert	การแจ้งเตือน SLO ตามสัดส่วนสะสมของ budget ที่ใช้ไป (เช่น warn ที่ 50% alert ที่ 75%) บอกว่ากำลังจะหมด เหมาะกับการตัดสินใจว่าควร ship การเปลี่ยนแปลงเสี่ยงหรือไม่ แต่ไม่บอกว่าเกิดเร็วแค่ไหน เทียบกับ burn rate alert	SLO, Error Budget และ Burn Rate Alert
error sampler / rare sampler	sampler ฝั่ง Agent ที่บังคับใช้จริง error sampler กู้ trace ที่มี error ซึ่ง head sampler ปฏิเสธ (ค่าเริ่มต้นราว 10 ต่อวินาทีต่อ Agent วัดได้ 105 จาก 500) ส่วน trace ที่ถูกปฏิเสธและไม่มี error จะถูกทิ้งหมด rare sampler ปิดเป็นค่าเริ่มต้น	Pipeline การ Sampling ของ Trace
Error Tracking	จัดกลุ่ม error ที่ซ้ำจาก trace และ log เป็น issue เดียวที่มี lifecycle แบบ new, triaged, resolved พร้อมลิงก์ไปยัง trace ตัวอย่าง เริ่มต้นจาก trace จึงบอกได้ว่า span ที่ล้มเหลวอยู่ใน issue ที่ dedupe แล้วตัวไหน	Continuous Profiler และ Error Tracking
escalation_message	ข้อความแยกสำหรับการแจ้งซ้ำ ใช้คู่กับ renotify_interval ข้อควรระวัง: ต้องซ้อนอยู่ใต้ options ถ้าวางระดับบนสุด constructor ของ client รับโดยไม่ error แต่ไม่มีผลใด ๆ	Composite Monitor และ Notification Workflow
evaluation_delay	จำนวนวินาทีที่ monitor เลื่อน window การประเมินให้ช้าลง เพื่อให้ข้อมูลที่มาช้า (metric ต้นทุน, pipeline ที่ช้า) ครบก่อนตัดสิน	Monitor Types และ Thresholds
exclude_at_match	ชนิด log_processing_rules ฝั่ง Agent ที่ทิ้งบรรทัดดิบที่ตรง regex ก่อนออกจากเครื่อง เป็นจุดกรองที่ถูกที่สุดแต่สิ้นสุดเด็ดขาด ไม่ถูก archive ไม่ถูก parse และกู้คืนไม่ได้	Indexes, Exclusion Filters, and Retention
Exclusion Filter	query แบบ Lucene บน Log Index ที่สุ่มทิ้งหรือทิ้ง log ที่ตรงจาก index นั้นเท่านั้น log ยังไปถึง index อื่น, Archive หรือ log-based metric ได้ ข้อควรระวัง: query: "*" กับ sample_rate: 1.0 ทิ้งทุกอย่างและผ่าน validation ได้ปกติ	Indexes, Exclusion Filters, and Retention, AI bug catalog

F

Term	ความหมาย	บทเรียน
Facet	attribute ของ log ที่ถูกยกระดับให้ Logs Explorer กรอง จัดกลุ่ม และทำกราฟได้ การสร้างทำได้ใน UI เท่านั้น (ไม่มี API model สาธารณะ) และ Log Analytics บน facet เห็นเฉพาะ log ที่ถูก index	Structured Logging and Log Facets
flapping	monitor ที่สลับระหว่าง Alert กับ OK เมื่อค่าแกว่งอยู่ที่เกณฑ์ การตั้ง recovery threshold ให้ต่ำกว่าเกณฑ์ทริกเกอร์อย่างมีนัย (เช่น 70 เทียบกับ 90) สร้างโซนตายที่กันอาการนี้	Monitor Types และ Thresholds, จัดการ Datadog เป็น Code ด้วย Terraform
Flex Logs	ชั้นเก็บ log ที่ถูกกว่าและเก็บได้นานกว่าสำหรับ log ที่ index แล้ว ปรากฏเป็น num_flex_logs_retention_days ข้าง num_retention_days ใน model LogsIndex คอร์สไม่ระบุราคา	Indexes, Exclusion Filters, and Retention
forwarder	stage ของ core Agent ที่รับผิดชอบทุก HTTP request และการ retry payload ที่ล้มเหลวถูกจัดคิวใหม่ในหน่วยความจำพร้อม backoff (RetryQueueSize) Trace Agent และ Logs Agent ไม่ผ่านตัวนี้ มี writer และ endpoint ของตัวเอง	สถาปัตยกรรมของ Agent

G

Term	ความหมาย	บทเรียน
GAUGE	type ของ DogStatsD (g) และคำสั่งของ check: ค่าที่แน่นอน ณ ขณะนั้น โดยมีแค่ค่าสุดท้ายในช่วงที่มีความหมาย (999 หลังเรียก 1,000 ครั้ง)	Custom Metrics ด้วย DogStatsD, Agent-Collected Metrics และ Checks, DogStatsD กับ Aggregation
Grok Parser	processor ใน pipeline ที่ใช้ pattern แบบ Grok ดึง attribute ออกจากบรรทัดข้อความอิสระ เป็นการเดิมพันว่ารูปแบบจะไม่เปลี่ยน log แบบ JSON ที่มีโครงสร้างไม่ต้องเดิมพัน	Log Collection and Processing Pipelines, Structured Logging and Log Facets

H

Term	ความหมาย	บทเรียน
harness modes (—options, —tf, —json, —agent)	สี่วิธีที่ npm run verify ตรวจ fence ที่ถูกเก็บ: --options (ทุก option ของ tracer, attribute ของ ddtrace.config และชื่อ DD_* ต้องมีจริง), --tf (terraform validate กับ provider ที่ pin ไว้), --json (model ของ datadog-api-client และ schema ของ Service Catalog), --agent (Agent จริงเริ่มได้ด้วย YAML ของคุณ) จุดบอด: --agent รายงาน 0 failed กับ instances: แบบ mapping ที่ configcheck เองยังเตือน	Verification tools
head-based sampling	การตัดสินใจเก็บหรือทิ้งที่ทำครั้งเดียวตอนเริ่ม root span แล้วส่งต่อให้ทุก service ปลายทางใน trace เป็น Gate 1 ของ pipeline อัตราอาจมาจาก rule, Agent หรือค่าเริ่มต้น	Pipeline การ Sampling ของ Trace, Ingestion Sampling เทียบกับ Retention Filters
HISTOGRAM	type ของ DogStatsD (h) ที่ Agent รวมต่อ host เป็น .avg, .max, .median, .95percentile และ .count ข้อควรระวัง: ค่าเหล่านี้เป็นรายเครื่อง ถ้าต้องการ percentile แบบ global ต้องใช้ DISTRIBUTION และ Metrics without Limits ไม่มี metric type histogram มีแต่ series ที่ derive ออกมา	Custom Metrics ด้วย DogStatsD, Agent-Collected Metrics และ Checks, AI bug catalog
host tags	tag ที่แนบกับทุกสิ่งที่ Agent รายงานบน host: แบบอัตโนมัติ (hostname, metadata ของ cloud) และรายการ tags: ใน datadog.yaml agent status แสดงตามที่ตั้งไว้ ส่วนการแปลงเป็นตัวพิมพ์เล็กและการจัดการช่องว่างเกิดฝั่ง server	Tag กับ Unified Service Tagging, Unified Service Tagging ในทางปฏิบัติ

I

Term	ความหมาย	บทเรียน
ingestion (APM)	ชั้นที่ 1 ของ trace sampling: จำนวน trace ที่ถูกส่งไป Datadog จริง สิ่งที่ไม่ถูก ingest กู้คืนไม่ได้ และแยกอิสระจาก retention filter ที่ตัดสินว่าอะไรค้นหาได้ต่อไป อัตรา ingestion สูงไม่ได้รับประกันว่าจะถูกเก็บ	Ingestion Sampling เทียบกับ Retention Filters, Pipeline การ Sampling ของ Trace
Ingestion Control page	หน้าฝั่ง backend ที่แสดงและปรับค่า ingestion ต่อ service โดยการเปลี่ยนอัตราถึง tracer ผ่าน Remote Configuration (Agent 7.41.1 ขึ้นไป ตามเอกสาร) มาจากเอกสาร ไม่ได้รันในคอร์ส	Pipeline การ Sampling ของ Trace
integration	Python wheel ที่แยกเวอร์ชัน (เช่น datadog-redisdb) ที่มากับ image ของ Agent และจัดการด้วย agent integration install ได้โดยไม่แตะ binary ของ Agent จะรันก็ต่อเมื่อมีไฟล์ใน conf.d ของมัน	Datadog Agent กับ Integration, Agent-Collected Metrics และ Checks
Intelligent Retention Filter	filter ฝั่ง backend ที่ทำงานตลอดเวลา เก็บสัดส่วนตัวแทนของ trace ที่ ingest มาเพื่อดูสุขภาพโดยรวม เพิ่มจาก retention filter ที่ตั้งเอง มาจากเอกสาร	Ingestion Sampling เทียบกับ Retention Filters, Pipeline การ Sampling ของ Trace

L

Term	ความหมาย	บทเรียน
Log Analytics	group-by, measure และ aggregation บน facet ใน Logs Explorer ทำงานกับ log ที่ index แล้วเท่านั้น log ที่ถูก exclude จึงต้องผ่อน filter, ใช้ log-based metric หรือ Rehydration ถึงจะวิเคราะห์ได้	Structured Logging and Log Facets
Log Archive	สตรีม log แบบเต็มที่ส่งไปยังที่เก็บของคุณเอง (S3, GCS, Azure Blob) ไม่ว่า Exclusion Filter จะทำอะไร ใช้เพื่อ compliance และเก็บระยะยาว ค้นหาโดยตรงไม่ได้ ต้องใช้ Archive Search หรือ Rehydration	Log-Based Metrics and Logging without Limits
log-based metric	metric แบบ COUNT หรือ DISTRIBUTION ที่คำนวณจากสตรีม ingest ทั้งหมด รวมถึง log ที่ไม่มี index ใดเก็บ ความละเอียด 10 วินาที และเก็บ 15 เดือนตามบทเรียน aggregation_type มีแค่ count หรือ distribution	Log-Based Metrics and Logging without Limits
log_processing_rules	rule ฝั่ง Agent ใน block logs: (exclude_at_match, mask_sequences, multi_line) ทำงานบน host ก่อนส่งบรรทัดออกไป และไม่มีอะไรด้านหลังย้อนได้ ข้อมูลที่ห้ามเก็บจึงควรจัดการที่นี่ ไม่ใช่ใน pipeline ฝั่ง backend	Processor ใน Log Pipeline
Logging without Limits	ชื่อที่ Datadog ใช้เรียกการแยก ingestion ของ log ออกจากการ index ทำให้ metric และ Archive ดึงจากทุกอย่างที่ ingest ขณะที่ index เก็บเฉพาะที่เลือกจะจ่าย	Log-Based Metrics and Logging without Limits
Log Index	ที่ที่เกิดการเก็บ log แบบค้นหาได้ในราคาเต็ม ค่าสำคัญ: num_retention_days (ไม่ใช่ retention_days), daily_limit, filter และ Exclusion Filter เมื่อมีหลาย index จะใช้ตัวแรกที่ตรงเงื่อนไข (LogsIndexesOrder)	Indexes, Exclusion Filters, and Retention
log injection	tracer hook เข้า logging library อ่าน span ที่ active จาก context ระดับ request แล้วเติม trace_id และ span_id ให้ทุก record ทำให้จากบรรทัด log กระโดดไปยัง trace ที่ตรงกันได้ แทนการเทียบด้วย timestamp	เชื่อม Log เข้ากับ Trace

M

Term	ความหมาย	บทเรียน
Metrics without Limits	แยก tag ที่ส่งเข้ามาออกจาก tag ที่ index และ query ได้ ทำต่อ custom metric แต่ละตัว ไม่ทำลายข้อมูลและย้อนกลับได้ โดยไม่ต้อง deploy ใหม่ ปริมาณ ingested และ indexed คิดเงินแยกกัน metric_type รับ gauge, rate, count, distribution	Metrics without Limits และ Tag Cardinality
min_collection_interval	option ต่อ instance ของ check ที่ตั้งช่วงเวลารัน (ค่าเริ่มต้นราว 15 วินาที) scheduler ทำตามจริง: ตั้ง 30 ได้สามรอบในเวลาประมาณ 90 วินาที	Agent-Collected Metrics และ Checks
min_location_failed	option ของ Synthetics: ต้องมีกี่ location ล้มเหลวก่อนแจ้งเตือน ค่าเริ่มต้นคือ 1 ดังนั้น test ที่รันจากสาม location จะแจ้งเตือนทันทีที่ตัวใดตัวหนึ่งล้ม ใช้ร่วมกับ options.retry ซึ่งลอง location เดิมซ้ำก่อน	Synthetics และ Uptime Check
monitor	query ที่บันทึกไว้ร่วมกับกฎที่แปลงผลลัพธ์เป็น OK, Warn, Alert หรือ No Data มีหลายชนิด (metric, log, APM, composite, synthetics, SLO, RUM, service check) ใช้ model และ pipeline การแจ้งเตือนเดียวกัน ต่างกันแค่แหล่งข้อมูล	Monitor Types และ Thresholds, Synthetics และ Uptime Check

N

Term	ความหมาย	บทเรียน
Notebook	เอกสารไล่ตั้งแต่บนลงล่างที่ผสมกราฟ, query ของ log และ markdown เหมาะกับ timeline ของ incident และ postmortem มีเฉพาะใน v1 ของ API client และใช้รูปแบบ widget definition เดียวกับ dashboard	Dashboard กับทัวร์ Datadog UI, สร้าง Dashboard และ Notebook
notify_no_data	แจ้งเตือนเมื่อ query เลิกคืนข้อมูล ข้อควรระวัง: monitor ต้องเคยประเมินข้อมูลได้อย่างน้อยครั้งหนึ่ง ถ้าชื่อ metric หรือ tag ผิดจนไม่เคยรายงานจะไม่เคยแจ้ง พฤติกรรมเริ่มต้นเมื่อข้อมูลหายยังต่างกันตามชนิด query (เช่น default_zero())	Monitor Types และ Thresholds, AI bug catalog, จัดการ Datadog เป็น Code ด้วย Terraform

O

Term	ความหมาย	บทเรียน
origin detection	การแปะ metadata ของ container ให้ metric ของ DogStatsD ต้องใช้ Unix domain socket (ผู้เขียนที่ผูกกับ filesystem ซึ่ง Agent ยืนยันตัวตนได้) และโหมด host PID ดังนั้น UDP ทำไม่ได้ อ้างจากเอกสารในบทเรียน ไม่ได้รันจริง	Custom Metrics ด้วย DogStatsD
OTel semantic convention mapping	service.name ของ OTel แมปเป็น service, service.version เป็น version และ deployment.environment.name เป็น env (deployment.environment แบบเก่าเลิกใช้แล้ว) ต้องใช้ Agent 7.58.0 ขึ้นไป, Datadog Exporter v0.110.0 ขึ้นไป หรือส่ง OTLP ตรง	Datadog คืออะไร
otelcol validate	การตรวจ config ของ Collector เอง ต่างจาก configcheck ของ Agent ตรงที่มันสร้าง graph ของ pipeline จริง ใน otelcol-contrib 0.161.0 จึงปฏิเสธ connector ที่ต่อผิดด้วย exit 1 และ apikey: แบบแบนใต้ Datadog Exporter ขณะที่ไฟล์ที่ถูกต้องผ่านด้วย exit 0	OTLP กับมาตรฐานเปิด
OTLP	โปรโตคอลของ OpenTelemetry ที่ไม่ผูกกับผู้ขาย เมื่อเปิด otlp_config Agent จะเป็นตัวรับที่พอร์ต 4317 (gRPC) และ 4318 (HTTP) (agent status แสดง Status: Enabled) หรือใช้ Collector ส่งผ่าน Datadog Exporter แทนก็ได้	Datadog คืออะไร, สถาปัตยกรรมของ Agent
OTLP metrics translation	วิธีที่ Agent แปลง OTLP metric เป็น metric ของ Datadog: cumulative_monotonic_mode: to_delta ทำให้ค่าแรกของ cumulative counter เป็น baseline ที่ไม่เกิดจุดข้อมูล (การ export ครั้งที่สองได้ delta 15) และ histograms.mode: distributions สร้าง DDSketch จาก bucket ที่ระบุ resource attribute เช่น service.name กลายเป็น tag ของ unified service tagging	OTLP กับมาตรฐานเปิด
OTLP probabilistic sampler	sampler ที่ใช้กับ OTLP trace (otlp_config.traces.probabilistic_sampler) ไม่มี tracer ของ Datadog เกี่ยวข้อง DD_TRACE_SAMPLING_RULES จึงไม่มีผล ที่ตั้งไว้ 25% เก็บได้ 98 จาก 400 trace (24.5%)	OTLP กับมาตรฐานเปิด, Pipeline การ Sampling ของ Trace
otlp_config	section ของ datadog.yaml ที่เปิดตัวรับ OTLP ของ Agent ปิดอยู่เป็นค่าเริ่มต้น endpoint อยู่ใต้ receiver.protocols.grpc.endpoint / receiver.protocols.http.endpoint (DD_OTLP_CONFIG_RECEIVER_PROTOCOLS_*_ENDPOINT ซึ่งต้องส่งถึงทั้ง core Agent และ Trace Agent) ข้อควรระวัง: localhost container อื่นเข้าไม่ถึง ใน container ให้ใช้ 0.0.0.0 topology ที่รองรับคือหนึ่ง Agent ต่อหนึ่ง host	OTLP กับมาตรฐานเปิด
otlp_http exporter	exporter ของ OpenTelemetry Collector ที่เอกสารแนะนำสำหรับ Datadog ในปัจจุบัน ส่งไปที่ OTLP intake ของ Datadog (https://otlp.<YOUR_DD_SITE>) คู่กับ connector span_metrics และ Datadog extension config มีรูปแบบต่างจาก Datadog Exporter รุ่นเก่า config ที่ AI เขียนจึงมักปนสองแบบเข้าด้วยกัน	OTLP กับมาตรฐานเปิด

P

Term	ความหมาย	บทเรียน
phantom bug	”bug” ที่ AI หรือ reviewer รายงานแต่การรันจริงหักล้างได้ ตัวอย่างในแคตตาล็อกคือคำกล่าวว่าการขาด init_config: ทำให้ check พัง แต่ Agent โหลดได้ปกติ การ review คือการพิสูจน์ bug ไม่ใช่แค่สงสัย	AI bug catalog
pipeline filter (logs)	query ที่ตัดสินว่า log ใดเข้า log pipeline ถูกประเมินก่อน processor ของ pipeline จึง filter ด้วย attribute ที่ pipeline นั้นสกัดเองไม่ได้ เอกสารแนะนำไม่เกิน 20 processor ต่อ pipeline และ 10 parsing rule ต่อ Grok processor	Processor ใน Log Pipeline
Powerpack	กลุ่ม widget ของ dashboard ที่บันทึกและนำกลับมาใช้ซ้ำได้ ใส่ลงหลาย dashboard ได้	สร้าง Dashboard และ Notebook
preprocessing (JSON logs)	ขั้นตอนที่รันกับ JSON log ก่อนเข้า pipeline ใด ๆ โดยใช้ reserved attribute เช่น timestamp, status, host, service และ message log ที่มี level, severity, status หรือ syslog.severity อยู่แล้วจะได้ status ที่ขั้นนี้ remapper ใน pipeline จึงอาจไม่มีโอกาสเลือก	Processor ใน Log Pipeline
priority (monitor)	จำนวนเต็ม 1 (สูง) ถึง 5 (ต่ำ) ใน payload ของ monitor ส่วน template ของข้อความใช้รูปแบบสตริง {{#is_priority 'P2'}} การส่งสตริงแบบ P เข้า field ของ payload เป็น type error	Composite Monitor และ Notification Workflow
private location	location ของ Synthetics ที่คุณโฮสต์เองเพื่อทดสอบแอปและ endpoint ภายในที่เข้าจากเครือข่ายสาธารณะของ Datadog ไม่ได้	Synthetics และ Uptime Check
probabilistic sampler (Agent)	sampler ฝั่ง Agent ที่เปิดด้วย DD_APM_PROBABILISTIC_SAMPLER_ENABLED=true และ ..._SAMPLING_PERCENTAGE เก็บเปอร์เซ็นต์คงที่ด้วยการ hash (210 จาก 1,000 ที่ 20%) ติด tag _dd.p.dm=-9 ให้ trace ที่เก็บ และ Agent จะตอบ rate_by_service ว่าง ({}) เพราะทำ sampling เอง	Pipeline การ Sampling ของ Trace
Process Agent	เก็บข้อมูล process แบบสดสำหรับ Live Processes ใน Agent 7.83.3 บน Linux ไม่ได้เป็น process แยกอีกต่อไป core Agent เป็นผู้เริ่ม process component และ agent status รายงานเป็น Process Component	Datadog Agent กับ Integration, สถาปัตยกรรมของ Agent
Process Component	section ของ agent status ที่แสดง process check ที่รันอยู่ใน core Agent (Enabled Checks: [process rtprocess]) และ error ตอนส่งข้อมูล ใน Agent 7.83.3 นี่คือที่ที่รายงานการเก็บ Live Processes ขณะที่ section Process Agent ขึ้นว่า Not running or unreachable ทั้งสองอย่างจริงพร้อมกัน	สถาปัตยกรรมของ Agent
Processing Pipeline	รายการ processor ตามลำดับที่รันหลัง intake กับทุก log ที่ตรง filter ก่อน index ทำหน้าที่ parse และเติมข้อมูล ไม่ได้ตัดสินว่าจะเก็บอะไร pipeline สำเร็จรูปตาม source ถูกแนบอัตโนมัติจาก source: (เช่น java, nginx)	Log Collection and Processing Pipelines
profiler (Continuous Profiler)	การทำ profiling ตลอดเวลาด้วย overhead ต่ำ ครอบคลุมเวลา CPU, wall time และ allocation ระดับฟังก์ชัน ผูกกับ service, endpoint และ trace พิสูจน์ในเครื่องด้วย DD_PROFILING_EXPORTERS=file (Node) และ DD_PROFILING_OUTPUT_PPROF (Python) trace บอกว่า span ไหน ส่วน profiler บอกว่าฟังก์ชันไหน	Continuous Profiler และ Error Tracking

R

Term	ความหมาย	บทเรียน
rate_by_service	map ของอัตรา sampling (ต่อ service:...,env:...) ที่ Agent ส่งกลับให้ tracer ในผลตอบกลับของการ flush trace แต่ละครั้ง เป็นคำแนะนำ ไม่ใช่การบังคับ: เป้า 10 trace ต่อวินาทีเทียบกับที่ส่ง 100 บรรจบที่ 0.1 หลังราว 10 วินาที แต่ Agent ก็ยังส่งต่อทั้ง 720 trace ที่ priority 1	Pipeline การ Sampling ของ Trace
Rehydration	index ชั่วคราวของช่วงเวลาที่เลือกจาก Log Archive เพื่อให้ค้นหาใน Logs Explorer ได้ archive จำกัดด้วย rehydration_max_scan_size_in_gb และ rehydration_tags ส่วน Archive Search เป็นทางเลือกที่ไม่ต้อง reindex และคิดเงินตามข้อมูลที่สแกน	Log-Based Metrics and Logging without Limits
remote agent	component ที่ลงทะเบียนกับ core Agent ผ่าน gRPC bus ภายในและรายงานตัวใน agent status (2 remote agent(s) registered: Agent Data Plane กับ Security Agent ใน container ที่วัด) เป็นวิธีที่ process แยกปรากฏว่ายังทำงานอยู่โดยไม่ต้องเป็น check	สถาปัตยกรรมของ Agent
Remote Configuration	ช่องทางที่การเปลี่ยนแปลงฝั่ง backend (เช่น อัตรา sampling ใน Ingestion Control) ไปถึง tracer ผ่าน Agent ต้องใช้ Agent 7.41.1 ขึ้นไปตามเอกสาร	Pipeline การ Sampling ของ Trace
renotify_interval	จำนวนนาทีระหว่างการแจ้งซ้ำขณะที่ monitor ยังลั่นอยู่ ใช้คู่กับ escalation_message เพื่อเปลี่ยนข้อความ	Monitor Types และ Thresholds, Composite Monitor และ Notification Workflow
restricted_roles / RBAC	ID ของ role ที่จำกัดว่าใครแก้ monitor ได้ (ใน Terraform id ของ permission เป็น ID ไม่ใช่ชื่อ) ใน Log Management สิทธิ์ logs_modify_indexes เป็นสิทธิ์มอบอำนาจแบบ global (สร้าง index, เปลี่ยน routing และ retention, ให้สิทธิ์ exclusion filter) จึงเป็นการควบคุมต้นทุนด้วย ไม่ใช่แค่การเข้าถึง	Composite Monitor และ Notification Workflow, Security และ Compliance เบื้องต้น, AI bug catalog
retention filter (APM)	กฎฝั่ง server (filter_type: spans-sampling-processor) ที่มีสองตัวปรับอิสระ: rate สำหรับ span ที่ตรง และ trace_rate สำหรับทั้ง trace ที่มี span นั้น ใช้ตามลำดับ เก็บ 15 วันตามเอกสาร ชื่อคลาสของ model ไม่ตรงกับ spec (มีการแก้ชื่อจริงในบทเรียน)	Ingestion Sampling เทียบกับ Retention Filters, Pipeline การ Sampling ของ Trace
retry queue (forwarder)	คิวในหน่วยความจำที่ forwarder เก็บ payload ที่ล้มเหลวพร้อม backoff (forwarder_backoff_max, 64 วินาที) จำกัดด้วย forwarder_retry_queue_payloads_max_size (15 MiB) ส่วนที่ล้นถูกนับใน Dropped ซึ่งเป็นตัวเลขที่ต้องดูเมื่อข้อมูลหาย และเมื่อปิด on-disk storage การ restart จะล้างคิว	สถาปัตยกรรมของ Agent
review checklist	ชุดคำถามใช่/ไม่ใช่หนึ่งหน้าเจ็ดกลุ่มสำหรับรีวิว config และโค้ด instrumentation ของ Datadog แต่ละข้อลิงก์ไปยังรายการในแคตตาล็อกและเครื่องมือที่พิสูจน์ได้ รวมถึงสิ่งที่เครื่องมือออฟไลน์มองไม่เห็น	Review checklist, AI bug catalog
RUM (Real User Monitoring)	SDK ภายใน browser หรือแอปมือถือที่ส่ง event แบบ session, view, action และ error จากผู้เข้าชมจริง sessionSampleRate ค่าเริ่มต้นคือ 100 ต่างจาก Synthetics ที่เป็น probe ตามสคริปต์	RUM และ Real User Context, Datadog คืออะไร

S

Term	ความหมาย	บทเรียน
s6-supervise	ตัวคุม process ของ container มีหนึ่ง entry ต่อ component ของ Agent (agent, trace, process, security, sysprobe, data-plane) s6-svstat แสดงสถานะแต่ละ service และ down (exitcode 0) คือการออกแบบเงียบ ๆ ตามปกติ (component ไม่มีงานทำ) ไม่ใช่ crash	สถาปัตยกรรมของ Agent
sampling priority (_sampling_priority_v1)	ค่าบน root span ที่ส่งต่อการตัดสินของ head sampling: -1 user reject, 0 auto reject, 1 auto keep, 2 user keep trace ที่ถูก reject (-1 หรือ 0) ยังถูกส่งไปที่ Agent (มาถึงครบ 40 จาก 40) การตัดสินของ tracer จึงประหยัดงานก็ต่อเมื่อ trace ถูกทิ้งด้วย	Pipeline การ Sampling ของ Trace
Security Agent	process ทางเลือกของ Agent สำหรับ Cloud Security (compliance และ runtime security) จบการทำงานด้วยรหัส 0 อย่างปกติเมื่อไม่ได้เปิดทั้งสองอย่าง ถือว่าว่าง ไม่ใช่ crash	Datadog Agent กับ Integration, สถาปัตยกรรมของ Agent
Sensitive Data Scanner	ค้นหา pattern (เลขบัตร, API key, PII, regex เอง) ใน log, APM span, RUM event และ event ศัพท์ใน Terraform ต่างจาก UI: text_replacement.type เป็น hash, replacement_string ฯลฯ ไม่มี redact และสิทธิ์ unmask (data_scanner_unmask) สำคัญพอ ๆ กับตัวกฎ	Security และ Compliance เบื้องต้น
Service Catalog / Software Catalog	คำนิยามที่คุณประกาศเกี่ยวกับ service โดยไม่ขึ้นกับ telemetry: metadata.owner, spec.dependsOn, datadog.codeLocations เอกสารและ UI เรียกว่า Software Catalog ด้วย ข้อควรระวัง: apiVersion: v3 กับรูปแบบ v2.1 เก่าเข้ากันไม่ได้เชิงโครงสร้าง และ Terraform provider ที่ pin ไว้ยังคาดหวัง v2.1	Service Catalog กับ Ownership, Datadog คืออะไร, AI bug catalog
Service Map	กราฟสดของเส้นเชื่อมระหว่าง service สร้างจาก span ที่ลูกมี service ต่างจากพ่อ อัปเดตตัวเองจากทราฟฟิก ขอบที่ประกาศด้วย spec.dependsOn ปรากฏใน Catalog ได้แม้ไม่มี span ข้ามผ่านเลย	Traces, Spans, and the Service Map, Service Catalog กับ Ownership
Session Replay	การสร้างซ้ำระดับพิกเซลของ session ใน RUM ต้องเปิดเอง (sessionReplaySampleRate ค่าเริ่มต้น 0) และ defaultPrivacyLevel ค่าเริ่มต้นคือ mask-user-input แต่โครงสร้าง DOM และข้อความที่ไม่ใช่ input ยังถูกบันทึก	RUM และ Real User Context
SET	type ของ DogStatsD (s) ที่นับค่าที่ไม่ซ้ำ เช่น ผู้ใช้ที่ไม่ซ้ำ การรวมฝั่ง client ยุบ 1,000 sample ที่มี 7 สมาชิกที่ต่างกันเหลือ 7 บรรทัด	Custom Metrics ด้วย DogStatsD, DogStatsD กับ Aggregation
setUser	คำเรียกของ RUM ที่แนบบริบท @usr ให้ event หลังจากนั้น รูปแบบปัจจุบันต้องมี id ส่วนแบบไม่มี id เลิกใช้แล้ว	RUM และ Real User Context
SLO (metric, monitor, time slice)	เป้าหมาย เช่น 99.9% ใน 30 วัน มีสามชนิด: metric-based (ดีต่อทั้งหมด), monitor-based (uptime ของ monitor), time slice (query อยู่ในเกณฑ์ในแต่ละช่วงหรือไม่) thresholds เป็น field บังคับทุกชนิด	SLO, Error Budget และ Burn Rate Alert
Software Catalog	ดู Service Catalog	Service Catalog กับ Ownership
span	หน่วยงานหนึ่งหน่วยที่มี name, resource, เวลาเริ่ม, ระยะเวลา, service และ parent_id span ที่ไม่มีพ่อคือ root span meta เก็บ tag แบบสตริง ส่วน metrics เก็บตัวเลข	Traces, Spans, and the Service Map
span evidence tags (_dd.rule_psr, _dd.limit_psr, _dd.agent_psr, _dd.p.dm)	tag ที่แต่ละ gate ของ sampling ทิ้งไว้บน root span: _dd.rule_psr (อัตราของ rule), _dd.limit_psr (rate limiter), _dd.agent_psr (อัตราจาก Agent) และ _dd.p.dm (กลไกที่ตัดสิน: -0 ค่าเริ่มต้น, -1 อัตราจาก Agent, -3 rule, -4 manual, -9 probabilistic sampler ของ Agent) ส่วน _sampling_priority_v1 เก็บ priority ที่ได้	Pipeline การ Sampling ของ Trace, Ingestion Sampling เทียบกับ Retention Filters
synthetic monitoring	การตรวจตามสคริปต์และตามตารางเวลาจากเครือข่าย location ของ Datadog (API test และ Browser test) ความล้มเหลวทำให้ synthetics alert monitor ทำงาน ซึ่งใช้ threshold, mention, escalation และ Downtime แบบเดียวกับ monitor อื่น	Synthetics และ Uptime Check, Datadog คืออะไร

T

Term	ความหมาย	บทเรียน
tag	label แบบ key:value บน metric, log และ trace จำกัดที่ 200 ตัวอักษร และการแปลงเป็นตัวพิมพ์เล็กกับการแทนอักขระเกิดที่ backend ของ Datadog ไม่ใช่ใน Agent key ที่สงวนไว้คือ host, env, service, version	Tag กับ Unified Service Tagging
target_traces_per_second	ค่าตั้งของ Agent (DD_APM_TARGET_TPS, ค่าเริ่มต้น 10) คำนวณอัตรา sampling แล้วแนะนำ tracer ผ่าน response rate_by_service ไม่ได้ทิ้ง trace ที่ head sampling เก็บไว้แล้ว: เข้า 720 ออก 720 ใช้แทน max_traces_per_second ที่เลิกใช้	Pipeline การ Sampling ของ Trace, Ingestion Sampling เทียบกับ Retention Filters
template conditionals ({{#is_alert}})	บล็อกในข้อความของ monitor ที่เปลี่ยนข้อความตามสถานะ: {{#is_alert}}, {{#is_warning}}, {{#is_recovery}}, {{#is_no_data}}, {{#is_renotify}}, {{#is_priority 'P1'}} ทุกอันต้องมีแท็กปิดคู่กัน	Composite Monitor และ Notification Workflow
Terraform provider (datadog)	provider DataDog/datadog เวอร์ชัน 4.22.0 ที่ pin ในคอร์สนี้ ตรวจด้วย terraform validate คีย์ปลอม และ validate = false การยืนยันตัวตนต่างกันตาม site และ Application key ไปอยู่ใน state จึงต้องถือ state เป็นความลับ	จัดการ Datadog เป็น Code ด้วย Terraform
terraform validate	การตรวจที่จับชื่อ argument, ชนิด block และชนิดค่าที่ผิดกับ provider ที่ pin ไว้ (Unsupported argument, Missing required argument) ให้รันด้วย key ปลอม ตั้ง validate = false ใน provider block และห้าม plan หรือ apply เด็ดขาด มันบอกไม่ได้ว่า query เป็น query ของ Datadog ที่ถูกต้องหรือไม่	Verification tools, Review checklist
TIMER	type ของ DogStatsD (ms) เป็นชื่อเรียกอีกชื่อของ HISTOGRAM ที่ใช้กับเวลาเป็นมิลลิวินาทีตามธรรมเนียม	Custom Metrics ด้วย DogStatsD
trace	การเดินทางของ request หนึ่งตั้งแต่ต้นจนจบ ในรูป tree ของ span ที่มี root คือ span ที่ไม่มีพ่อ trace จะเป็น trace เดียวข้าม service ได้ก็ต่อเมื่อทั้งสองฝั่งตกลงรูปแบบ propagation ตรงกัน	Traces, Spans, and the Service Map, เชื่อม Log เข้ากับ Trace
Trace Agent	binary ของ Agent ที่รับ span จาก tracer ทาง TCP 8126 หรือ Unix socket จัดกลุ่มแล้วส่งไป APM intake รับ OTLP ด้วย และตัวเขียนของมันไม่ผ่าน forwarder ของ core	Datadog Agent กับ Integration, สถาปัตยกรรมของ Agent
trace metrics	จำนวน hit, จำนวน error และ latency ที่คำนวณจากทุก span ที่ถึง Datadog จึงไม่ได้รับผลจาก ingestion sampling หรือ retention filter มีเพียงการเปิด trace ตัวอย่างเฉพาะตัวที่ขึ้นกับชั้นเหล่านั้น compute_stats_by_span_kind ขยายว่า span ใดป้อนสถิติ	Trace Metrics และ DDSketch

U

Term	ความหมาย	บทเรียน
UDS (Unix domain socket)	transport ของ DogStatsD ที่ผูกกับ filesystem นับแยกเป็น Uds Packets ข้าง Udp Packets UDP ไม่มี connection และไม่มีการยืนยันตัวตน และต้องเปิด dogstatsd_non_local_traffic จึงเข้าถึงจากภายนอกได้	Custom Metrics ด้วย DogStatsD
unified service tagging	การตั้ง env, service และ version ให้เหมือนกันบน metric ของ Agent, span ของ tracer และ log injection เพื่อให้สามผลิตภัณฑ์ join กันด้วยตัวตนเดียว บน Kubernetes ใช้ label tags.datadoghq.com/* ทั้งบน workload และ pod template ส่วน Docker ใช้ com.datadoghq.tags.* ข้อควรระวัง: ตัวพิมพ์ใหญ่เล็กไม่ตรงกันทำให้ join แตกเงียบ ๆ	Tag กับ Unified Service Tagging, Unified Service Tagging ในทางปฏิบัติ, Production Rollout Checklist
_unparsed (client models)	constructor ของ datadog-api-client ไม่บังคับค่า enum ดังนั้น Monitor(type="metrics alert") สร้างได้ ตัว deserializer ตั้ง _unparsed = True เมื่อ enum หรือ oneOf ไม่ตรง ซึ่งเป็นสัญญาณที่แรงกว่าและ harness ไม่ได้ใช้ ข้อควรระวัง: ผ่านการเช็ก model ไม่ได้แปลว่า payload ถูกต้อง	AI bug catalog, Review checklist

W

Term	ความหมาย	บทเรียน
Watchdog	การตรวจจับความผิดปกติโดยไม่ต้องตั้งค่าบน telemetry ที่มีอยู่ ไม่ใช่ monitor ที่คุณสร้างเอง	Monitor Types และ Thresholds
Workload Protection	ด้านรันไทม์ของ Cloud Security: กฎบนกิจกรรมของ process, ไฟล์ และเครือข่ายบน host, container และ Kubernetes จับเหตุ เช่น container เปิด shell ที่ไม่คาดคิด	Security และ Compliance เบื้องต้น

Mark as complete