المراقبة والملاحظة والاستجابة للحوادث

أساسيات المقاييس والمراقبة

4 دقيقة للقراءة

كل مقابلة SRE ستختبر معرفتك بالمراقبة. دعنا نتقن المفاهيم والأدوات.

الإشارات الذهبية الأربع

كتاب Google SRE يُعرّف أربعة مقاييس حرجة:

الإشارة ما تقيسه مثال
الزمن الوقت لخدمة الطلبات p50، p95، p99 وقت الاستجابة
الحركة الطلب على النظام طلبات في الثانية (RPS)
الأخطاء معدل الطلبات الفاشلة أخطاء 5xx، وظائف فاشلة
التشبع استخدام الموارد استخدام CPU، الذاكرة، القرص

نصيحة للمقابلة: عند سؤالك "كيف ستراقب X؟"، ابدأ بهذه الإشارات الأربع.

طرق USE وRED

طريقة USE (البنية التحتية)

لكل مورد، تحقق من:

  • Utilization: كم يُستخدم (0-100%)
  • Saturation: كم عمل في الطابور
  • Errors: أعداد الأخطاء
CPU:     الاستخدام → متوسط الحمل، %CPU
         التشبع   → طول طابور التشغيل
         الأخطاء  → استثناءات فحص الجهاز

الذاكرة: الاستخدام → المستخدم مقابل الكلي
         التشبع   → استخدام التبديل، أحداث OOM
         الأخطاء  → فشل التخصيص

القرص:   الاستخدام → %المستخدم، عرض نطاق I/O
         التشبع   → وقت انتظار I/O
         الأخطاء  → أخطاء القراءة/الكتابة

طريقة RED (الخدمات)

لكل خدمة:

  • Rate: الطلبات في الثانية
  • Errors: الطلبات الفاشلة في الثانية
  • Duration: الوقت لكل طلب (الزمن)

أساسيات Prometheus

أنواع المقاييس

النوع الوصف مثال
Counter يزيد فقط http_requests_total
Gauge يمكن أن يزيد/ينقص temperature_celsius
Histogram عينات في دلاء request_duration_seconds
Summary المئينات مع الوقت request_latency_seconds

أساسيات PromQL

# معدل الطلبات على 5 دقائق
rate(http_requests_total[5m])

# نسبة معدل الأخطاء
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) * 100

# المئين 95 للزمن
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

# استخدام CPU لكل pod
sum by (pod) (rate(container_cpu_usage_seconds_total[5m]))

# نسبة استخدام الذاكرة
(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)
/ node_memory_MemTotal_bytes * 100

تصميم لوحة Grafana

أفضل الممارسات

┌─────────────────────────────────────────────────┐
│  نظرة عامة على صحة الخدمة                       │
├─────────────────────────────────────────────────┤
│  [RPS] [معدل الأخطاء] [الزمن p99] [التشبع]      │  ← الإشارات الذهبية
├─────────────────────────────────────────────────┤
│  معدل الطلبات        │  معدل الأخطاء            │
│  ████████████████    │  ███░░░░░░░░░           │  ← سلسلة زمنية
├──────────────────────┼──────────────────────────┤
│  توزيع الزمن         │  استخدام الموارد         │
│  [p50] [p95] [p99]   │  CPU | الذاكرة | القرص  │
└─────────────────────────────────────────────────┘

متغيرات اللوحة

# عرّف متغيرات للتصفية
$environment = production، staging، development
$service = api، web، worker
$instance = جميع حالات الخدمة المختارة

# استخدم في الاستعلامات
rate(http_requests_total{env="$environment", service="$service"}[5m])

أفضل ممارسات التنبيهات

بنية التنبيه

# قاعدة تنبيه Prometheus
groups:
- name: service-alerts
  rules:
  - alert: HighErrorRate
    expr: |
      sum(rate(http_requests_total{status=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])) > 0.05
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "تم اكتشاف معدل أخطاء عالٍ"
      description: "معدل الأخطاء {{ $value | humanizePercentage }} لمدة 5 دقائق"
      runbook: "https://wiki/runbooks/high-error-rate"

منع إرهاق التنبيهات

الممارسة لماذا
نبّه على الأعراض، ليس الأسباب المستخدمون يهتمون بالأخطاء، ليس CPU
أضف runbooks قلل متوسط وقت التخفيف
ضع عتبات مناسبة تجنب الإيجابيات الخاطئة
استخدم مدة for امنع التنبيهات المتقلبة
وجّه للفريق الصحيح لا توقظ الأشخاص الخطأ

أسئلة المقابلة

س: "كيف تميز بين مشاكل الزمن والتوفر؟"

المقياس زمن عالٍ توفر منخفض
الطلبات تكتمل ببطء تفشل/تنتهي مهلتها
معدل الأخطاء منخفض (الطلبات تنجح) عالٍ (الطلبات تفشل)
تجربة المستخدم بطيء لكن يعمل معطل
السبب الجذري الخلفية بطيئة، تنافس الموارد الخدمة متوقفة، مشكلة شبكة

س: "تنبيه معدل الأخطاء انطلق. أرشدني خلال التحقيق."

# 1. قيّم التأثير
# تحقق من معدل الأخطاء الحالي والاتجاه
# ما نسبة المستخدمين المتأثرين؟

# 2. حدد النطاق
# أي endpoints تفشل؟
rate(http_requests_total{status=~"5.."}[5m]) by (endpoint)

# 3. تحقق من التغييرات الأخيرة
# نشر في الساعة الأخيرة؟
# تغييرات تكوين؟

# 4. انظر التبعيات
# قاعدة البيانات سليمة؟
# APIs الخارجية تستجيب؟

# 5. تحقق من الموارد
# CPU/الذاكرة/القرص مشبع؟
# تجمعات الاتصالات استُنفدت؟

التالي، سنغطي الأعمدة الثلاثة للملاحظة: المقاييس، السجلات، والتتبعات. :::

اختبار

الوحدة 5: المراقبة والملاحظة والاستجابة للحوادث

خذ الاختبار