ประวัติโหลดของเซิร์ฟเวอร์: 24 ชั่วโมง, 7 หรือ 30 วัน (เก็บข้อมูลทุก 5 นาที)
| โปรเซส | CPU % | RAM % |
|---|---|---|
| falco | 10.1 | 10.0 |
| crowdsec | 5.2 | 15.9 |
| apache2 | 3.6 | 5.9 |
| suricata | 2.5 | 2.1 |
| php-fpm | 1.5 | 13.9 |
| โปรเซส | CPU % | RAM % |
|---|---|---|
| suricata | 9.0 | 17.7 |
| falco | 5.5 | 15.6 |
| fail2ban-server | 2.5 | 16.4 |
| apache2 | 1.7 | 11.1 |
| clamd | 1.0 | 13.5 |
top ตอบคำถามเกี่ยวกับวินาทีปัจจุบัน ขณะที่คำถามที่ถามกันจริงมักเป็นเรื่องของคืนที่ผ่านมา ว่าทำไมตอนตีสามทุกอย่างจึงหยุดนิ่งแล้วกลับมาเองได้ ถึงตอนนั้นก็ไม่เหลืออะไรให้ดูแล้ว เพราะไม่มีสิ่งใดถูกบันทึกไว้ ส่วนการตั้ง Prometheus และ Grafana เพื่อ VPS เพียงเครื่องเดียวก็เป็นปัญหาในตัวเอง เพราะกองซอฟต์แวร์ที่คอยเฝ้าดูหนักกว่าเซิร์ฟเวอร์ที่ถูกเฝ้าดู
ตัวเก็บข้อมูลเขียนหนึ่งแถวลงฐานข้อมูลทุกห้านาที และหน้านี้วาดช่วงยี่สิบสี่ชั่วโมงล่าสุดจากข้อมูลเหล่านั้น ทั้ง load average, การใช้ CPU โดยแยก I/O wait ออกมา, RAM และ swap, ปริมาณข้อมูลเครือข่ายขาเข้าและขาออก, การอ่านและเขียนดิสก์, การเชื่อมต่อ TCP ที่สร้างแล้ว, โพรเซส, ความเต็มของพาร์ทิชัน, inodes และตัวชี้ไฟล์เป็นร้อยละของขีดจำกัด รวมถึงการเชื่อมต่อ MySQL ทั้งหมดอยู่ในหน้าเดียวและบนแกนเวลาเดียวกัน ความบังเอิญจึงมองเห็นได้ด้วยตา
กราฟเหล่านี้ควรอ่านเป็นคู่ ค่า I/O wait สูงขณะที่ CPU สงบหมายความว่าเซิร์ฟเวอร์กำลังรอดิสก์ การเพิ่มคอร์จึงไม่ช่วยอะไร swap ที่เคยขึ้นครั้งหนึ่งแล้วไม่เคยกลับมาที่ศูนย์บอกว่าจุดสูงสุดของหน่วยความจำได้ผ่านไปแล้ว ไม่ว่าตอนนี้จะดูสงบเพียงใด ตัวชี้ไฟล์ที่ไต่ใกล้ร้อยเปอร์เซ็นต์คือข้อผิดพลาด too many open files ล่วงหน้าหลายชั่วโมงก่อนเกิดจริง และบนเซิร์ฟเวอร์ส่วนใหญ่ inodes หมดก่อนพื้นที่ว่างอยู่มาก