الموثوقية والإتاحة والمرونة

المراقبة والتسجيل والتنبيه

18 دقيقة الدرس 8 من 10

المراقبة والتسجيل والتنبيه

لا يمكنك إصلاح ما لا تراه. حين يتدهور نظام إنتاجي في الساعة الثانية صباحاً، تحدد الركائز الثلاث للـقابلية للرصد (Observability) — المقاييس والسجلات والتتبعات — ما إذا كان مهندس المناوبة يستعيد الخدمة في خمس دقائق أو خمس ساعات. القابلية للرصد ليست رفاهية تُضيفها بعد الإطلاق؛ إنها متطلب تصميمي من الدرجة الأولى، بنفس أهمية التكرار أو التحويل التلقائي للفشل.

الركائز الثلاث للقابلية للرصد

مصطلح "قابلية الرصد" مأخوذ من نظرية التحكم: نظام قابل للرصد إذا أمكنك استنتاج حالته الداخلية من مخرجاته الخارجية فحسب. في هندسة الأنظمة الموزعة، يترجم هذا إلى ثلاثة أنواع تكميلية من البيانات، كل منها يجيب على سؤال مختلف:

المقاييس (Metrics) — ما الذي يحدث الآن؟ بيانات سلاسل زمنية رقمية مجمَّعة عبر الزمن (مثل معدل الطلبات ومعدل الأخطاء واستخدام المعالج وزمن الاستجابة عند النسبة p99).
السجلات (Logs) — ماذا حدث بالضبط؟ سجلات غير قابلة للتعديل مُوقَّتة لأحداث منفردة (مثل طلب HTTP واحد أو استعلام قاعدة بيانات أو تتبع مكدس استثناء).
التتبعات (Traces) — لماذا هو بطيء أو معطوب؟ سجلات شاملة لرحلة طلب واحد عبر خدمات متعددة، تُظهر أين أُمضي الوقت وأين وقعت الأخطاء.

فكرة رئيسية: تُخبرك المقاييس أن شيئاً ما خاطئ. تُخبرك السجلات بما حدث. تُخبرك التتبعات بالمكان والسبب. تحتاج إلى الثلاثة جميعاً؛ إنها تكاملية لا بديلة عن بعضها.

تُغذّي الركائز الثلاث للقابلية للرصد منصة موحدة تدعم لوحات المعلومات والتنبيهات والتحقيق في الحوادث.

الركيزة الأولى: المقاييس

المقاييس رخيصة التخزين وسريعة الاستعلام ومثالية للوحات المعلومات والتنبيهات. إنها أرقام مُجمَّعة مسبقاً — تفقد تفاصيل الأحداث الفردية لكن تكتسب القدرة على استعلام مليارات الأحداث في ميلي ثوانٍ. الإطار المعياري في الصناعة هو أسلوب RED (للخدمات) وأسلوب USE (للموارد):

RED (لكل خدمة): Rate (طلبات/ثانية)، Errors (طلبات فاشلة/ثانية)، Duration (توزيع زمن الاستجابة).
USE (لكل مورد): Utilisation (نسبة الانشغال)، Saturation (عمق الطابور)، Errors (أحداث الأخطاء).

الأرقام الواقعية مهمة. أظهر لوحة Hystrix التابعة لـ Netflix حالات قاطع الدارة في الوقت الفعلي عبر مئات الخدمات المصغرة. يستوعب نظام Monarch الداخلي لـ Google أكثر من تريليون نقطة بيانات مقاييس يومياً عبر أسطولها. بهذا الحجم، يُعدّ اختيار الدقة الزمنية المناسبة أمراً بالغ الأهمية: تخزين البيانات بدقة ثانية واحدة لمدة 13 شهراً يكلف 10 أضعاف تخزينها بدقة دقيقة — تحتفظ معظم الفرق بالبيانات عالية الدقة 15 يوماً ثم تُقلّص الدقة.

