Linux : Monitoring Server Dasar (htop, netdata)

Monitoring server sering dianggap pekerjaan "buka htop, lihat angka, tutup". Padahal htop cuma menjawab satu pertanyaan: apa yang terjadi detik ini. Begitu terminal ditutup, jawabannya hilang. Netdata menjawab pertanyaan yang berbeda: sejak kapan ini terjadi, dan apa yang berubah sebelumnya.

Artikel ini menyusun keduanya sebagai satu rantai kerja, bukan dua daftar perintah. Kalau kamu belum pernah memakai htop atau uptime, baca dulu dua halaman dasarnya di bagian Materi terkait.

🎯 Tujuan

Setelah membaca dan mempraktikkan artikel ini, kamu bisa:

• menjelaskan beda potret sesaat dan riwayat dalam monitoring, plus kapan masing-masing dipakai;
• membaca layar htop tanpa salah tafsir: load average, CPU per core, memori, dan swap;
• membedakan "server sibuk" dari "server menunggu disk";
• memasang Netdata di VM latihan dan membaca grafiknya, bukan cuma angka terakhir;
• menghitung sendiri berapa lama data monitoring tersimpan, dan kapan datanya dibuang;
• menulis satu alarm sederhana yang benar-benar berbunyi saat ambang terlampaui.

📍 Konteks nyata

Bayangkan lab komputer SMK tempatmu praktik. Jam 10.00, semua siswa masuk aplikasi ujian. Sepuluh menit kemudian aplikasi terasa lambat, soal kadang gagal dimuat. Guru membuka htop di server dan melihat angka CPU 4 persen. Kesimpulan cepat: "server sehat, pasti jaringannya."

Tux, maskot Linux — teman pertama saat membuka server.

Dua hari kemudian ketahuan masalahnya bukan jaringan. Disk server menunggu terus, swap terpakai hampir 2 GB, dan htop memang tidak pernah menunjukkan itu sebagai "CPU tinggi". Yang menipu adalah caranya membaca: satu angka bagus dipakai untuk membatalkan seluruh keluhan.

Analogi yang enak dipakai: htop itu termometer yang ditempel di dahi. Netdata itu rekam medis yang menyimpan kurva suhu seminggu. Termometer berguna saat demam sekarang. Tapi dokter yang cuma punya termometer tidak bisa menjawab "sejak kapan demamnya naik".

🔥 Kasus nyata: di sebuah SMK, server CBT dianggap sehat karena htop menunjukkan CPU 4 persen. Kenyataannya vmstat menunjukkan wa (wait I/O) 60 persen dan swap terpakai 1,9 GB karena innodb_buffer_pool_size dipasang lebih besar dari RAM. Sekolah sempat membeli RAM baru yang tidak menyelesaikan apa pun. Setelah dipasang grafik 7 hari, pola langsung terlihat: lambat selalu muncul jam 10.00, saat backup harian dan input nilai bertabrakan.

🧠 Konsep singkat

Monitoring yang berguna selalu menjawab tiga pertanyaan berurutan:

1. Apakah ini normal? — butuh pembanding, bukan angka mentah.
2. Sejak kapan tidak normal? — butuh riwayat, bukan potret.
3. Apa yang berubah sebelumnya? — butuh korelasi antar-metrik.

Ketiganya tidak bisa dijawab oleh satu layar htop. Karena itu monitoring disusun sebagai rantai lima lapis berikut.

Lapis	Pertanyaan	Kalau lapis ini bolong
Metric	Angka apa yang diukur?	Kamu sibuk melihat hal yang tidak berhubungan dengan keluhan
Sampel	Seberapa sering diambil?	Lonjakan 2 menit hilang, yang terlihat cuma rata-rata
Retensi	Berapa lama disimpan?	Tidak bisa menjawab "sejak kapan", cuma "sekarang"
Ambang	Kapan angka dianggap salah?	Grafiknya cantik, tapi tidak ada yang berteriak
Pemberitahuan	Siapa yang diberi tahu?	Alarm berbunyi di layar yang tidak ada orangnya

