المراقبة وإمكانية الملاحظة: أفضل ممارسات APM والتسجيل والتنبيه

** الشركات التي تتمتع بممارسات ناضجة لقابلية المراقبة تعمل على حل الحوادث بشكل أسرع بنسبة 69% وفقًا لتقرير حالة قابلية الملاحظة الخاص بشركة Splunk. ** تخبرك المراقبة بوجود شيء ما معطل. تخبرك إمكانية الملاحظة عن سبب كسرها وأين تبحث. الفرق بين مكافحة كل مشكلة إنتاجية لساعات وحلها في دقائق يعود إلى مدى جودة استخدام أنظمتك، وتنظيم سجلاتك، وتصميم تنبيهاتك.

الوجبات الرئيسية

• الركائز الثلاث لقابلية المراقبة - المقاييس والسجلات والتتبعات - تجيب كل منها على أسئلة مختلفة وتعمل معًا لتوفير فهم كامل للنظام
• تنبيه بشأن الأعراض (التأثير الذي يواجه المستخدم) وليس الأسباب (المقاييس الداخلية) لتقليل إرهاق التنبيه والتقاط أوضاع الفشل الجديدة
• يتيح تسجيل JSON المنظم بمعرفات الارتباط إمكانية البحث عبر الخدمات وإعادة بناء تدفقات الطلبات
• تقوم أهداف مستوى الخدمة (SLOs) بتحويل المراقبة من "هل تم كسر أي شيء" إلى "هل نفي بالتزاماتنا تجاه المستخدمين"

---

الركائز الثلاث لقابلية الملاحظة

تعتمد إمكانية الملاحظة على ثلاثة أنواع من البيانات التكميلية. يجيب كل عمود على أسئلة مختلفة حول سلوك نظامك.

المقاييس

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

الخصائص:

• مجمعة ومدمجة - ملايين الأحداث المضغوطة في عدادات سلاسل زمنية
• رخيصة الثمن للتخزين - بيانات ذات حجم ثابت بغض النظر عن حجم حركة المرور
• مثالية للوحات المعلومات والتنبيه
• سياق محدود - تعلم أن وقت الاستجابة قد زاد ولكن ليس الطلبات المحددة التي تكون بطيئة

أنواع المقاييس الرئيسية:

• العداد - زيادة القيمة بشكل رتيب (إجمالي الطلبات، إجمالي الأخطاء)
• المقياس -- القيمة التي ترتفع وتنخفض (الاستخدام الحالي لوحدة المعالجة المركزية، والاتصالات النشطة)
• الرسم البياني - توزيع القيم (النسب المئوية لوقت الاستجابة، وأحجام الحمولة)
• الملخص--النسب المئوية المحسوبة مسبقًا من جانب العميل

السجلات

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

الخصائص:

• سياق غني - تفاصيل عشوائية حول الأحداث الفردية
• باهظة الثمن على نطاق واسع - تولد الأنظمة ذات حركة المرور العالية غيغابايت من السجلات في الساعة
• قابل للبحث - ابحث عن أحداث محددة باستخدام البحث عن النص الكامل
• يتطلب بنية - يصعب تحليل خطوط السجل غير المنظمة وربطها

آثار

تتبع التتبعات طلبًا واحدًا عبر خدمات متعددة. يجيبون على أسئلة "أين يقضي الوقت": ما هي خدمة الاتصال البطيئة؟ أين يتباعد مسار الطلب؟ ما هو استعلام قاعدة البيانات الذي يمثل عنق الزجاجة؟

الخصائص:

• إظهار السببية - العلاقات بين الوالدين والطفل بين العمليات
• الكشف عن سلوك النظام الموزع - الكمون عبر حدود الخدمة
• أخذ العينات مطلوب على نطاق واسع - فتتبع كل طلب أمر مكلف
• ضروري للخدمات الصغيرة - بدون آثار، يعد تصحيح أخطاء تدفقات الخدمات المتعددة بمثابة تخمين

---

النظام البيئي لأداة المراقبة

اختيار المكدس

