| العملية | CPU % | RAM % |
|---|---|---|
| apache2 | 13.4 | 4.7 |
| clamd | 9.8 | 5.3 |
| crowdsec | 6.6 | 9.6 |
| suricata | 4.7 | 0.9 |
| falco | 2.6 | 16.5 |
| العملية | CPU % | RAM % |
|---|---|---|
| falco | 19.5 | 5.3 |
| mysqld | 13.1 | 9.6 |
| fail2ban-server | 8.1 | 8.8 |
| crowdsec | 5.7 | 13.6 |
| apache2 | 3.5 | 11.0 |
يجيب الأمر top عن سؤال يخص الثانية الحالية، بينما السؤال المطروح فعلاً يخص الليلة الماضية: لماذا توقف كل شيء عند الثالثة فجراً ثم عاد من تلقاء نفسه. عند تلك اللحظة لم يعد هناك ما يُنظر إليه، لأن شيئاً لم يُسجَّل. أما نصب Prometheus وGrafana من أجل خادم افتراضي واحد فمشكلة قائمة بذاتها: الحزمة التي تراقب أثقل من الخادم المُراقَب.
يضيف المُجمِّع سطراً واحداً إلى قاعدة البيانات كل خمس دقائق، وترسم هذه الصفحة منها اليوم الأخير. متوسط الحِمل، واستهلاك المعالج مع فصل I/O wait، والذاكرة والـswap، وحركة الشبكة الواردة والصادرة، وقراءة القرص وكتابته، واتصالات TCP القائمة، والعمليات، وامتلاء القسم، وعُقد الفهرسة ومُعرِّفات الملفات كنسبة من حدّها، واتصالات MySQL. كل ذلك في صفحة واحدة وعلى محور زمني واحد، فتُرى التزامنات بالعين المجردة.
تُقرأ هذه الرسوم أزواجاً. ارتفاع I/O wait مع معالج هادئ يعني أن الخادم ينتظر القرص، ولن تُجدي زيادة الأنوية. وswap ارتفع مرة ولم يعد إلى الصفر يقول إن ذروة الذاكرة قد وقعت فعلاً مهما بدا الوضع الآن هادئاً. ومُعرِّفات الملفات المقتربة من مئة بالمئة هي خطأ too many open files قبل وقوعه بساعات. وفي معظم الخوادم تنفد عُقد الفهرسة قبل المساحة الحرة بكثير.