أذكرها وكأنها البارحة، ليلة شتاء قارس، والساعة تقترب من الثانية صباحًا. رنين الهاتف الحاد يخترق سكون الليل، وعلى الطرف الآخر صوت زميلي يملؤه التوتر: “أبو عمر، الحقنا! الموقع واقع والزبائن بشتكوا!”. كان ذلك في ذروة موسم التخفيضات، وكل دقيقة توقف تعني خسارة آلاف الدولارات وضياع ثقة المستخدمين.
هرعنا جميعًا، فريق كامل من المهندسين، نحاول فهم ما يجري. السيرفرات تبدو بخير، استهلاك المعالج والذاكرة طبيعي، قواعد البيانات تستجيب… لكن الموقع لا يعمل! قضينا الساعات الثلاث التالية في جحيم لا أتمناه لأحد. كنا كمن يبحث عن إبرة في كومة قش عملاقة، لكن في الظلام الدامس. نُطلق التخمينات واحدًا تلو الآخر: “يمكن الكاش؟”، “جرب اعمل ريستارت للسيرفر الفلاني”، “هل المشكلة من مزوّد الدفع؟”. كل محاولة كانت طلقة في الهواء، تزيد من إحباطنا وتوتر الإدارة.
في النهاية، وبعد ساعات من البحث اليائس، اكتشفنا المشكلة بالصدفة البحتة: خدمة صغيرة ومنسية، مسؤولة عن توليد أرقام الفواتير، دخلت في حلقة لا نهائية بسبب حالة نادرة لم نكن نتوقعها، مما أدى إلى استنزاف “pool” الاتصالات مع قاعدة البيانات ببطء، حتى انهار كل شيء. لم تظهر المشكلة في المقاييس العامة لأنها كانت خبيثة وصامتة.
في تلك الليلة، أقسمتُ أن هذا السيناريو لن يتكرر. كانت أنظمتنا “صناديق سوداء”، نرى مدخلاتها ومخرجاتها، لكن ما يحدث في الداخل كان لغزًا. هنا كانت بداية رحلتي مع مفهوم غيّر طريقة تفكيرنا وبناءنا للأنظمة: المراقبة الاستباقية (Observability).
ما هي الـ Observability؟ ولماذا هي ليست مجرد “Monitoring”؟
كثيرون يخلطون بين المراقبة التقليدية (Monitoring) والمراقبة الاستباقية (Observability)، والفرق بينهما جوهري.
- المراقبة (Monitoring): هي أن تراقب أشياء تعرف مسبقًا أنها قد تتعطل. أنت تضع لوحة عدادات (Dashboard) تعرض لك استخدام المعالج، الذاكرة، ومعدل الأخطاء. هي تخبرك أن هناك مشكلة. مثل ضوء “Check Engine” في سيارتك.
- المراقبة الاستباقية (Observability): هي القدرة على فهم الحالة الداخلية للنظام من خلال بياناته الخارجية. هي لا تخبرك فقط بأن هناك مشكلة، بل تمنحك الأدوات لتسأل لماذا وأين وكيف حدثت المشكلة، حتى لو لم تكن تتوقعها أبدًا. هي تمنحك القدرة على تشخيص سبب إضاءة ضوء “Check Engine” بنفسك وبأدق التفاصيل.
باختصار، المراقبة هي جمع البيانات عن أسئلة معروفة مسبقًا. أما الـ Observability فهي تجهيز نظامك ليجيب عن أسئلة لم تكن تعرف أنك ستحتاج إلى طرحها.
لتحقيق هذه القدرة السحرية، نعتمد على ثلاثة أعمدة رئيسية، أو كما أحب أن أسميها “أركان الفهم الثلاثة”.
أركان الفهم الثلاثة: Logs, Metrics, and Traces
لتتمكن من تشخيص أي عطل، تحتاج إلى رؤية المشكلة من زوايا مختلفة. هذه الأعمدة الثلاثة تمنحك تلك الرؤية الشاملة.
1. السجلات (Logs) – حكواتي النظام
السجلات هي أبسط وأقدم شكل من أشكال المراقبة. هي عبارة عن أحداث فردية مسجلة مع طابع زمني (timestamp). كل سطر في ملف الـ log هو قصة قصيرة يرويها جزء من نظامك.
المشكلة أن السجلات التقليدية غالبًا ما تكون غير منظمة، مما يجعل البحث فيها كابوسًا. هنا يأتي دور السجلات المنظمة (Structured Logging). بدلًا من تسجيل نص عشوائي، نقوم بتسجيل كائنات JSON.
مثال على سجل غير منظم (سيء):
ERROR: Failed to process payment for user 123. Amount: 99.99. Reason: Insufficient funds.
مثال على سجل منظم (ممتاز):
{
"timestamp": "2023-10-27T10:00:00Z",
"level": "error",
"message": "Failed to process payment",
"user_id": "123",
"order_id": "xyz-abc-789",
"amount": 99.99,
"currency": "USD",
"payment_gateway": "Stripe",
"reason": "Insufficient funds"
}
هل ترى الفرق؟ الآن يمكنك بسهولة البحث عن “كل الأخطاء التي حدثت للمستخدم 123” أو “مجموع المبالغ التي فشل دفعها عبر بوابة Stripe”.
نصيحة أبو عمر: لا تسجل الأخطاء فقط! سجل الأحداث الهامة والناجحة أيضًا (مثل تسجيل دخول مستخدم، إتمام عملية شراء). هذه السجلات ستكون منجم ذهب عندما تريد فهم سلوك المستخدمين أو تتبع مشكلة معقدة.
2. المقاييس (Metrics) – نبض النظام
المقاييس هي بيانات رقمية يتم تجميعها على فترات زمنية. هي التي تمنحك النظرة العامة على صحة النظام. فكر فيها كلوحة عدادات الطائرة التي تعرض السرعة والارتفاع وضغط المحرك.
أشهر أنواع المقاييس هي ما يعرف بـ “الإشارات الذهبية الأربع” (The Four Golden Signals):
- الكمون (Latency): كم من الوقت يستغرق نظامك للرد على الطلبات؟
- حجم المرور (Traffic): ما هو حجم الطلب على نظامك (مثلاً، طلبات في الثانية)؟
- الأخطاء (Errors): ما هو معدل الطلبات التي تفشل؟
- التشبع (Saturation): ما مدى “امتلاء” نظامك؟ (مثلاً، كم تبقى من مساحة القرص أو كم هي نسبة استخدام المعالج).
أدوات مثل Prometheus ممتازة لجمع هذه المقاييس، وGrafana رائعة لعرضها في لوحات جميلة ومفهومة.
مثال بسيط لكود Python يعرض مقياسًا لـ Prometheus:
from prometheus_client import start_http_server, Counter
import random
import time
# Create a metric to track requests.
REQUESTS = Counter('http_requests_total', 'Total HTTP Requests', ['method', 'endpoint'])
def process_request(method, endpoint):
"""A dummy function to simulate processing a request."""
REQUESTS.labels(method=method, endpoint=endpoint).inc()
time.sleep(random.random())
if __name__ == '__main__':
# Start up the server to expose the metrics.
start_http_server(8000)
# Generate some requests.
while True:
process_request('get', '/api/users')
process_request('post', '/api/users')
نصيحة أبو عمر: ابدأ بالإشارات الذهبية. لا تغرق نفسك في بحر من المقاييس عديمة الفائدة. لكل خدمة، اسأل نفسك: ما هي المقاييس الأربعة التي تخبرني أن هذه الخدمة “حية وبصحة جيدة”؟
3. التتبعات (Traces) – خريطة رحلة الطلب
هذا هو الركن الأكثر تطورًا وربما الأقوى في عالم الـ Observability، خصوصًا في بيئة الخدمات المصغرة (Microservices).
التتبع يريك قصة حياة طلب واحد وهو ينتقل عبر الخدمات المختلفة في نظامك. تخيل أنك تطلب طردًا من أمازون. التتبع يريك رحلة الطرد من المستودع، إلى مركز الفرز، إلى شاحنة التوصيل، وصولًا إلى باب منزلك.
في عالم البرمجيات، عندما يضغط مستخدم على زر “شراء”، قد يمر طلبه عبر:
- خدمة الواجهة الأمامية (Frontend)
- خدمة المصادقة (Authentication Service)
- خدمة سلة المشتريات (Cart Service)
- خدمة الدفع (Payment Service)
- خدمة الإشعارات (Notification Service)
التتبع (Trace) يربط كل هذه الخطوات معًا بمعرّف فريد (Trace ID). إذا فشل الطلب أو كان بطيئًا، يمكنك أن ترى بالضبط في أي مرحلة حدثت المشكلة وكم من الوقت استغرقت كل خطوة. هذا ينهي لعبة “إلقاء اللوم” بين الفرق!
معايير مثل OpenTelemetry أصبحت هي اللغة المشتركة لجمع التتبعات، وأدوات مثل Jaeger و Zipkin تساعد في عرضها بشكل مرئي.
نصيحة أبو عمر: مفتاح قوة التتبعات هو “السياق” (Context). تأكد من أن الـ `trace_id` يتم تمريره بين كل خدماتك، والأهم من ذلك، قم بإضافته إلى سجلاتك (Logs)! عندما تجد خطأً في السجلات، يمكنك أخذ الـ `trace_id` والبحث عنه مباشرة لترى القصة الكاملة للطلب. هذه هي القوة الحقيقية للـ Observability.
من الصندوق الأسود إلى الصندوق الزجاجي: كيف نطبق هذا عمليًا؟
لو عدنا بالزمن إلى ليلة الحادثة التي رويتها في البداية، ومع وجود نظام Observability جيد، لكان السيناريو مختلفًا تمامًا:
- الإنذار (Metric): نتلقى تنبيهًا بأن مقياس “معدل نجاح إتمام الطلبات” قد انخفض بشكل حاد، أو أن مقياس “الكمون” لخدمة الطلبات ارتفع فوق الحد المسموح.
- التحليل (Logs): ننظر إلى سجلات خدمة الطلبات خلال تلك الفترة. بفضل السجلات المنظمة، نقوم بفلترة الأخطاء ونلاحظ تكرار رسالة خطأ “Timeout while acquiring connection from pool”.
- التشخيص (Traces): نأخذ `trace_id` من أحد السجلات الفاشلة ونضعه في أداة عرض التتبعات (مثل Jaeger). نرى فورًا أن الطلب يقضي 99% من وقته عالقًا في انتظار استدعاء “خدمة توليد الفواتير”.
المشكلة تم تحديدها في 5 دقائق، وليس 3 ساعات. النظام لم يعد صندوقًا أسود غامضًا، بل أصبح صندوقًا زجاجيًا شفافًا يمكننا فهم ما يجري بداخله.
نصائح أبو عمر الذهبية للبدء
- ابدأ صغيرًا: لا تحاول تطبيق كل شيء دفعة واحدة. اختر خدمة واحدة مهمة وابدأ بتطبيق السجلات المنظمة (Structured Logging). هي الأسهل تطبيقًا والأسرع في تحقيق الفائدة.
- الثقافة قبل الأدوات: الـ Observability ليست مجرد أداة تشتريها، بل هي ثقافة وفلسفة يتبناها الفريق. شجع المطورين على التفكير في “كيف سأراقب هذه الميزة؟” أثناء كتابة الكود، وليس بعد إطلاقه.
- استثمر في OpenTelemetry: إنه المستقبل. هو معيار مفتوح المصدر تدعمه كل الشركات الكبرى. استخدامه يحررك من التقيّد بمزوّد خدمة واحد ويجعل نظامك مستعدًا للمستقبل.
– اربط كل شيء ببعضه: السحر الحقيقي يحدث عندما ترتبط الأعمدة الثلاثة. تأكد من أن `trace_id` و `user_id` وأي معرّفات مهمة أخرى موجودة في سجلاتك. هذا يسمح لك بالقفز بسهولة من المقاييس إلى التتبعات إلى السجلات.
الخلاصة النهائية 🚀
يا جماعة، لقد ولّى زمن بناء الأنظمة التي لا نفهمها. الانتقال من المراقبة التقليدية إلى المراقبة الاستباقية (Observability) ليس ترفًا، بل هو ضرورة حتمية في عالم الأنظمة الموزعة والمعقدة اليوم. إنه استثمار في راحة بال فريقك، وفي وقتك، وفي ثقة عملائك.
قد يبدو الأمر معقدًا في البداية، لكن الفائدة التي ستحصل عليها لا تقدر بثمن. ستنام ليلًا بشكل أفضل، وستقضي وقتك في بناء ميزات جديدة بدلًا من مطاردة الأشباح في الظلام.
يلا يا إخوان، خلينا نبني أنظمة بنفهمها، مش أنظمة بتغلبنا.
