| প্রক্রিয়া | CPU % | RAM % |
|---|---|---|
| falco | 7.4 | 5.6 |
| mysqld | 4.4 | 7.3 |
| crowdsec | 2.6 | 15.6 |
| apache2 | 1.4 | 4.5 |
| fail2ban-server | 0.7 | 17.1 |
| প্রক্রিয়া | CPU % | RAM % |
|---|---|---|
| apache2 | 18.0 | 9.3 |
| mysqld | 12.8 | 14.0 |
| clamd | 8.9 | 14.3 |
| falco | 6.2 | 11.0 |
| suricata | 2.8 | 18.4 |
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 ফুরিয়ে যায়।