Maintenance script: Konsep inti: monitoring server dasar dengan htop dan netdata

2026-11-12T00:02:16Z

Konsep inti: monitoring server dasar dengan htop dan netdata

New page

'''Monitoring server''' sering dianggap pekerjaan "buka <code>htop</code>, lihat angka, tutup". Padahal <code>htop</code> 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 <code>htop</code> atau <code>uptime</code>, baca dulu dua halaman dasarnya di bagian Materi terkait.

__TOC__

== 🎯 Tujuan ==
Setelah membaca dan mempraktikkan artikel ini, kamu bisa:

* menjelaskan beda '''potret sesaat''' dan '''riwayat''' dalam monitoring, plus kapan masing-masing dipakai;
* membaca layar <code>htop</code> 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 <code>htop</code> di server dan melihat angka CPU '''4 persen'''. Kesimpulan cepat: "server sehat, pasti jaringannya."

[[File:Tux.png|thumb|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 <code>htop</code> 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: <code>htop</code> 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 <code>htop</code> menunjukkan CPU 4 persen. Kenyataannya <code>vmstat</code> menunjukkan <code>wa</code> (wait I/O) 60 persen dan swap terpakai 1,9 GB karena <code>innodb_buffer_pool_size</code> 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:

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

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

{| class="wikitable"
! 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 ===
{| class="wikitable"
! Alat !! Menyimpan riwayat? !! Paling cocok untuk
|-
| <code>top</code> / <code>htop</code> || Tidak, hilang saat ditutup || Melihat kondisi sekarang dan mencari proses rakus
|-
| <code>sar</code> (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
|}

<code>sar</code> 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:''' <code>uptime</code> 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 <code>nproc</code> 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:''' <code>htop</code> menampilkan <code>CPU%</code> '''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:
<syntaxhighlight lang="text">
uptime; nproc
free -m
vmstat 1 3
cat /proc/pressure/io
</syntaxhighlight>
Kalau load tinggi tapi kolom <code>id</code> di <code>vmstat</code> 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, <code>sar</code> 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 <code>sudo</code>.

=== 🔹 Langkah 0: potret baseline ===
Simpan kondisi awal ke satu berkas, supaya nanti bisa dibandingkan.

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

=== 🔹 Langkah 1: membaca layar htop dengan benar ===
Jalankan <code>htop</code>, lalu baca dari atas ke bawah, bukan dari daftar proses.

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

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

=== 🔹 Langkah 2: kunci htop yang menghemat waktu ===
<syntaxhighlight lang="text">
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
</syntaxhighlight>

Di dalam <code>htop</code>, tombol yang paling sering dipakai:

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

📊 '''Angka penting:''' opsi <code>-d</code> 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:

<syntaxhighlight lang="text">
for i in $(seq 1 "$(nproc)"); do
timeout 90 bash -c 'while :; do :; done' &
done
htop --readonly
</syntaxhighlight>

Di terminal lain, lihat perubahan angkanya:

<syntaxhighlight lang="text">
uptime
vmstat 1 3
</syntaxhighlight>

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

=== 🔹 Langkah 4: membuktikan htop tidak punya riwayat ===
Ini bagian yang paling penting untuk dipahami.

# Saat beban masih jalan, catat angka load di <code>htop</code>.
# Tutup <code>htop</code> dengan <code>q</code>.
# Tunggu beban selesai, lalu buka <code>htop</code> lagi.

Angka load sudah turun, dan '''tidak ada satu pun jejak''' bahwa tadi ada lonjakan. Bukan bug — <code>htop</code> 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.

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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

Verifikasi cepat:

<syntaxhighlight lang="text">
systemctl is-active netdata
ss -tlnp | grep 19999
curl -s localhost:19999/api/v1/info
</syntaxhighlight>

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

<syntaxhighlight lang="text">
ssh -L 19999:localhost:19999 server@192.168.100.240
</syntaxhighlight>

Lalu buka <code>http://localhost:19999</code> 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 <code>system.cpu</code>, <code>system.ram</code>, <code>disk.io</code>, dan <code>system.io</code> 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:

<syntaxhighlight lang="text">
sudo /etc/netdata/edit-config netdata.conf
</syntaxhighlight>

Cari bagian <code>[db]</code>. Nilai bawaan yang perlu kamu tahu:

{| class="wikitable"
! Pengaturan !! Bawaan !! Arti
|-
| <code>db</code> || <code>dbengine</code> || Data disimpan di disk, bukan cuma di RAM
|-
| <code>update every</code> || 1 || Satu sampel per detik
|-
| <code>storage tiers</code> || 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:

<syntaxhighlight lang="text">
curl -s localhost:19999/netdata.conf | grep -A15 '\[db\]'
</syntaxhighlight>

⚠️ '''Hati-hati:''' kalau <code>db</code> diubah jadi <code>ram</code>, 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 <code>health.d/</code>. Buat satu alarm pemakaian RAM:

<syntaxhighlight lang="text">
sudo /etc/netdata/edit-config health.d/ram-usage.conf
</syntaxhighlight>

Isinya:

<syntaxhighlight lang="text">
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
</syntaxhighlight>

Terapkan tanpa restart, supaya tidak ada lubang data:

<syntaxhighlight lang="text">
sudo netdatacli reload-health
curl -s localhost:19999/api/v1/alarms
</syntaxhighlight>

Perhatikan baris <code>to: sysadmin</code>. 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:

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

Sambil menunggu, pantau di terminal lain:

<syntaxhighlight lang="text">
watch -n 2 'free -m | head -2; curl -s localhost:19999/api/v1/alarms | head -c 300'
</syntaxhighlight>

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

=== 🔹 Langkah 10: bersih-bersih ===
<syntaxhighlight lang="text">
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
</syntaxhighlight>

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 <code>allow connections from</code> dipersempit ke jaringan kantor.

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

{| class="wikitable"
! Yang diperiksa !! Perintah !! Hasil yang diharapkan
|-
| Load vs kapasitas || <code>uptime; nproc</code> || Kamu bisa menyebut load per core
|-
| Memori tersedia || <code>free -m</code> || Kamu membaca kolom <code>available</code>, bukan <code>free</code>
|-
| Tekanan I/O || <code>vmstat 1 3</code> || Kolom <code>wa</code> dan <code>si/so</code> terbaca
|-
| Tekanan kernel || <code>cat /proc/pressure/io</code> || Ada baris <code>some</code> dan <code>full</code>
|-
| htop interaktif || <code>htop --readonly</code> || Meter dan daftar proses tampil, tidak bisa kill
|-
| Netdata hidup || <code>systemctl is-active netdata</code> || <code>active</code>
|-
| Port benar || <code>ss -tlnp | grep 19999</code> || Hanya lokal atau alamat VPN
|-
| Retensi terbaca || <code>curl -s localhost:19999/netdata.conf</code> || Bagian <code>[db]</code> muncul
|-
| Alarm terdaftar || <code>curl -s localhost:19999/api/v1/alarms</code> || 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 <code>CPU%</code> 100 berarti semua core penuh.''' Itu 100 persen dari satu core.
* '''Membaca kolom <code>free</code> di <code>free -m</code>.''' Cache bisa dilepas; yang menentukan adalah <code>available</code>.
* '''Memasang alarm sebelum punya baseline.''' Ambang 85 persen terasa masuk akal, padahal server normalnya sudah 88 persen.
* '''Mengubah <code>netdata.conf</code> lalu hanya menjalankan <code>reload-health</code>.''' Perubahan <code>netdata.conf</code> butuh restart; <code>reload-health</code> hanya membaca ulang berkas alarm.

{| class="wikitable"
! Gejala !! Penyebab sering !! Cek cepat
|-
| <code>htop: command not found</code> || Paket belum ada || <code>sudo apt-get install htop</code>
|-
| Load tinggi, CPU rendah || Menunggu disk || <code>vmstat 1 5</code>, lihat kolom <code>wa</code>
|-
| Server terasa lambat, semua angka wajar || Swap sudah terpakai || <code>free -m</code>, lihat baris Swap
|-
| Daftar proses dobel || Thread ditampilkan || Tekan <code>H</code> di <code>htop</code>
|-
| Netdata tidak aktif || Instalasi gagal di tengah || <code>systemctl status netdata</code>, <code>journalctl -u netdata</code>
|-
| Dashboard tidak terbuka dari luar || Dibatasi <code>allow connections from</code> || <code>curl -sI localhost:19999</code> dari server
|-
| Grafik kosong setelah restart || <code>db = ram</code> || <code>curl -s localhost:19999/netdata.conf</code>
|-
| Retensi lebih pendek dari perkiraan || Batas ukuran tercapai lebih dulu || Periksa ukuran tier dan laju metric
|-
| Alarm tidak pernah berbunyi || <code>to:</code> 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 <code>vmstat 1 5</code>. Kolom <code>r</code> besar berarti antrean CPU; kolom <code>b</code> dan <code>wa</code> besar berarti menunggu disk.

== 🔐 Catatan keamanan & etika ==
* '''Port 19999 bukan halaman publik.''' Bawaan <code>allow connections from = localhost *</code> 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 <code>/proc</code> dan statistik sistem. Jalankan sebagai user <code>netdata</code>, 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 ==
<code>htop</code> menjawab "sekarang". Netdata menjawab "sejak kapan". Keduanya tidak saling menggantikan, dan justru paling kuat saat dipakai berurutan: <code>htop</code> 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 <code>htop</code>.
* [[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 ==
* <code>htop(1)</code> — Debian bookworm. Opsi <code>-d</code>, <code>--readonly</code>, <code>-F</code>, kolom <code>PERCENT_CPU</code> dan <code>PERCENT_NORM_CPU</code>.
* <code>uptime(1)</code> — procps, Debian bookworm. Definisi load average dan catatan tidak dinormalisasi per CPU.
* <code>top(1)</code> — procps, Debian bookworm. Penjelasan Irix mode dan Solaris mode.
* Netdata — ''Daemon Configuration Reference'', <code>[global]</code> dan <code>[db]</code>: <code>update every</code>, <code>storage tiers</code>, 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 <code>alarm</code>, <code>lookup</code>, <code>warn</code>, <code>crit</code>, dan <code>netdatacli reload-health</code>.
* Netdata — ''Web Server Reference'': port 19999 dan <code>allow connections from</code>.
* Linux kernel — ''Pressure Stall Information'', <code>/proc/pressure/cpu</code>, <code>io</code>, <code>memory</code>.

[[Category:TKJ]]
[[Category:Linux]]
[[Category:Server]]
[[Category:Monitoring]]

Linux : Monitoring Server Dasar (htop, netdata) - Revision history

Maintenance script: Protected "Linux : Monitoring Server Dasar (htop, netdata)": Proteksi editorial: edit/move sysop ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))

Maintenance script: Konsep inti: monitoring server dasar dengan htop dan netdata

← Older revision	Revision as of 07:02, 12 November 2026
(No difference)