بالنسبة لمعظم الشركات المتنامية، نوصي بالبدء بما يلي:

1. Sentry لتتبع الأخطاء - يلتقط الاستثناءات من خلال تتبعات المكدس الكاملة، وخرائط المصدر، وتتبع الإصدار
2. Prometheus + Grafana للمقاييس - نظام بيئي متكامل واسع النطاق ومفتوح المصدر ومُختبر في المعارك
3. ** التسجيل المنظم إلى خدمة مُدارة ** - Datadog Logs، أو AWS CloudWatch، أو Grafana Loki اعتمادًا على موفر السحابة الخاص بك
4. OpenTelemetry للأجهزة - معيار محايد للبائع يعمل مع أي واجهة خلفية

بالنسبة للفرق التي تريد بائعًا واحدًا، توفر Datadog أفضل تجربة شاملة ولكن بتكلفة كبيرة على نطاق واسع. توفر حزمة Grafana مفتوحة المصدر (Prometheus، Loki، Tempo) إمكانات مكافئة بتكلفة ترخيص أقل ولكن مع عبء تشغيلي أعلى.

---

أفضل ممارسات التسجيل المنظم

خطوط السجل غير المنظمة مثل Error processing order 12345 for user [email protected] قابلة للقراءة من قبل الإنسان ولكنها معادية للآلة. تتيح سجلات JSON المنظمة إمكانية البحث والتصفية والتجميع والتنبيه في حقول محددة.

هيكل السجل

يجب أن يتضمن كل إدخال سجل ما يلي:

معرفات الارتباط

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

التنفيذ: أنشئ UUID في بوابة API أو موازن التحميل، وقم بتمريره في الرأس X-Request-ID، وقم بتضمينه في كل إدخال سجل. في NestJS، استخدم برنامجًا وسيطًا يستخرج معرف الارتباط أو ينشئه ويخزنه في سياق التخزين المحلي غير المتزامن.

مستويات السجل

استخدم مستويات السجل باستمرار:

• DEBUG -- معلومات تشخيصية تفصيلية، يتم تعطيلها في الإنتاج ما لم يتم تصحيح الأخطاء بشكل نشط
• معلومات - أحداث تجارية مهمة (تم تقديم الطلب، تسجيل المستخدم، معالجة الدفع)
• تحذير -- مواقف غير متوقعة تعامل معها النظام ولكن يجب التحقيق فيها (نجحت إعادة المحاولة، وفشلت ذاكرة التخزين المؤقت، واستدعاء واجهة برمجة التطبيقات المهملة)
• خطأ -- حالات الفشل التي أثرت على تجربة المستخدم (فشل الطلب، رفض الدفع، الخدمة الخارجية غير متوفرة)
• فادح -- لا يمكن متابعة التطبيق (لا يمكن الوصول إلى قاعدة البيانات، ويفتقد التكوين المطلوب)

الاحتفاظ بالسجل وإدارة التكلفة

السجلات هي بيانات قابلية المراقبة الأكثر تكلفة لتخزينها. تنفيذ الاحتفاظ المتدرج:

• التخزين السريع (30 يومًا) - نص كامل قابل للبحث، واستعلامات سريعة، وتكلفة عالية
• التخزين الدافئ (90 يومًا) - استعلامات مضغوطة وأبطأ وتكلفة معتدلة
• التخزين البارد (سنة واحدة فما فوق) - مؤرشف، الاستعلام عند الطلب، منخفض التكلفة
• سجلات تصحيح الأخطاء -- لا تقم بتخزينها في مرحلة الإنتاج ما لم يتم استكشاف الأخطاء وإصلاحها بشكل فعال

---

تصميم التنبيه

تؤدي التنبيهات السيئة إلى إجهاد التنبيه - تتوقف الفرق عن الاستجابة للتنبيهات لأن معظمها عبارة عن نتائج إيجابية كاذبة أو ضوضاء ذات أولوية منخفضة. يُبرز التنبيه الجيد مشكلات حقيقية تتطلب التدخل البشري.