Periksa dari kiri ke kanan, dan berhenti di lapis pertama yang gagal. Salah urutan paling sering: orang langsung membahas ambang dan alarm, padahal belum punya riwayat sama sekali.

🔹 Tiga alat, tiga tugas

Alat	Menyimpan riwayat?	Paling cocok untuk
top / htop	Tidak, hilang saat ditutup	Melihat kondisi sekarang dan mencari proses rakus
sar (paket sysstat)	Ya, ringkas tiap 10 menit	Server tanpa agen, pertanyaan "tadi jam 10 kenapa"
Netdata	Ya, resolusi per detik	Menjawab "sejak kapan" plus alarm otomatis

sar sengaja disebut karena sering dilupakan: satu paket kecil, tanpa dashboard, tapi cukup untuk menjawab "kemarin jam 10 server kenapa". Banyak teknisi langsung memasang dashboard besar padahal butuhnya cuma angka historis.

🔹 Angka tanpa pembanding bukan informasi

Baseline adalah potret kondisi normal server kamu sendiri, diambil saat semuanya baik-baik saja. Tanpa baseline, kamu tidak punya dasar untuk bilang "tinggi" atau "rendah".

Contoh: load 4 di server 2 core artinya antrean dua kali lipat kapasitas. Load 4 di server 16 core artinya santai. Angka yang sama, arti yang berlawanan.

📊 Angka penting: uptime menghitung load average dari jumlah proses yang runnable atau uninterruptable (menunggu disk), dirata-ratakan 1, 5, dan 15 menit. Manpage-nya menegaskan load tidak dinormalisasi terhadap jumlah CPU. Jadi selalu bagi dengan nproc sebelum panik.

🔹 Kenapa CPU rendah tapi terasa lambat

Ada dua penyebab yang paling sering dan paling sering terlewat:

• Menunggu disk (iowait). Proses "runnable" tapi menunggu data dari disk. CPU menganggur, pengguna tetap menunggu.
• Swap. Memori penuh, sebagian isi RAM dipindah ke disk. Setiap akses ke bagian itu jadi ratusan kali lebih lambat.

⚠️ Hati-hati: htop menampilkan CPU% per core, bukan total. Satu program yang tidak multithread di server 2 core maksimal hanya menyentuh 100 persen dari 200 persen kapasitas. Ini disebut "Irix mode" dan sengaja dipakai supaya kamu tahu core mana yang bekerja.

🧪 Uji cepat: bandingkan tiga sudut pandang dalam 30 detik:

uptime; nproc
free -m
vmstat 1 3
cat /proc/pressure/io

Kalau load tinggi tapi kolom id di vmstat juga tinggi, curigai I/O, bukan CPU.

🧩 Istilah penting

• Metric — satu jenis angka yang diukur terus-menerus, misalnya pemakaian CPU atau jumlah koneksi.
• Sampel (sample) — satu nilai metric pada satu waktu tertentu.
• Time series — deretan sampel yang tersimpan berurutan, inilah "rekam medis" server.
• Interval / update every — jarak antar sampel. Netdata bawaannya 1 detik, sar 10 menit.
• Retensi — berapa lama data disimpan sebelum dibuang.
• Baseline — potret kondisi normal server kamu sendiri.
• Threshold — ambang yang memisahkan "wajar" dan "perlu dilihat".
• Alert / alarm — aturan yang mengubah angka jadi pemberitahuan.
• iowait — waktu CPU menganggur karena menunggu disk selesai.
• Swap — ruang di disk yang dipakai sebagai tambahan memori.
• PSI (Pressure Stall Information) — angka dari kernel yang mengukur berapa lama tugas benar-benar tertahan, bukan cuma seberapa sibuk.

🔧 Praktik: dari htop ke netdata

Lab ini memakai VM latihan, bukan server produksi. Siapkan snapshot dulu. Semua perintah dijalankan sebagai user biasa yang punya sudo.

🔹 Langkah 0: potret baseline

Simpan kondisi awal ke satu berkas, supaya nanti bisa dibandingkan.

