المقدمة

إذا كان عندنا Monitoring... ليه لسه بنتكلم عن Observability؟ 📈

بعد ما بدأنا نبني أنظمة أكبر وأكثر تعقيدًا، بقى عندنا Dashboards في كل مكان.

بنراقب:

  • CPU
  • Memory
  • Disk
  • Network
  • وعدد الطلبات (Requests)

ولو كل المؤشرات باللون الأخضر...

بنفترض إن كل حاجة تمام.

لكن هل ده معناه إن المستخدم فعلًا بيستمتع بتجربة كويسة؟

مش دائمًا.

تخيل إن تطبيقك بيستقبل 100 ألف طلب في الدقيقة.

وفجأة المستخدمين اشتكوا إن الخدمة بقت بطيئة.

بصيت على الـ Dashboard...

  • CPU طبيعي.
  • Memory طبيعية.
  • Disk طبيعي.
  • حتى الـ Pods كلها Running.

يبقى المشكلة فين؟

الحقيقة إن Monitoring بيجاوب على الأسئلة اللي أنت توقعتها مسبقًا.

يعني لو حددت Alert يقول:

"لو الـ CPU وصل 90% ابعت تنبيه."

فالـ Monitoring هيبلغك فعلًا.

لكن...

إيه لو المشكلة مش في الـ CPU أصلًا؟

إيه لو Service معينة بقت بترد أبطأ؟

أو فيه مشكلة في الاتصال بين خدمتين؟

أو فيه عدد قليل من الطلبات بيفشل، لكنه بيأثر على المستخدمين؟

هنا بيظهر دور Observability.

Observability مش مجرد Dashboard جديدة.

هي القدرة على فهم سبب المشكلة من خلال البيانات اللي بيجمعها النظام.

وغالبًا بيعتمد على ثلاث ركائز أساسية:

📊 Metricsلمعرفة "ماذا يحدث؟"

📝 Logsلمعرفة "ماذا حدث بالتفصيل؟"

🔗 Tracesلمتابعة رحلة الطلب (Request) بين الخدمات المختلفة ومعرفة أين حدث التأخير أو الخطأ.

💡 تخيلها بالشكل ده...

Monitoring يشبه عداد السيارة.

يعرفك السرعة، ودرجة حرارة المحرك، ومستوى الوقود.

لكن لو لمبة المحرك نورت...

العداد هيقولك إن فيه مشكلة.

مش هيقولك سببها.

أما Observability...

فهو أشبه بفتح غطاء المحرك، وتتبع سبب المشكلة خطوة بخطوة حتى تصل إلى مصدرها.

💡 الخلاصة

Monitoring يخبرك أن هناك مشكلة.

Observability تساعدك على فهم لماذا حدثت المشكلة.

والأنظمة الحديثة لا تعتمد على أحدهما دون الآخر...

بل تحتاج الاثنين معًا.

🚀 في المقال القادم...

إذا كانت Observability مهمة لهذه الدرجة...

ليه تعتبر الـ Logs من أهم الأصول في أي نظام؟ وهل كتابة Log كويس مهارة فعلًا؟