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

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

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: المراقبة والملاحظة والاستجابة للحوادث

خذ الاختبار
نشرة أسبوعية مجانية

ابقَ على مسار النيرد

بريد واحد أسبوعياً — دورات، مقالات معمّقة، أدوات، وتجارب ذكاء اصطناعي.

بدون إزعاج. إلغاء الاشتراك في أي وقت.