mkdir -p ~/lab-monitor
{
  date -Is
  uptime
  nproc
  free -m
  df -h /
  vmstat 1 5
  cat /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory
} > ~/lab-monitor/baseline-$(date +%F-%H%M).txt
less ~/lab-monitor/baseline-*.txt

Kalau /proc/pressure tidak ada, kernel kamu lebih lama dari 4.20. Lewati bagian itu, sisanya tetap jalan.

🔹 Langkah 1: membaca layar htop dengan benar

Jalankan htop, lalu baca dari atas ke bawah, bukan dari daftar proses.

1. Baris load average — bandingkan dengan nproc. Load 2 di 2 core artinya penuh.
2. Meter CPU — kalau dibuat per core, cari core yang penuh, bukan rata-rata.
3. Meter Mem — perhatikan warna cache; memori bekas cache bukan memori hilang.
4. Meter Swp — angka bukan nol berarti ada halaman yang sudah pindah ke disk.
5. Daftar proses — baru di sini kamu cari proses penyebabnya.

💡 Tips: di server produksi pakai htop --readonly. Semua fitur pengubah (kill, renice) dimatikan, jadi tidak ada risiko salah tekan saat menunjuk layar.

🔹 Langkah 2: kunci htop yang menghemat waktu

htop --readonly            # aman untuk produksi
htop -d 20                 # refresh tiap 2 detik (satuan persepuluh detik)
htop -u www-data           # hanya proses satu user
htop -t                    # tampilan pohon, kelihatan induk-anak
htop -F "php|mariadb"      # filter nama, dipisah tanda pipa

Di dalam htop, tombol yang paling sering dipakai:

• F6 — ganti kolom urutan, misalnya PERCENT_MEM.
• F4 — filter proses yang sedang tampil.
• F5 — mode pohon, untuk melihat siapa induk dari proses aneh.
• H — sembunyikan thread, supaya daftar tidak penuh baris kembar.
• K — sembunyikan thread kernel.
• u — filter per user.
• Z — jeda pembaruan, berguna saat membaca angka dengan teliti.

📊 Angka penting: opsi -d memakai satuan persepuluh detik. Nilai di bawah 1 dinaikkan jadi 1, nilai di atas 100 diturunkan jadi 100. Artinya rentang nyatanya 0,1 sampai 10 detik.

🔹 Langkah 3: membuat beban sendiri

Supaya tidak menebak, buat beban terkendali lalu amati. Beban CPU dulu:

for i in $(seq 1 "$(nproc)"); do
  timeout 90 bash -c 'while :; do :; done' &
done
htop --readonly

Di terminal lain, lihat perubahan angkanya:

uptime
vmstat 1 3

Load akan naik mendekati jumlah core, dan tiap core terlihat penuh di htop. Setelah 90 detik beban berhenti sendiri.

🔹 Langkah 4: membuktikan htop tidak punya riwayat

Ini bagian yang paling penting untuk dipahami.

1. Saat beban masih jalan, catat angka load di htop.
2. Tutup htop dengan q.
3. Tunggu beban selesai, lalu buka htop lagi.

Angka load sudah turun, dan tidak ada satu pun jejak bahwa tadi ada lonjakan. Bukan bug — htop memang tidak menyimpan apa pun. Di titik inilah Netdata masuk.

🔹 Langkah 5: memasang netdata

Netdata adalah agen monitoring yang mengumpulkan metric tiap detik, menyimpannya ke disk, dan menyediakan dashboard sendiri di port 19999.

sudo apt-get update
sudo apt-get install -y curl
curl -fsSL -o /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sudo sh /tmp/netdata-kickstart.sh

Skrip ini butuh akses root dan internet, serta menulis ke /etc/netdata dan /var/lib/netdata. Di server produksi, baca dulu skripnya dan jalankan di luar jam sibuk.

Verifikasi cepat:

systemctl is-active netdata
ss -tlnp | grep 19999
curl -s localhost:19999/api/v1/info

Akses dashboard paling aman lewat terowongan SSH, bukan membuka port ke internet:

ssh -L 19999:localhost:19999 server@192.168.100.240

