کارکردگی

سرور بوجھ کی تاریخ: 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، پروسیسر کا استعمال اور الگ سے I/O wait، RAM اور swap، آنے اور جانے والا نیٹ ورک ٹریفک، ڈسک کی پڑھائی اور لکھائی، قائم شدہ TCP کنکشن، پروسیس، پارٹیشن کا بھراؤ، inodes اور فائل ڈسکرپٹر اپنی حد کے فیصد میں، اور MySQL کے کنکشن۔ سب ایک ہی صفحے پر اور ایک ہی وقت کے پیمانے پر، تاکہ ہم وقت واقعات آنکھ سے دکھائی دیں۔

ان گرافوں کو جوڑوں میں پڑھنا چاہیے۔ پرسکون پروسیسر کے ساتھ بلند I/O wait کا مطلب ہے کہ سرور ڈسک کا انتظار کر رہا ہے، اور کور بڑھانے سے کچھ نہ ہوگا۔ وہ swap جو ایک بار بڑھا اور کبھی صفر پر واپس نہ آیا، بتاتا ہے کہ میموری کی انتہا پہلے ہی گزر چکی ہے، خواہ اب سب پرسکون لگے۔ سو فیصد کے قریب پہنچتے فائل ڈسکرپٹر too many open files کی خرابی کو اُس کے وقوع سے کئی گھنٹے پہلے دکھا دیتے ہیں۔ اور بیشتر سرورز پر inodes خالی جگہ سے کہیں پہلے ختم ہو جاتے ہیں۔