การสังเกตการณ์อยู่บน เสาสามต้น — บันทึก เมตริก และ การติดตาม — และเป้าหมายคือตอบ "อะไรผิดปกติและเพราะเหตุใด" สำหรับระบบที่ใหญ่เกินไปที่จะตรวจสอบด้วยมือ ในระดับใหญ่ กลยุทธ์นี้เกี่ยวกับความสัมพันธ์ การสุ่มตัวอย่าง และต้นทุน
การสังเกตการณ์อยู่บน เสาสามต้น — บันทึก เมตริก และ การติดตาม — และเป้าหมายคือตอบ "อะไรผิดปกติและเพราะเหตุใด" สำหรับระบบที่ใหญ่เกินไปที่จะตรวจสอบด้วยมือ ในระดับใหญ่ กลยุทธ์นี้เกี่ยวกับความสัมพันธ์ การสุ่มตัวอย่าง และต้นทุน
| เสา | ตอบคำถาม | เครื่องมือ |
|---|
| เมตริก | มีบางอย่างผิดปกติหรือไม่ (อัตรา ความหน่วง) | Prometheus, Grafana |
| การติดตาม | อยู่ที่ไหนในการไหล | OpenTelemetry, Jaeger |
| บันทึก | เกิดอะไรขึ้นจริงๆ | ELK, Loki |
Metrics alert ─▶ trace pinpoints the slow service ─▶ logs explain the cause
(broad) (path) (detail)
รหัสการติดตาม/ความสัมพันธ์ต้องหลัวผ่านเลเบลเมตริก บรรทัดบันทึก และช่วง เพื่อให้คุณสามารถหมุนระหว่างพวกมัน
log line: level=error trace_id=abc123 service=payments msg="gateway timeout"
^^^^^^^^^^^^^^^ same id appears in the trace + metrics
✓ Standardize: OpenTelemetry across all services
✓ Use structured (JSON) logs — queryable, not grep-only
✓ Sample traces (e.g. keep all errors + 1% of success) to control cost
✓ Define SLOs and alert on symptoms (latency/error rate), not noise
✓ RED/USE method for dashboards (Rate, Errors, Duration)
การบันทึกทุกอย่างที่ 100% นั้นไม่สามารถบรรเทาได้และจมสัญญาณ ตัวอย่าง โครงสร้าง และเตือนเกี่ยวกับ SLO แทน
ด้วยบริการหลายร้อยแห่ง คุณไม่สามารถ SSH เข้าและดู — การสังเกตการณ์เป็นวิธีเดียวที่จะเข้าใจพฤติกรรมการผลิต
กลยุทธ์ที่ชนะคือความสัมพันธ์ สุ่มตัวอย่าง และขับเคลื่อนด้วย SLO: มันยืดปัญหาจริงอย่างรวดเร็วโดยไม่ทำให้คุณล้มละลายในการจัดเก็บเทเลมิเตรีหรือฝังการเรียก ในเสียงรบกวน