Lalu buka http://localhost:19999 di browser komputermu.

🔹 Langkah 6: membaca grafik, bukan angka

Di dashboard, ubah rentang waktu ke 15 menit, lalu 3 jam, lalu 7 hari. Perhatikan tiga hal:

• Bentuk kurva, bukan nilai terakhir. Naik-turun teratur biasanya pola jadwal.
• Titik perubahan — cari jam saat kurva berubah perilaku.
• Anomali — versi terbaru punya deteksi anomali berbasis machine learning. Anggap sebagai petunjuk, bukan vonis.

💡 Tips: saat ada keluhan "lambat", jangan langsung buka grafik CPU. Buka dulu system.cpu, system.ram, disk.io, dan system.io pada rentang waktu keluhan. Penyebab paling sering justru di disk, bukan CPU.

🔹 Langkah 7: memeriksa retensi

Retensi menentukan sejauh apa kamu bisa melihat ke belakang. Buka konfigurasi:

sudo /etc/netdata/edit-config netdata.conf

Cari bagian [db]. Nilai bawaan yang perlu kamu tahu:

Pengaturan	Bawaan	Arti
db	dbengine	Data disimpan di disk, bukan cuma di RAM
update every	1	Satu sampel per detik
storage tiers	3	Tiga tingkat resolusi
Tier 0	1 GiB / 14 hari	Resolusi per detik
Tier 1	1 GiB / 3 bulan	Resolusi per menit
Tier 2	1 GiB / 2 tahun	Resolusi per jam

📊 Angka penting: total penyimpanan bawaan sekitar 3 GiB untuk metric, dan sekitar 4 GiB bila ditambah basis data metadata. Data dibuang saat salah satu batas tercapai — ukuran atau waktu, mana yang lebih dulu.

Cek nilai yang benar-benar aktif:

curl -s localhost:19999/netdata.conf | grep -A15 '\[db\]'

⚠️ Hati-hati: kalau db diubah jadi ram, semua riwayat hilang setiap Netdata restart. Dashboard tetap jalan, tapi pertanyaan "sejak kapan" tidak bisa dijawab lagi.

🔹 Langkah 8: menulis alarm sendiri

Alarm Netdata disimpan sebagai berkas di health.d/. Buat satu alarm pemakaian RAM:

sudo /etc/netdata/edit-config health.d/ram-usage.conf

Isinya:

 alarm: ram_usage_lab
    on: system.ram
lookup: average -1m percentage of used
 units: %
 every: 10s
  warn: $this > 70
  crit: $this > 85
  info: RAM terpakai di atas ambang lab
    to: sysadmin

Terapkan tanpa restart, supaya tidak ada lubang data:

sudo netdatacli reload-health
curl -s localhost:19999/api/v1/alarms

Perhatikan baris to: sysadmin. Tanpa konfigurasi pengiriman notifikasi, alarm hanya berubah warna di dashboard — tidak ada pesan yang keluar. Itu lapis kelima yang sering dilupakan.

🔹 Langkah 9: menguji alarm dengan beban nyata

Alarm yang belum pernah berbunyi belum bisa dipercaya. Pakai memori terkendali:

python3 - <<'PY'
b = bytearray(900 * 1024 * 1024)
for i in range(0, len(b), 4096):
    b[i] = 1
import time
time.sleep(120)
PY

Sambil menunggu, pantau di terminal lain:

watch -n 2 'free -m | head -2; curl -s localhost:19999/api/v1/alarms | head -c 300'

Alarm harus naik ke WARNING, lalu kembali normal setelah proses selesai. Kalau tidak pernah berubah, masalahnya bukan di beban — periksa every, lookup, dan apakah health benar-benar aktif.

🔹 Langkah 10: bersih-bersih

sudo rm -f /etc/netdata/health.d/ram-usage.conf
sudo netdatacli reload-health
sudo systemctl disable --now netdata   # hanya untuk VM latihan
rm -rf ~/lab-monitor

Jangan menonaktifkan Netdata di server yang memang sedang dipakai memantau.

🏭 Dipakai di dunia kerja

