أسس قابلية الرصد

المقاييس التي تهم

18 دقيقة الدرس 3 من 28

المقاييس التي تهم

قياس الخدمة أمر سهل. أما معرفة أي المقاييس تخبرك فعلاً بما إذا كانت خدمتك تعمل بشكل صحيح — وأيها مجرد ضجيج — فهو الجزء الصعب. نموذجان ذهنيان متكاملان يقطعان خلال هذا الفوضى: طريقة RED لفهم الخدمات من الخارج إلى الداخل، وطريقة USE لفهم الموارد من الداخل إلى الخارج. يتطابق كلاهما مع إشارات جوجل الذهبية الأربع، التي تعاملها كل فرقة SRE في جوجل باعتبارها الحد الأدنى من لوحة المعلومات لأي خدمة إنتاجية.

وُلدت هذه الأطر من تجربة مؤلمة. قبلها، كانت الفرق تقيس عشرات المقاييس الداخلية العشوائية ثم تحدق في مئات لوحات Grafana خلال الحوادث، غير قادرة على الإجابة عن السؤال الوحيد المهم: هل هذه الخدمة تعمل للمستخدمين الآن؟

طريقة RED — الخدمات من الخارج إلى الداخل

RED اختصار لـ Rate (المعدل) وErrors (الأخطاء) وDuration (المدة). صاغها Tom Wilkie في Grafana Labs، وهي الإطار الصحيح لأي خدمة تعالج طلبات — HTTP APIs وخدمات gRPC ومستهلكو الرسائل واستعلامات قواعد البيانات.

Rate (المعدل) — كم طلباً في الثانية تستقبل الخدمة؟ هذه إشارة الطلب. إذا انخفض المعدل فجأة، فإما اختفى الحمل (مشكلة في المنبع) أو الخدمة ترفض الاتصالات (مشكلتك).
Errors (الأخطاء) — ما نسبة الطلبات الفاشلة؟ تتبع HTTP 5xx وأكواد gRPC غير OK وأخطاء الأعمال على مستوى التطبيق منفصلةً عن أخطاء البنية التحتية. نسبة خطأ 1% تبدو صغيرة؛ بمعدل 10,000 طلب في الثانية هذا يعني 100 طلب فاشل كل ثانية.
Duration (المدة) — كم تستغرق الطلبات؟ دائماً قِس كـ histogram أو summary، وليس مجرد متوسط. p50 يخبرك بما يختبره معظم المستخدمين؛ p99 يخبرك بما يختبره أسوأ 1%؛ p999 يكشف عن توقعات الاستجابة الشاذة التي ستظهر كانتهاكات لـ SLO على نطاق واسع. متوسط الاستجابة يخفي التوزيعات ذات الذروتين بالكامل.

RED موجّهة نحو المستخدم: تجيب هذه الإشارات الثلاث عن "هل الخدمة تؤدي مهمتها من منظور المستخدم؟" لا تقول شيئاً عن السبب. يمكن لخدمة ما أن يكون لها مقاييس RED مثالية بينما تجلس على قرص ممتلئ أو تسرب ذاكرة — إلى أن تتوقف عن ذلك.

Prometheus مع Grafana هي الحزمة المعيارية لـ RED. إعداد scrape بسيط لـ Prometheus واستعلامات PromQL تلتقط الإشارات الثلاث لخدمة Kubernetes:

# prometheus.yml — scrape نقطة نهاية /metrics لتطبيقك
scrape_configs:
  - job_name: 'checkout-service'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: keep
        regex: checkout

---
# PromQL — استعلامات لوحة معلومات RED

# Rate: الطلبات في الثانية (نافذة 5 دقائق)
rate(http_requests_total{job="checkout-service"}[5m])

# Errors: نسبة الطلبات التي أعادت 5xx
sum(rate(http_requests_total{job="checkout-service",status=~"5.."}[5m]))
  /
sum(rate(http_requests_total{job="checkout-service"}[5m]))

# Duration: استجابة النسبة المئوية 99
histogram_quantile(0.99,
  sum by (le) (
    rate(http_request_duration_seconds_bucket{job="checkout-service"}[5m])
  )
)

طريقة USE — الموارد من الداخل إلى الخارج

