เริ่มต้น ไม่ใช่จากล่างขึ้นบนจากโครงสร้างพื้นฐาน ฟลีตโฮสต์ที่เชื่อถือได้มากที่สุดไร้ประโยชน์หากคำขอล้มเหลว ดังนั้นให้เริ่มต้นด้วย ที่หันหน้าไปทางผู้ใช้ — — จากนั้นเพิ่มสี่สัญญาณสีทองแล้วเพิ่มเมตริกโครงสร้างพื้นฐานเป็นอันดับสุดท้าย
เริ่มต้น ไม่ใช่จากล่างขึ้นบนจากโครงสร้างพื้นฐาน ฟลีตโฮสต์ที่เชื่อถือได้มากที่สุดไร้ประโยชน์หากคำขอล้มเหลว ดังนั้นให้เริ่มต้นด้วย ที่หันหน้าไปทางผู้ใช้ — — จากนั้นเพิ่มสี่สัญญาณสีทองแล้วเพิ่มเมตริกโครงสร้างพื้นฐานเป็นอันดับสุดท้าย
1. USER-FACING SLIs → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS → latency, traffic, errors, saturation per service
3. INFRA METRICS → CPU, memory, disk, network (causes, not symptoms)
หากคุณเพียงแค่สังเกตการณ์ CPU และดิสก์ (จากล่างขึ้นบน) คุณอาจเป็นสีเขียวโดยสิ้นเชิงในขณะที่ผู้ใช้ได้รับ 500s การสังเกตการณ์ SLI ก่อน (จากบนลงล่าง) หมายความว่าคุณแจ้งเตือนเกี่ยวกับ อาการที่ผู้ใช้รู้สึกได้จริง จากนั้นคุณลงรายละเอียดของสัญญาณสีทองและโครงสร้างพื้นฐานเพื่อหาสาเหตุ
INSTRUMENT app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
↓
COLLECT a TSDB scrapes/ingests them (Prometheus, Datadog agent)
↓
DASHBOARD visualize SLIs + golden signals (Grafana) for humans to read
↓
ALERT fire on SLO violations / burn rate, routed to on-call
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
กำหนด SLO สำหรับ SLI แต่ละอัน (เช่น 99.9% ความพร้อมใช้งาน p99 < 300ms) แดชบอร์ดพวกเขา และแจ้งเตือนเมื่อ SLO มีความเสี่ยง — ไม่ใช่ในทุกความผันผวน
การติดตามสร้างขึ้นจากล่างขึ้นบนจะบอกคุณว่าดิสก์เต็ม 80% แต่ไม่บอกว่าลูกค้าไม่สามารถเช็คเอาต์ได้ การเริ่มต้นด้วย SLI ที่หันหน้าไปทางผู้ใช้จะเชื่อมโยงแดชบอร์ดและการแจ้งเตือนแต่ละรายกลับไปยังผลกระทบของผู้ใช้ที่แท้จริง ลดเสียงรบกวน และให้เส้นทางการวิเคราะห์ลงเชิงที่ชัดเจน (อาการ → สัญญาณสีทอง → สาเหตุโครงสร้างพื้นฐาน) เมื่อมีบางอย่างขัดข้อง