Agent-Collected Metrics และ Checks
ใจความสำคัญในหนึ่งประโยค
หัวข้อที่มีชื่อว่า “ใจความสำคัญในหนึ่งประโยค”metric ทุกตัวที่ขึ้นบน host ใน Datadog มาจากสองทาง คือ core check ของ Agent ที่เก็บอัตโนมัติ หรือ integration check ที่เรียก check API method ชุดหนึ่งตาม collection interval คงที่
Built-in system metrics
หัวข้อที่มีชื่อว่า “Built-in system metrics”ทันทีที่ Agent start จะรัน core check กลุ่มหนึ่งโดยไม่ต้อง config อะไรเลย เช่น cpu, memory, disk, network, io และอื่น ๆ อีกไม่กี่ตัว สิ่งเหล่านี้คือที่มาของ metric ที่เห็นบน host dashboard ทันทีโดยไม่ต้องติดตั้งอะไรเพิ่ม เช่น system.cpu.user, system.cpu.system, system.mem.used, system.mem.free, system.disk.used, system.net.bytes_rcvd เป็นต้น นี่คือเหตุผลที่ Agent ที่เพิ่งติดตั้งใหม่มี data ไหลเข้ามาแล้วก่อนที่จะไป config integration ตัวไหนเลยด้วยซ้ำ — ภาพรวมระดับ host มีให้อยู่แล้วเสมอ
นอกจาก core check แล้ว Agent ยังมาพร้อม integration ต่าง ๆ ที่เป็น Python check เฉพาะเทคโนโลยี เช่น postgres, redis, nginx, kafka และอีกหลายร้อยตัว integration check จะ active ก็ต่อเมื่อมี config file ให้ check นั้น (ปกติอยู่ที่ conf.d/<integration>.d/conf.yaml) แล้ว Agent detect เจอ config นั้นในรอบ check ถัดไป การเปิด integration postgres เป็นตัวอย่าง คือสิ่งที่ทำให้ metric อย่าง postgresql.connections หรือ postgresql.rows_returned เริ่มปรากฏขึ้นมา — ไม่มี auto-discovery ว่า “มี postgres รันอยู่ตรงนี้” ถ้าไม่มี config นั้น
Check API: gauge, count, rate, histogram
หัวข้อที่มีชื่อว่า “Check API: gauge, count, rate, histogram”check ทุกตัวไม่ว่าจะ built-in หรือ integration คือ Python class เล็ก ๆ ที่รันตาม schedule แล้วเรียก method บน self เพื่อส่งค่า นี่คือสี่ verb เดียวกันที่จะเจออีกครั้งใน DogStatsD บทถัดไป
from datadog_checks.base import AgentCheck
class MyServiceCheck(AgentCheck): def check(self, instance): # a point-in-time value, e.g. current connection count self.gauge('myservice.connections.active', 42, tags=['env:prod'])
# an incrementing counter since the last check run self.count('myservice.requests.total', 137, tags=['env:prod'])
# count normalized to "per second" by the Agent self.rate('myservice.errors.rate', 3, tags=['env:prod'])
# distribution of a value observed during this check run self.histogram('myservice.query.duration', 0.045, tags=['env:prod'])gauge— รายงานค่า ณ ขณะนั้น เหมือนเข็มวัดน้ำมัน สนใจแค่ค่าล่าสุดใน interval นั้นcount— รายงานจำนวนดิบที่เกิดขึ้นระหว่างรอบ check นั้น Agent ไม่หารด้วยเวลาให้ ส่งเป็น count ตรง ๆrate— คล้ายcountแต่ Agent หารด้วยเวลาที่ผ่านไประหว่างรอบ run ให้ metric มาถึง Datadog แบบ normalize เป็น per-second แล้วhistogram— รายงาน distribution ของค่าที่เห็นระหว่างรอบ check หนึ่งครั้ง ซึ่ง Agent จะ aggregate แบบ client-side ออกมาเป็น derived metric หลายตัว (average, max, percentile, count) — พฤติกรรม aggregate แบบ client-side นี้จะเจอซ้ำอีกครั้งใน DogStatsD histogram
Collection interval ประมาณ 15 วินาที
หัวข้อที่มีชื่อว่า “Collection interval ประมาณ 15 วินาที”โดย default check ทุกตัวที่ Agent รันจะถูก schedule ที่ collection interval 15 วินาที — Agent ปลุก check ขึ้นมา check นั้นเรียก self.gauge(...) / self.count(...) ฯลฯ ตามที่สังเกตเห็นตั้งแต่รอบก่อนหน้า แล้ว Agent flush ค่านั้นขึ้นไปข้างบน interval นี้ config ได้ต่อ check (min_collection_interval ใน config ของ check นั้น) แต่ 15 วินาทีคือค่า default ที่ควรสมมติไว้ถ้า config ไม่ได้บอกไว้เป็นอย่างอื่น เรื่องนี้สำคัญโดยเฉพาะกับ rate และ count เพราะตัวเลขที่ method สองตัวนี้คำนวณหรือรายงานมีความหมายในบริบท “ตั้งแต่ collection interval รอบก่อน” เท่านั้น การเปลี่ยน interval จึงเปลี่ยนวิธีตีความค่าพวกนั้น ไม่ใช่แค่ความถี่ที่มาถึง
flowchart LR A[Agent process] -->|runs every ~15s| B[Core checks: cpu, memory, disk, network] A -->|runs every ~15s| C[Integration checks: postgres, redis, nginx, ...] B -->|self.gauge / self.rate| D[system.* metrics] C -->|self.gauge / self.count / self.rate / self.histogram| E[integration.* metrics] D --> F[Datadog backend] E --> F