ประสิทธิภาพ

ประวัติโหลดของเซิร์ฟเวอร์: 24 ชั่วโมง, 7 หรือ 30 วัน (เก็บข้อมูลทุก 5 นาที)

Load Average (1m)
2.28
CPU
7.7%
RAM
31.5%
ESTABLISHED
121
โปรเซส
5 / 443
Load Average
CPU
หน่วยความจำ
เครือข่าย (KB/s)
Disk I/O (KB/s)
การเชื่อมต่อ TCP
ดิสก์และลิมิต (%)
MySQL
โปรเซสในการวัดล่าสุด 11:14
โปรเซส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
โปรเซสในช่วงพีคของวัน 12.10 08:39 · load 2.49
โปรเซส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

ประวัติภาระของเซิร์ฟเวอร์โดยไม่ต้องใช้ Prometheus และ Grafana

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 หมดก่อนพื้นที่ว่างอยู่มาก