USE اختصار لـ Utilization (الاستخدام) وSaturation (التشبع) وErrors (الأخطاء). عرّفها Brendan Gregg وهي الإطار الصحيح لكل مورد يستهلكه النظام — المعالجات والذاكرة وإدخال/إخراج القرص وواجهات الشبكة ومجمعات الخيوط ومجمعات اتصالات قواعد البيانات.

Utilization (الاستخدام) — ما النسبة المئوية من الوقت الذي يكون فيه هذا المورد مشغولاً؟ معالج عند 70% استخدام يعني هامش 30%. متحكم في I/O القرص عند 99% استخدام يكاد لا يملك هامشاً. الاستخدام إشارة تخطيط السعة.
Saturation (التشبع) — كم من العمل في الانتظار لأن المورد لا يستطيع المواكبة؟ معالج عند 70% استخدام مع عمق قائمة انتظار تشغيل 4 يكون مشبعاً رغم الاستخدام المعتدل. عمق قائمة الانتظار غالباً ما يكون أقدم إنذار قبل انفجار الاستجابة — تأخر الاستجابة يتأخر عن التشبع بثوانٍ إلى دقائق.
Errors (الأخطاء) — هل يُبلّغ المورد عن أخطاء في الأجهزة أو البرمجيات؟ أخطاء قراءة القرص وفقدان حزم الشبكة وتصحيحات ECC للذاكرة وإعادة إرسال TCP. هذه أخطاء على مستوى المورد، مختلفة عن الأخطاء على مستوى التطبيق في RED.

USE تجد الاختناق: عندما تتدهور إشارات RED ولا تعرف السبب، طبّق USE بشكل منهجي على كل مورد في مسار الطلب — المعالج والذاكرة والقرص والشبكة ومجمعات الاتصال. المورد الأول الذي يُظهر تشبعاً عالياً هو الاختناق في الغالب. يحوّل هذا مكالمة غرفة حرب مدتها 45 دقيقة إلى تشخيص يستغرق 5 دقائق.

Node Exporter يكشف مقاييس موارد Linux لتحليل USE. استعلامات PromQL الرئيسية:

# USE — استعلامات PromQL لـ Node Exporter

# استخدام المعالج: النسبة المشغولة (ليست خاملة) عبر جميع الأنوية
1 - avg by (instance) (
  rate(node_cpu_seconds_total{mode="idle"}[5m])
)

# تشبع المعالج: طول قائمة التشغيل الطبيعية (متوسط الحمل لكل نواة)
node_load1 / count without (cpu, mode) (node_cpu_seconds_total{mode="idle"})

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

# تشبع الذاكرة: نشاط الترحيل (صفحات مبادلة في الثانية)
rate(node_vmstat_pgpgin[5m])

# استخدام I/O القرص: نسبة وقت الجهاز المشغول
rate(node_disk_io_time_seconds_total{device="sda"}[5m])

# تشبع القرص: متوسط طول قائمة انتظار I/O
rate(node_disk_io_time_weighted_seconds_total{device="sda"}[5m])

# أخطاء الشبكة: أخطاء الاستقبال والإرسال في الثانية
rate(node_network_receive_errs_total[5m])
  + rate(node_network_transmit_errs_total[5m])

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

يعرّف كتاب Site Reliability Engineering من جوجل أربع إشارات باعتبارها الحد الأدنى المطلوب لأي خدمة إنتاجية. تتوافق بسلاسة مع RED وUSE:

Latency (الاستجابة) — الوقت المستغرق لخدمة طلب، مع التمييز بين الناجح والفاشل (الخطأ السريع ليس نجاحاً). ← RED Duration
Traffic (حركة المرور) — الطلب على النظام: الطلبات في الثانية، المعاملات في الثانية، الاتصالات النشطة. ← RED Rate
Errors (الأخطاء) — معدل الطلبات الفاشلة، صريحة (HTTP 500) وضمنية (HTTP 200 بحمولة خاطئة). ← RED Errors
Saturation (التشبع) — مدى "امتلاء" الخدمة؛ يركز على الموارد الأكثر تقييداً. الخدمة القريبة من التشبع تتدهور قبل أن يصل الاستخدام إلى 100%. ← USE Saturation

