प्रदर्शन

सर्वर लोड का इतिहास: 24 घंटे, 7 या 30 दिन (संग्रह — हर 5 मिनट में एक बार)

Load Average (1m)
1.22
CPU
11.8%
RAM
30.8%
ESTABLISHED
92
प्रोसेस
1 / 397
Load Average
CPU
मेमोरी
नेटवर्क (KB/s)
डिस्क I/O (KB/s)
TCP कनेक्शन
डिस्क और लिमिट (%)
MySQL
अंतिम माप की प्रक्रियाएँ 01:27
प्रक्रिया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
दिन के शिखर की प्रक्रियाएँ 11.10 08:57 · load 2.00
प्रक्रिया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

Prometheus और Grafana के बिना सर्वर लोड का इतिहास

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 खाली जगह से काफ़ी पहले समाप्त हो जाते हैं।