المكدس مفتوح المصدر السائد هو Prometheus (استطلاع بالسحب، لغة استعلام PromQL القوية) مع Grafana للتصور. تشمل البدائل المُدارة سحابياً AWS CloudWatch وGoogle Cloud Monitoring وAzure Monitor. تقدم Datadog وNew Relic بدائل SaaS مع تكاملات أوثق.

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

الركيزة الثانية: السجلات

السجل هو تسجيل غير قابل للإلحاق لحدث منفرد. تُقدم السجلات السرد الذي لا تستطيع المقاييس تقديمه: طلب أي مستخدم بالتحديد فشل، وكيف بدا استعلام SQL، وما رسالة الخطأ التي أعادتها واجهة برمجة التطبيقات الخارجية. الاختيار الهندسي الرئيسي هو التسجيل المنظَّم مقابل النص العادي.

سجلات النص العادي (مثل Apache Combined Log Format) مقروءة للإنسان لكنها تتطلب تحليل تعبيرات نظامية هشة للتحليل البرمجي. السجلات المنظَّمة تُصدر كائنات JSON بأسماء حقول متسقة (user_id، trace_id، status_code، duration_ms)، مما يجعلها قابلة للفهرسة والاستعلام بشكل مباشر. افضّل دائماً التسجيل المنظَّم لأنظمة الإنتاج.

// Plain text (hard to parse at scale)
[2024-03-15 14:23:01] GET /api/orders/98 200 142ms user=47391

// Structured JSON (machine-readable, easy to query)
{
  "timestamp": "2024-03-15T14:23:01.342Z",
  "method": "GET",
  "path": "/api/orders/98",
  "status": 200,
  "duration_ms": 142,
  "user_id": 47391,
  "trace_id": "4bf92f3577b34da6"
}

مسار معيارية إدارة السجلات هو مكدس ELK: Elasticsearch (الفهرسة والاستعلام)، Logstash أو Fluentd (الاستيعاب والتحويل)، Kibana (التصور والبحث). بالحجم الكبير (بيتابايت/يوم)، تتحول الفرق إلى مخازن عمودية مثل ClickHouse أو خدمات مُدارة مثل AWS CloudWatch Logs أو Google Cloud Logging أو Datadog Logs.

فخ — التسجيل المفرط أو القاصر: التسجيل المفرط يُغرق التخزين ويجعل استخلاص الإشارة مستحيلاً (تدفق سجلات بمعدل 10 ميغابايت/ثانية عند مستوى DEBUG يُولّد 864 غيغابايت/يوم لكل خدمة). التسجيل القاصر يتركك أعمى أثناء الحوادث. استخدم مستويات السجل بصواب: DEBUG في التطوير فقط، INFO للعمليات الاعتيادية، WARN للشذوذات القابلة للتعافي، ERROR للأعطال التي تستدعي الانتباه. لا تسجّل أبداً البيانات الحساسة (كلمات المرور، المعلومات الشخصية، الرموز) — فذلك يُنشئ تعرضاً للامتثال والأمان.

الركيزة الثالثة: التتبعات الموزعة

في المعمارية الأحادية، من السهل تحديد طلب بطيء: انظر إلى تتبع المكدس. في معمارية الخدمات المصغرة مع 20 خدمة تتعاون على إجراء مستخدم واحد، قد يكون المسبب أي واحدة منها — أو الشبكة بينها. يحل التتبع الموزع هذه المشكلة بنشر trace_id فريد عبر كل استدعاء خدمة، ثم تجميع جدول زمني للنطاقات (مخطط غانت لوقت الاستجابة في كل محطة).

يتكون التتبع من نطاقات (Spans). يسجل كل نطاق وقت البدء والمدة واسم الخدمة واسم العملية وأي أخطاء أو بيانات وصفية لوحدة عمل واحدة. يمثل النطاق الجذر الطلب الذي يواجه المستخدم؛ تمثل النطاقات الفرعية الاستدعاءات اللاحقة (استعلامات قاعدة البيانات، عمليات البحث في الذاكرة المؤقتة، استدعاءات RPC لخدمات أخرى). أدوات مثل Jaeger وZipkin وAWS X-Ray تصور شجرات النطاق هذه.

