นี่คือ สามเสาของการสังเกตการณ์ซึ่งตอบคำถามต่างๆกัน: เมตริกบอกคุณว่า มีอะไรผิด บันทึกบอกคุณว่า เกิดอะไรขึ้น และการติดตามบอกคุณว่า เวลาหรือข้อผิดพลาดเกิดขึ้นที่ไหน ในการไหลแบบกระจาย
นี่คือ สามเสาของการสังเกตการณ์ซึ่งตอบคำถามต่างๆกัน: เมตริกบอกคุณว่า มีอะไรผิด บันทึกบอกคุณว่า เกิดอะไรขึ้น และการติดตามบอกคุณว่า เวลาหรือข้อผิดพลาดเกิดขึ้นที่ไหน ในการไหลแบบกระจาย
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
เมตริกจะจำกัดคุณให้อยู่ในอาการและช่วงเวลา; การติดตามจะระบุตำแหน่งไปยังบริการหรือการเรียก; บันทึกให้สาเหตุที่แน่นอน การไปที่บันทึกโดยตรงโดยไม่มีเมตริกหมายความว่าการค้นหาแบบตาบอด
เมตริกจะรวมกลุ่มดังนั้นจึงยังคงราคาไม่แพง แม้ในระดับ — เหมาะสำหรับแดชบอร์ดและการแจ้งเตือนที่เปิดอยู่ตลอดเวลา บันทึกและการติดตามต่อเหตุการณ์และราคาแพง ดังนั้นโดยปกติจึง สุ่มตัวอย่าง และค้นหาตามความต้องการระหว่างการสอบสวน
การใช้เสาที่ผิดนั้นเสียเวลา: คุณไม่สามารถแจ้งเตือนได้อย่างมีประสิทธิภาพในบันทึกดิบ (ต่ำเกินไป ราคาแพงเกินไป) และคุณไม่สามารถแก้ไขข้อผิดพลาดของคำขอที่ล้มเหลวโดยเฉพาะจากเมตริกรวมกลุ่ม การรู้ว่าเมตริกตรวจจับ การติดตามระบุตำแหน่ง และบันทึกอธิบายจะให้เส้นทางที่รวดเร็วและสามารถทำซ้ำได้จาก "มีอะไรผิด" ไปจนถึงสาเหตุแท้จริง