تنبيه بشأن الأعراض، وليس الأسباب

تنبيه قائم على الأعراض (جيد): "تجاوز معدل الخطأ في /api/الطلبات 1% لمدة 5 دقائق" - يشير هذا بشكل مباشر إلى تأثير المستخدم بغض النظر عن السبب الأساسي.

تنبيه مبني على السبب (سيء): "تجاوزت وحدة المعالجة المركزية لقاعدة البيانات 90%" - قد يؤثر هذا على المستخدمين وقد لا يؤثر. قد تتعامل قاعدة البيانات مع 95% من وحدة المعالجة المركزية بشكل جيد، أو قد تكون عند 50% من وحدة المعالجة المركزية ولكنها في طريق مسدود تمامًا.

تنتمي المقاييس المستندة إلى السبب إلى لوحات المعلومات للتحقيق، وليس في قواعد التنبيه.

مستويات خطورة التنبيه

تقليل ضجيج التنبيه

1. التنبيهات المتعلقة بالمجموعة -- إذا تعطلت قاعدة البيانات، فستحصل على تنبيه واحد "قاعدة البيانات غير متاحة"، وليس 50 تنبيهًا من كل خدمة تعتمد عليها
2. يتطلب انتهاكًا مستمرًا -- "وحدة المعالجة المركزية أعلى من 90% لمدة 5 دقائق" وليس "وحدة المعالجة المركزية أعلى من 90% لمدة ثانية واحدة" لتجنب الارتفاعات العابرة
3. الحل التلقائي - يجب أن يتم مسح التنبيهات تلقائيًا عند حل الحالة
4. مراجعة التنبيهات الأسبوعية -- قم بمراجعة جميع التنبيهات التي تم تشغيلها، وتحديد وإصلاح أو إسكات التنبيهات التي لا تتطلب إجراءً بشريًا
5. حلقة التعليقات عند الطلب -- بعد كل دورة عند الطلب، يقوم المهندس بتوثيق التنبيهات التي كانت قابلة للتنفيذ والتي تحتاج إلى ضبط

---

SLOs: أهداف مستوى الخدمة

تعمل SLOs على تحويل المراقبة من رد الفعل ("حدث عطل، قم بإصلاحه") إلى استباقي ("نحن نستهلك ميزانية الأخطاء لدينا، فلنتحقق قبل أن يلاحظ المستخدمون").

تعريف SLOs

يحدد SLO الموثوقية المستهدفة للخدمة. يتكون من:

• SLI (مؤشر مستوى الخدمة) -- المقياس الذي يتم قياسه (معدل نجاح الطلب، النسبة المئوية لزمن الوصول)
• الهدف -- الحد الذي يحدد الأداء المقبول (معدل نجاح 99.9%، P95 أقل من 200 مللي ثانية)
• النافذة -- الفترة الزمنية التي يتم خلالها تقييم الهدف (30 يومًا)

مثال على SLOs لمنصة التجارة الإلكترونية

ميزانيات الخطأ

ميزانية الخطأ هي عكس هدف SLO الخاص بك. يسمح SLO بنسبة 99.9% بأخطاء بنسبة 0.1% - ما يقرب من 43 دقيقة من وقت التوقف عن العمل شهريًا. عند استنفاد ميزانية الخطأ، يحول الفريق التركيز من الميزات إلى العمل الموثوق.

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

---

الأسئلة المتداولة

ما هي تكلفة إمكانية الملاحظة على نطاق واسع؟

تتراوح تكاليف إمكانية المراقبة من 10 إلى 50 دولارًا أمريكيًا لكل مضيف شهريًا للمجموعات مفتوحة المصدر (Prometheus، Grafana، Loki) إلى 30-100 دولارًا أمريكيًا لكل مضيف للحلول التجارية (Datadog، New Relic). أكبر محرك للتكلفة هو حجم السجل - قم بالتحسين عن طريق أخذ عينات من سجلات تصحيح الأخطاء، وضغط السجلات المخزنة، وتعيين فترات الاحتفاظ المناسبة. بالنسبة لمعظم الشركات التي يقل عدد خوادمها عن 50 خادمًا، تتراوح التكلفة بين 500 و2000 دولار شهريًا.