• Sekolah/lab komputer: ujian berbasis komputer berjalan serentak. Monitoring riwayat memisahkan masalah server dari masalah jaringan, sehingga tidak ada pembelian hardware yang sia-sia.
• Kantor dan UMKM: server aplikasi kasir atau stok. Grafik 14 hari cukup untuk menjawab "sejak kapan lambat" saat pemilik bertanya.
• Hosting dan VPS kecil: paket 1 vCPU membuat load 1,0 sudah berarti penuh. Alarm otomatis mencegah pembelian paket lebih besar tanpa bukti.
• Industri/manufaktur: server produksi atau mesin tidak boleh berhenti mendadak. Alarm dikirim ke operator, bukan ditunggu di dashboard.
• ISP dan NOC: banyak server dipantau dari satu titik. Netdata mendukung model parent-child, jadi agen di tiap server mengirim data ke satu penampung.
• Freelancer dan remote worker: cukup satu VPS. Terowongan SSH membuat dashboard bisa dibuka dari HP tanpa membuka port ke internet.

🔥 Kasus nyata: sebuah distributor membuka dashboard Netdata ke internet "biar bisa dipantau dari rumah". Tiga minggu kemudian log akses menunjukkan percobaan login ke aplikasi internal yang alamatnya hanya terlihat dari dashboard. Port ditutup, akses dipindah ke VPN, dan daftar allow connections from dipersempit ke jaringan kantor.

✅ Verifikasi

Cek satu per satu; jangan lanjut kalau baris sebelumnya belum benar.

Yang diperiksa	Perintah	Hasil yang diharapkan
Load vs kapasitas	uptime; nproc	Kamu bisa menyebut load per core
Memori tersedia	free -m	Kamu membaca kolom available, bukan free
Tekanan I/O	vmstat 1 3	Kolom wa dan si/so terbaca
Tekanan kernel	cat /proc/pressure/io	Ada baris some dan full
htop interaktif	htop --readonly	Meter dan daftar proses tampil, tidak bisa kill
Netdata hidup	systemctl is-active netdata	active
Port benar	grep 19999	Hanya lokal atau alamat VPN
Retensi terbaca	curl -s localhost:19999/netdata.conf	Bagian [db] muncul
Alarm terdaftar	curl -s localhost:19999/api/v1/alarms	Nama alarm buatanmu ada
Riwayat terbukti	dashboard rentang 3 jam	Kurva beban uji tadi masih terlihat

⚠️ Kesalahan umum & troubleshooting

Lima jebakan yang paling sering terjadi:

• Melihat load tanpa membagi jumlah core. Load 6 di 16 core masih wajar; di 2 core sudah kritis.
• Menganggap CPU% 100 berarti semua core penuh. Itu 100 persen dari satu core.
• Membaca kolom free di free -m. Cache bisa dilepas; yang menentukan adalah available.
• Memasang alarm sebelum punya baseline. Ambang 85 persen terasa masuk akal, padahal server normalnya sudah 88 persen.
• Mengubah netdata.conf lalu hanya menjalankan reload-health. Perubahan netdata.conf butuh restart; reload-health hanya membaca ulang berkas alarm.

Gejala	Penyebab sering	Cek cepat
htop: command not found	Paket belum ada	sudo apt-get install htop
Load tinggi, CPU rendah	Menunggu disk	vmstat 1 5, lihat kolom wa
Server terasa lambat, semua angka wajar	Swap sudah terpakai	free -m, lihat baris Swap
Daftar proses dobel	Thread ditampilkan	Tekan H di htop
Netdata tidak aktif	Instalasi gagal di tengah	systemctl status netdata, journalctl -u netdata
Dashboard tidak terbuka dari luar	Dibatasi allow connections from	curl -sI localhost:19999 dari server
Grafik kosong setelah restart	db = ram	curl -s localhost:19999/netdata.conf
Retensi lebih pendek dari perkiraan	Batas ukuran tercapai lebih dulu	Periksa ukuran tier dan laju metric
Alarm tidak pernah berbunyi	to: belum dikonfigurasi	Lihat status alarm di dashboard
Netdata makan disk	Bawaan 3 GiB metric	Kecilkan ukuran tier bila perlu

