الإقليم ٦ — العين الساهرة: المراقبة (Monitoring) وQPS
النبذة
بنينا نظاماً متوفّراً مؤمَّناً — لكنه أعمى. لو مات خادمٌ، أو امتلأ قرص، أو تضاعفت الطلبات حتى الاختناق، لن نعرف إلا حين يشتكي المستخدمون (متأخّرين). Task 2 يضيف ثلاثة عملاء مراقبة (monitoring clients). هذا الإقليم يجيب: لماذا نراقب، وكيف تجمع أداة المراقبة بياناتها، وكيف تراقب QPS تحديداً.
نظامك يخدم بسعادةٍ منذ أسبوع. فجأةً يبطؤ الموقع ثم يسقط. تفتح تحقيقاً: هل خادمٌ مات؟ متى؟ هل القرص امتلأ؟ هل تضاعفت الطلبات؟ هل الـ CPU كان مختنقاً ساعةً قبل السقوط؟ لا تملك أي بيانٍ تاريخي — كل ما لديك هو «الآن، وهو ميت».
السؤال: ما الذي كان يجب أن يكون موجوداً قبل السقوط ليخبرك أن القرص يمتلئ ببطءٍ منذ يومين؟ صمّمه على ورقة. ستُجبر على اختراع شيءٍ يقيس باستمرار، يخزّن التاريخ، وينبّه عند العتبات — وهذا هو نظام المراقبة.
الدرس
ليش نراقب — لا تستطيع إصلاح ما لا تراه
المراقبة ليست رفاهية؛ هي حاسّة النظام. ثلاثة أغراضٍ تشتقّ منها كل ميزةٍ لاحقة:
- التوفّر (availability): هل كل عنصرٍ حيّ؟ (كشف الأعطال فور حدوثها، لا بعد الشكاوى.)
- الأداء (performance): هل النظام بطيء؟ أين؟ (زمن الاستجابة، حِمل CPU/RAM/قرص.)
- السعة والاتجاه (capacity): هل نقترب من السقف؟ (القرص يمتلئ، الطلبات تتزايد ⟵ متى نوسّع قبل الأزمة؟)
وفوقها التنبيه (alerting): أن تُوقَظ في الثالثة فجراً بإشعارٍ آليّ بدل أن تستيقظ على موقعٍ ميت. الغرض النهائي: تحويل المفاجأة إلى توقّع.
ليش «عميل» على كل خادم — كيف تجمع الأداة بياناتها
المشروع يسأل صراحةً «كيف تجمع أداة المراقبة بياناتها». النمط القياسي:
- على كل خادمٍ يُركَّب عميل/مجمِّع (monitoring client / data collector / agent) — برنامجٌ صغيرٌ يعمل محلياً.
- العميل يجمع المقاييس والسجلّات من خادمه (استهلاك CPU/RAM/قرص، حالة الخدمات، سطور access log…) ويرسلها (push) عبر الشبكة إلى خدمة المراقبة المركزية (مثل Sumologic, Datadog, Prometheus…).
- الخدمة تخزّن التاريخ، ترسم اللوحات (dashboards)، وتطلق التنبيهات عند العتبات.
ليش ثلاثة عملاء في Task 2؟ واحدٌ لكل خادمٍ من الثلاثة. المراقبة لامركزية بطبيعتها: كل خادمٍ يراقب نفسه ويبلّغ، لأن مصدر البيانات هو الخادم نفسه. (بعض الأنظمة تَسحب pull بدل push، لكن النموذج المطلوب هنا هو الوكيل المجمِّع الذي يدفع.)
ليش QPS — وكيف تراقبه على الـ web server (سؤال Task 2)
QPS = Queries Per Second — عدد الطلبات/الاستعلامات في الثانية. لماذا يهمّ؟ لأنه المقياس المباشر لـ الحِمل: هو ما يقول لك متى تقترب من سقف الموزّع أو الخادم، ومتى يجب أن توسّع (إقليم ٧). إنه الجسر بين «المراقبة» و«التوسّع».
كيف تراقب QPS للـ web server تحديداً؟ اشتقّها من «كيف تجمع الأداة بياناتها»:
- الـ web server (Nginx) يسجّل كل طلبٍ في access log بطابعٍ زمني.
- اضبط عميل المراقبة على ذلك الخادم ليقرأ هذا السجلّ (أو ليقرأ عدّاد طلباتٍ يعرضه Nginx مثل
stub_status)، ويعدّ الطلبات لكل ثانية، ثم يرسل الرقم لخدمة المراقبة لترسمه وتنبّه إن تجاوز عتبة.
بكلمة: عدّ الطلبات في access log عبر الزمن، أرسل المعدّل، ضع عتبة تنبيه. هذا هو الجواب الكامل لسؤال «explain what to do if you want to monitor your web server QPS».
تحليل الأخطاء
- «المراقبة = معرفة أن الخادم حيّ.» ذاك جزءٌ واحد (availability). الأهمّ غالباً هو الأداء والاتجاه: أن ترى الاختناق قادماً.
- «QPS مقياس قاعدة البيانات فقط.» «Query» هنا تعني أي طلب؛ تقيس QPS على أي طبقة (web requests/s، DB queries/s). المشروع يطلبها على الـ web server.
- «العميل يحلّل البيانات.» العميل يجمع ويرسل؛ التحليل والتخزين والتنبيه في الخدمة المركزية.
أكمِل مخطّط Task 2: ضع عميل مراقبة على كل خادمٍ من الثلاثة، وارسم أسهماً منها إلى خدمة مراقبةٍ خارجية. لكل عنصرٍ مضاف اكتب «لماذا». ثم على ورقة:
- ما الغرض من المراقبة؟ كيف تجمع الأداة البيانات (agent → push → service)؟
- صف خطوة بخطوة كيف تراقب QPS للـ web server.
الخلاصة — وصلٌ في الشجرة
- اشتققتَ المراقبة كـ حاسّةٍ للنظام: توفّر + أداء + سعة + تنبيه.
- ملكتَ نموذج الجمع: agent على كل خادم ⟵ يدفع المقاييس/السجلّات ⟵ خدمةٌ مركزية، وفهمتَ لماذا ثلاثة عملاء.
- عرّفتَ QPS وربطتَه بالحِمل، وعرفتَ كيف تقيسه من access log — وهذا **يفتح باب التوسّع*: المراقبة تخبرك متى* توسّع.
البذرة المتروكة: المراقبة قالت لك إن QPS تجاوز طاقة الـ app server، بينما قاعدة البيانات شبه فارغة. لكن في بنيتك الحالية كل خادمٍ يحوي الثلاثة معاً — فكيف توسّع طبقةً واحدةً دون الأخريات؟ ولاحظ أيضاً أن الموزّع لا يزال SPOF. هذا هو الإقليم ٧: الانتشار.
Monitoring is the system's senses: it tracks availability (is each part up?), performance (latency, CPU/RAM/disk), and capacity/trends, and alerts us before a failure instead of after user complaints.
How it collects data: a monitoring client / agent runs on each server, gathers metrics and logs locally, and pushes them to a central monitoring service (e.g., Sumologic). That's why there's one client per server.
QPS = Queries Per Second — the load metric. To monitor the web server's QPS, point the agent at Nginx's access log (or
stub_status), count requests per second, and send that rate to the service with an alert threshold.
وقفة الانضباط: «how it collects data» = agent collects locally and pushes to a service. لا تَسرد أسماء أدواتٍ ولا فرق push/pull ما لم يُسأل.