هل يجب أن أستخدم OpenTelemetry أو وكلاء خاصين بالموردين؟

استخدم القياس عن بعد المفتوح. إنه معيار الصناعة للأجهزة، ويدعمه كل بائع رئيسي لقابلية المراقبة، ويمنع تقييد البائع. يمكنك تبديل الواجهات الخلفية (من Datadog إلى Grafana، على سبيل المثال) دون إعادة استخدام التعليمات البرمجية الخاصة بك. يقدم الوكلاء الخاصون بالموردين أحيانًا تكاملًا أعمق، لكن مقايضة قابلية النقل لا تستحق العناء.

كيف أقوم بإعداد المراقبة لتطبيق NestJS؟

في NestJS، استخدم أدوات الاعتراض لتوقيت الطلب، ومرشحات الاستثناءات لتتبع الأخطاء، والبرامج الوسيطة لنشر معرف الارتباط. قم بدمج Sentry مع @sentry/nestjs لتتبع الأخطاء. قم بتصدير مقاييس Prometheus باستخدام مكتبة prom-client المعروضة على نقطة نهاية /metrics. استخدم التسجيل المنظم مع nestjs-pino أو winston الذي تم تكوينه لمخرجات JSON.

ما الفرق بين المراقبة وإمكانية الملاحظة؟

تخبرك المراقبة عندما تسوء الأمور المحددة مسبقًا (وحدة المعالجة المركزية عالية، معدل الخطأ مرتفع، القرص ممتلئ). تتيح لك إمكانية الملاحظة طرح أسئلة جديدة حول سلوك النظام دون نشر أدوات جديدة. يمكن ملاحظة النظام عندما يمكنك فهم حالته الداخلية من خلال مخرجاته الخارجية (المقاييس والسجلات والتتبعات). ومن الناحية العملية، يعد الرصد الجيد جزءًا فرعيًا من إمكانية الملاحظة.

كيف أقنع فريقي بالاستثمار في إمكانية الملاحظة؟

تتبع متوسط ​​الوقت حتى القرار (MTTR) لحوادث الإنتاج قبل وبعد تحسينات إمكانية المراقبة. عادةً ما تقلل الفرق التي تتمتع بقابلية ملاحظة جيدة من MTTR بنسبة 60-70%. اضرب الوقت الذي توفره التكلفة الهندسية لإظهار عائد الاستثمار. قم أيضًا بتتبع عدد الحوادث المكتشفة من خلال المراقبة مقابل تقارير المستخدم - فالكشف الاستباقي يبني ثقة العملاء.

---

ما هو التالي

ابدأ بتتبع الأخطاء (Sentry) إذا لم يكن لديك أي شيء - فهو يوفر القيمة الأكثر إلحاحًا من خلال اكتشاف أخطاء الإنتاج والتنبيه بها. بعد ذلك، أضف التسجيل المنظم بمعرفات الارتباط. ثم قم بتنفيذ جمع المقاييس باستخدام لوحات معلومات Prometheus وGrafana. وأخيرًا، قم بإضافة التتبع الموزع عندما يكون لديك خدمات متعددة.

للحصول على سياق هندسة الأداء الكامل، راجع دليلنا الأساسي حول توسيع نطاق النظام الأساسي لأعمالك. لتحسين البنية التحتية التي تراقبها المراقبة، اقرأ دليل قياس البنية التحتية.

تنفذ ECOSIRE مكدسات إمكانية المراقبة لمنصات الأعمال التي تعمل على Odoo ERP والبنيات المخصصة. اتصل بفريق DevOps لإجراء تقييم للمراقبة والملاحظة.

---

تم النشر بواسطة ECOSIRE — لمساعدة الشركات على التوسع باستخدام الحلول المدعومة بالذكاء الاصطناعي عبر Odoo ERP، وShopify eCommerce، وOpenClaw AI.