🧪 Uji cepat: kalau ragu antara "server sibuk" dan "server menunggu", jalankan vmstat 1 5. Kolom r besar berarti antrean CPU; kolom b dan wa besar berarti menunggu disk.

🔐 Catatan keamanan & etika

• Port 19999 bukan halaman publik. Bawaan allow connections from = localhost * artinya hampir semua alamat cocok. Selama port bisa dijangkau, dashboard bisa dibuka. Batasi lewat firewall atau VPN.
• Dashboard adalah peta infrastruktur. Hostname, alamat IP, nama layanan, dan daftar container terlihat di sana. Informasi itu memudahkan penyerang memilih sasaran.
• Pasang agen dari sumber resmi. Skrip instalasi berjalan sebagai root. Simpan berkasnya, periksa isinya, dan jangan menjalankan skrip yang diambil dari tautan acak.
• Agen butuh akses baca luas. Sebagian collector membaca /proc dan statistik sistem. Jalankan sebagai user netdata, jangan sebagai root penuh tanpa alasan.
• Metric bisa menyentuh privasi. Plugin aplikasi dapat menampilkan aktivitas per user. Di lab bersama, jelaskan ke pengguna bahwa aktivitas dipantau.
• Uji hanya di mesin sendiri. Membuat beban CPU atau memori di server orang lain tanpa izin sama dengan sengaja memperlambat layanan.
• Alarm jangan dikirim ke kanal publik. Nama host dan alamat IP internal sebaiknya tidak muncul di grup terbuka.

📌 Kesimpulan

htop menjawab "sekarang". Netdata menjawab "sejak kapan". Keduanya tidak saling menggantikan, dan justru paling kuat saat dipakai berurutan: htop untuk menemukan tersangka, Netdata untuk membuktikan kapan dan seberapa lama.

Yang membuat monitoring berguna bukan jumlah grafik, tapi adanya baseline, retensi yang cukup, dan alarm yang pernah diuji. Grafik tanpa ambang cuma hiasan; ambang tanpa riwayat cuma tebakan.

Langkah berikutnya: ambil baseline server yang sedang kamu pegang hari ini, lalu tentukan satu saja alarm yang paling relevan — biasanya memori atau kapasitas disk.

🔗 Materi terkait

• Linux : Perintah htop — dasar tombol dan opsi htop.
• Linux : Perintah uptime — membaca load average dan waktu aktif.
• Linux : Log dan journalctl untuk Troubleshooting — bukti kejadian setelah monitoring menunjukkan jamnya.
• Linux : Membuat Service Sendiri dengan systemd — menjadikan pemantau buatan sendiri sebagai layanan.
• Linux : Disk, Partisi, dan Filesystem (Mount dan fstab) — saat alarm kapasitas disk berbunyi.
• Linux : SSH Hardening Lanjutan (Lima Lapis Kunci Akses) — mengamankan akses ke dashboard.
• Linux : Monitoring Server dengan Prometheus — alternatif dengan model tarik data.
• Linux : Monitoring Server dengan Cacti — alternatif berbasis grafik RRDtool.

📚 Referensi

• htop(1) — Debian bookworm. Opsi -d, --readonly, -F, kolom PERCENT_CPU dan PERCENT_NORM_CPU.
• uptime(1) — procps, Debian bookworm. Definisi load average dan catatan tidak dinormalisasi per CPU.
• top(1) — procps, Debian bookworm. Penjelasan Irix mode dan Solaris mode.
• Netdata — Daemon Configuration Reference, [global] dan [db]: update every, storage tiers, retensi per tier.
• Netdata — Disk Requirements & Retention: bawaan 3 GiB, tier 0 14 hari, tier 1 3 bulan, tier 2 2 tahun.
• Netdata — Configure Health Alerts: format alarm, lookup, warn, crit, dan netdatacli reload-health.
• Netdata — Web Server Reference: port 19999 dan allow connections from.
• Linux kernel — Pressure Stall Information, /proc/pressure/cpu, io, memory.