| תהליך | CPU % | RAM % |
|---|---|---|
| falco | 7.4 | 5.6 |
| mysqld | 4.4 | 7.3 |
| crowdsec | 2.6 | 15.6 |
| apache2 | 1.4 | 4.5 |
| fail2ban-server | 0.7 | 17.1 |
| תהליך | CPU % | RAM % |
|---|---|---|
| apache2 | 18.0 | 9.3 |
| mysqld | 12.8 | 14.0 |
| clamd | 8.9 | 14.3 |
| falco | 6.2 | 11.0 |
| suricata | 2.8 | 18.4 |
הפקודה top עונה על שאלה בנוגע לשנייה הנוכחית, בעוד השאלה שנשאלת בפועל נוגעת ללילה שעבר: מדוע בשלוש לפנות בוקר הכול נעצר וחזר מעצמו. באותו רגע כבר אין על מה להסתכל, משום ששום דבר לא נשמר. גם להקים Prometheus ו-Grafana עבור שרת וירטואלי יחיד היא בעיה בפני עצמה: המערך שמשגיח כבד מן השרת המושגח.
אוסף הנתונים מוסיף שורה אחת למסד הנתונים כל חמש דקות, והדף מצייר מהן את היממה האחרונה. Load average, ניצול המעבד עם I/O wait בנפרד, RAM ו-swap, תעבורת רשת נכנסת ויוצאת, קריאה וכתיבה לדיסק, חיבורי TCP פעילים, תהליכים, תפוסת המחיצה, inodes ומתארי קבצים באחוזים מן המגבלה, וחיבורי MySQL. הכול בדף אחד ועל ציר זמן אחד, כך שצירופי מקרים נראים בעין.
כדאי לקרוא את הגרפים האלה בזוגות. I/O wait גבוה לצד מעבד רגוע פירושו שהשרת ממתין לדיסק, והוספת ליבות לא תועיל. swap שעלה פעם אחת ומעולם לא חזר לאפס אומר ששיא הזיכרון כבר קרה, גם אם כרגע הכול נראה שקט. מתארי קבצים המתקרבים למאה אחוז הם שגיאת too many open files כמה שעות לפני שתתרחש. וברוב השרתים ה-inodes נגמרים הרבה לפני המקום הפנוי.