ابدأ ، وليس من الأسفل لأعلى من البنية التحتية. أفضل جهاز خادم موثوق لا قيمة له إذا كانت الطلبات تفشل، لذا ابدأ بـ الموجهة للمستخدم — ، ، — ثم أضف الإشارات الأربع الذهبية، ثم مقاييس البنية التحتية أخيراً.
ابدأ ، وليس من الأسفل لأعلى من البنية التحتية. أفضل جهاز خادم موثوق لا قيمة له إذا كانت الطلبات تفشل، لذا ابدأ بـ الموجهة للمستخدم — ، ، — ثم أضف الإشارات الأربع الذهبية، ثم مقاييس البنية التحتية أخيراً.
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)
إذا راقبت وحدة المعالجة المركزية والقرص فقط (من الأسفل لأعلى)، يمكن أن تكون أخضر بالكامل بينما يحصل المستخدمون على 500s. مراقبة SLIs أولاً (من الأعلى لأسفل) تعني أنك تنبه على الأعراض التي يشعر بها المستخدمون فعلاً، ثم تحفر في الإشارات الذهبية والبنية التحتية للعثور على السبب.
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% لكنها لا تخبرك أن العملاء لا يستطيعون الدفع. البدء من SLIs الموجهة للمستخدم يربط كل لوحة تحكم وتنبيه بتأثير المستخدم الحقيقي، يحافظ على الضوضاء منخفضة، ويعطي مسار حفر واضح (العرض → الإشارة الذهبية → سبب البنية التحتية) عندما ينقطع شيء ما.