مصيدة الإنتاج — متوسط الاستجابة: avg(http_request_duration_seconds) هو كذبة. توزيع ذو ذروتين حيث 95% من الطلبات تستغرق 5 ms و5% تستغرق 2000 ms يُبلّغ عن متوسط ~105 ms — الذي يبدو جيداً في لوحة المعلومات بينما مئات المستخدمين في الثانية يعانون من انتهاء مهلة ثانيتين. دائماً أنذر على p99 (وغالباً p999 للخدمات عالية الحجم)، وليس على المتوسط. هذا أحد أكثر الأخطاء شيوعاً في لوحات المعلومات التي بناها مهندسون مبتدئون.

RED تغطي الخدمات (المعدل والأخطاء والمدة)؛ USE تغطي الموارد (الاستخدام والتشبع والأخطاء). معاً يتطابقان مع إشارات جوجل الذهبية الأربع.

حدود هذه الأساليب — وما يملأ الفجوة

RED وUSE ليستا شاملتين. هما الحد الأدنى. على نطاق كبير تحتاج أيضاً إلى مقاييس الأعمال — الطلبات في الثانية، ومعدل تحويل الدفع، ومعدل النقر على الإعلانات — لأن الخدمة يمكن أن تبدو بصحة ممتازة على مستوى البنية التحتية بينما تعيد بصمت بيانات خاطئة تدمر نتائج الأعمال. تراقب Stripe معدل نجاح الرسوم كإشارة من الدرجة الأولى جنباً إلى جنب مع مقاييس RED. هذه المقاييس على مستوى الأعمال غالباً ما تكون الوحيدة التي تلتقط أخطاء الصحة الخفية التي تجتاز جميع فحوصات صحة البنية التحتية.

تحتاج أيضاً إلى مقاييس RED للتبعيات: قِس كل استدعاء صادر تقوم به خدمتك — لقواعد البيانات والمخابئ والـ APIs الداخلية ووسطاء الرسائل — بثلاثيته الخاصة من المعدل والأخطاء والمدة. التبعية المتدهورة بصمت هي من أكثر الأسباب الجذرية شيوعاً لتراجع الاستجابة الذي يبدو كأنه خطأ خدمتك لكنه في الحقيقة ليس كذلك.

قاعدة قرار للمقاييس الجديدة: قبل إضافة أي مقياس إلى قاعدة الكود، اسأل: "هل يخبرني هذا المقياس بالمعدل أو الأخطاء أو المدة أو الاستخدام أو التشبع أو نتيجة أعمال؟" إذا كانت الإجابة لا، فالمقياس على الأرجح ضجيج. تبقي هذه القاعدة cardinality تحت السيطرة ولوحاتك قابلة للقراءة.

تطبيق RED وUSE خلال الحوادث

النهج المنهجي للحادث المجهول هو: RED أولاً، ثم USE لإيجاد السبب. ابدأ بتأكيد إشارات RED المتدهورة — هل هي الاستجابة أم الأخطاء أم كلاهما؟ هل المعدل طبيعي أم بدأ العملاء بإعادة المحاولة (ارتفاع في المعدل)؟ بمجرد معرفة العرض، طبّق USE على كل مورد في مسار الطلب حتى تجد التشبع أو الأخطاء. هذا هو النهج المنهجي الذي يميز المهندسين الذين يتعاملون مع الحوادث بهدوء عن المهندسين الذين يتخبطون عشوائياً في لوحات المعلومات.

مثال حقيقي: استجابة p99 لخدمة الطلبات ترتفع إلى 8 ثوانٍ. RED يؤكد تدهور Duration، أخطاء طبيعية، معدل طبيعي. USE على مجمع اتصالات قاعدة البيانات يُظهر تشبعاً — عمق قائمة الانتظار وصل إلى 200 اتصال في الانتظار. السبب الجذري: استعلام بطيء (مُدخل في آخر نشر) يحتجز الاتصالات لمدة 4 ثوانٍ لكل منها، مما يحرم جميع الطلبات الأخرى. الحل: التراجع عن النشر أو إضافة فهرس. بدون إطار USE، كان الفريق سيضيع وقتاً في فحص المعالج والشبكة وإعدادات النشر قبل إيجاد الاختناق الفعلي.