| प्रक्रिया | 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 मौजूदा सेकंड के बारे में सवाल का जवाब देता है, जबकि असल सवाल आम तौर पर बीती रात का होता है: तीन बजे सब कुछ क्यों रुक गया और अपने आप लौट आया। उस समय तक देखने को कुछ बचता ही नहीं, क्योंकि कहीं कुछ दर्ज ही नहीं हुआ। एक अकेले VPS के लिए Prometheus और Grafana खड़ा करना भी अपने आप में समस्या है: निगरानी करने वाला ढाँचा निगरानी में रखे सर्वर से भारी पड़ जाता है।
एक संग्राहक हर पाँच मिनट पर डेटाबेस में एक पंक्ति जोड़ता है, और यह पृष्ठ उन्हीं से पिछले चौबीस घंटे बनाता है। Load average, CPU का उपयोग और अलग से I/O wait, RAM तथा swap, आने और जाने वाला नेटवर्क ट्रैफ़िक, डिस्क का पढ़ना और लिखना, स्थापित TCP कनेक्शन, प्रक्रियाएँ, विभाजन का भराव, inodes और फ़ाइल डिस्क्रिप्टर अपनी सीमा के प्रतिशत में, तथा MySQL कनेक्शन। सब कुछ एक ही पृष्ठ पर और एक ही समय-अक्ष पर, ताकि संयोग आँख से दिख जाएँ।
इन ग्राफ़ों को जोड़ों में पढ़ना चाहिए। शांत CPU के साथ ऊँचा I/O wait का अर्थ है कि सर्वर डिस्क की प्रतीक्षा कर रहा है, और कोर बढ़ाने से कुछ नहीं होगा। वह swap जो एक बार बढ़ा और कभी शून्य पर नहीं लौटा, बताता है कि मेमोरी का शिखर पहले ही आ चुका है, चाहे अभी सब शांत लगे। सौ प्रतिशत के पास पहुँचते फ़ाइल डिस्क्रिप्टर too many open files त्रुटि को उसके घटित होने से कुछ घंटे पहले दिखा देते हैं। और अधिकांश सर्वरों पर inodes खाली जगह से काफ़ी पहले समाप्त हो जाते हैं।