ประวัติโหลดของเซิร์ฟเวอร์: 24 ชั่วโมง, 7 หรือ 30 วัน (เก็บข้อมูลทุก 5 นาที)
| โปรเซส | CPU % | RAM % |
|---|---|---|
| crowdsec | 4.7 | 4.2 |
| clamd | 3.0 | 18.1 |
| mysqld | 1.9 | 11.9 |
| falco | 0.9 | 14.2 |
| apache2 | 0.6 | 0.7 |
| โปรเซส | CPU % | RAM % |
|---|---|---|
| fail2ban-server | 9.0 | 17.5 |
| falco | 4.9 | 1.9 |
| clamd | 3.5 | 11.0 |
| crowdsec | 2.4 | 1.8 |
| mysqld | 1.4 | 4.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 หมดก่อนพื้นที่ว่างอยู่มาก