يوفر مشروع OpenTelemetry (CNCF) حزمة تطوير برامج محايدة للمورد وتنسيق سلكي يُعدَّد مرة واحدة ويُصدَّر إلى أي خلفية (Jaeger وDatadog وHoneycomb وغيرها). إنه يصبح بسرعة معيار الصناعة — اعتمده للأنظمة الجديدة لتجنب الارتباط بمورد واحد.

يُظهر التتبع الموزع مخطط غانت للنطاقات عبر الخدمات. استعلام Postgres البطيء (140 مللي ثانية) مرئي فوراً باعتباره عنق الزجاجة داخل Order Service.

التنبيه: من الإشارة إلى الإجراء

المقاييس والسجلات مفيدة فقط إذا أُبلغ الأشخاص المناسبون في الوقت المناسب. التنبيه الفعّال أصعب مما يبدو — يعاني معظم الفرق من إرهاق التنبيهات، حيث تُسبب التنبيهات الكثيرة الصاخبة في بدء مهندسي المناوبة بتجاهلها، وهذه أسوأ نتيجة ممكنة.

المبادئ الرئيسية للتنبيه الفعّال:

نبّه على الأعراض لا الأسباب. "معدل أخطاء المستخدم > 1%" هو عرَض (شيء يشعر به المستخدم). "المعالج > 80%" سبب — قد يؤثر على المستخدمين أو لا. نبّه على الأعراض؛ دع كتيبات التشغيل والتتبعات تُحدد الأسباب.
نبّه على معدل استهلاك ميزانية الأخطاء. بدلاً من عتبة ثابتة، نبّه حين تستنزف ميزانية أخطائك بسرعة أكثر مما هو مستدام. إذا كانت ميزانية الأخطاء الشهرية ستنضب في ساعتين بالمعدل الحالي، استدعِ أحدهم فوراً — حتى لو بدا عدد الأخطاء المطلق صغيراً.
كل تنبيه يجب أن يكون قابلاً للتنفيذ. إذا كان الرد على التنبيه "تحقق ولا تفعل شيئاً"، احذف التنبيه. التنبيهات التي لا تملك إجراء استجابة محدداً هي ضوضاء محضة.
ميّز بين الخطورة: إنذار مقابل تذكرة. احتفظ بتنبيهات الإنذار للمشكلات التي تحتاج استجابة بشرية فورية (اختراق SLO وشيك). المشكلات منخفضة الخطورة تذهب إلى قائمة انتظار التذاكر للمعالجة في يوم العمل التالي.

مسارات التنبيه الشائعة: Prometheus Alertmanager → PagerDuty / OpsGenie للإنذار؛ Slack / البريد الإلكتروني للإشعارات منخفضة الخطورة. تتضمن Datadog وGrafana Cloud محركات تنبيه مدمجة.

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

تجميع الصورة: سير عمل التحقيق في الحوادث

حين يُطلق تنبيه، تقود بيانات القابلية للرصد تحقيقاً منظَّماً:

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

هذه الحلقة تُغلق دورة القابلية للرصد. متوسط وقت الكشف (MTTD) في الشركات ذات القابلية للرصد الناضجة هو أقل من 5 دقائق؛ ومتوسط وقت الحل (MTTR) أقل من 30 دقيقة. الشركات بدون قابلية رصد منظَّمة غالباً تشهد MTTD من 30-60 دقيقة وMTTR بالساعات — فرق صارخ في التأثير على العملاء.

مثال واقعي: استمر انقطاع GitHub الكبير عام 2018 لـ 24 ساعة إلى حد بعيد لأن المراقبة الداخلية لم تكن تمتلك تتبعاً موزعاً كافياً لتحديد مصدر الفشل المتسلسل بسرعة. دفع تقرير ما بعد الحادثة باستثمار كبير في أدوات القابلية للرصد. الدرس: البنية التحتية للقابلية للرصد شرط مسبق للحل السريع للحوادث، لا إضافة اختيارية.

الملخص

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