Monitoring Sistem

Bab 37 ditutup dengan sebuah konsekuensi yang wajar: begitu cloud-init membuat provisioning VM baru semudah menulis satu file user-data, jumlah server yang dikelola cenderung bertambah cepat, dan kebiasaan lama memeriksa kesehatan server satu per satu lewat SSH mulai kewalahan mengimbanginya. Pola kerja reaktif seperti itu sebenarnya sudah kita praktikkan tanpa sadar sejak awal series ini, login lewat SSH, jalankan top sekilas, lalu logout lagi begitu servernya terlihat baik-baik saja. Cara ini masih masuk akal untuk satu atau dua server, tetapi mustahil diskalakan begitu jumlah server bertambah menjadi puluhan, apalagi kalau baru diperiksa setelah ada laporan masalah. Monitoring hadir untuk mengubah pola kerja ini dari reaktif menjadi proaktif, yaitu mengumpulkan data kondisi server secara berkelanjutan, sehingga masalah bisa terdeteksi sebelum berdampak ke user, bukan sesudahnya.

Skenario ini sangat akrab bagi Sysadmin yang mengelola server produksi. Developer melaporkan aplikasi terasa lambat sejak pagi, sementara User dan Client sudah mulai mengeluh lewat tiket support. Tanpa data historis, Sysadmin hanya bisa menebak, apakah CPU yang penuh, memory yang habis, atau disk I/O yang menjadi bottleneck. Monitoring yang tepat menjawab pertanyaan itu dalam hitungan detik lewat grafik yang sudah merekam kondisi server jauh sebelum keluhan pertama masuk, bahkan idealnya Sysadmin sudah tahu dan bertindak sebelum Developer sempat melapor sama sekali.

Bab ini dimulai dari tool command line klasik seperti htop, vmstat, dan iostat yang tetap relevan untuk investigasi cepat lewat SSH, lalu naik ke Netdata sebagai contoh monitoring modern yang menyajikan dashboard real-time nyaris tanpa konfigurasi. Dari situ, kita berkenalan dengan konsep dasar Prometheus dan Grafana, kombinasi stack monitoring yang jadi standar de facto industri untuk mengawasi banyak server sekaligus dari satu tempat terpusat, sebuah kebutuhan nyata begitu armada server bertambah lewat cloud-init pada Bab 37. Bab ditutup dengan alerting sederhana, langkah terakhir yang mengubah data monitoring pasif menjadi notifikasi aktif, sehingga Sysadmin diberi tahu duluan, bukan menunggu keluhan Developer maupun User.

38.1 Monitoring Dasar: htop, vmstat, dan iostat

38.1.1 Kenapa Monitoring dari Command Line Tetap Relevan

Sebelum masuk ke dashboard modern pada Bagian 38.2 dan 38.3, penting menguasai lebih dulu tiga tool command line yang sudah jadi standar investigasi cepat sysadmin selama puluhan tahun. Ketiganya ringan, nyaris tidak membebani server yang justru sedang bermasalah, dan tetap bisa dijalankan lewat sesi SSH biasa tanpa bergantung pada service tambahan yang mungkin belum terpasang atau justru ikut bermasalah saat server sedang kritis. Di lapangan, momen paling umum tool ini dipakai adalah saat alert dari Grafana pada Bagian 38.4 baru saja masuk, dan langkah pertama Sysadmin tetap sama seperti dahulu, yaitu SSH ke server yang bersangkutan lalu memeriksa kondisinya secara langsung.

38.1.2 Memantau CPU dan Memory Real-Time dengan htop

htop adalah versi interaktif dari perintah top bawaan Linux, menampilkan daftar proses yang bisa di-scroll, disortir, dan langsung di-kill dari dalam tampilannya sendiri, jauh lebih nyaman dibanding top polos yang antarmukanya lebih kaku.

Langkah Praktik

1. Pasang htop, karena paket ini tidak ikut terpasang secara default pada instalasi dasar Ubuntu Server sejak Bab 2.

   sudo apt install -y htop

2. Jalankan htop tanpa argumen apa pun.

   htop

3. Perhatikan bagian atas layar yang menampilkan meter CPU per core, penggunaan memory (Mem), dan swap (Swp), sementara bagian bawah menampilkan daftar proses lengkap dengan kolom %CPU, %MEM, dan COMMAND.
4. Tekan F6 untuk mengurutkan daftar proses berdasarkan kolom tertentu, misalnya %MEM saat mencurigai kebocoran memory pada salah satu proses PHP-FPM dari Bab 14.
5. Tekan t untuk beralih ke tampilan tree, memperlihatkan relasi induk-anak antar proses, berguna untuk melihat proses worker mana saja yang lahir dari satu proses master Nginx pada Bab 12.
6. Tekan q untuk keluar.

Verifikasi dan Troubleshooting

• Kolom RES jauh lebih akurat dibanding VIRT untuk menilai pemakaian memory riil sebuah proses. VIRT mencakup seluruh alamat memory virtual yang dipetakan proses, termasuk shared library yang dipakai bersama proses lain, sehingga angkanya sering terlihat jauh lebih besar dari memory fisik yang benar-benar terpakai.
• Proses dengan status D pada kolom S (state) yang bertahan lama biasanya sedang menunggu operasi I/O disk, sebuah petunjuk awal untuk beralih memeriksa iostat pada Bagian 38.1.4.
• Baris Load average di pojok kanan atas layar menampilkan tiga angka, berturut-turut rata-rata jumlah proses yang antre dalam 1, 5, dan 15 menit terakhir. Patokan kasar yang lazim dipakai di lapangan adalah membandingkan angka pertama dengan jumlah core CPU server, angka 4.00 pada server dengan 4 core tergolong penuh tapi masih wajar, sementara angka yang sama pada server 2 core sudah menandakan antrean CPU yang cukup serius.

38.1.3 Membaca Statistik Sistem dengan vmstat

vmstat merangkum kondisi CPU, memory, dan swap seluruh sistem dalam satu baris ringkas per interval, cocok untuk melihat tren beban tanpa perlu men-scroll daftar proses satu per satu seperti htop. Berbeda dari htop, vmstat merupakan bagian dari paket procps yang tergolong essential, sehingga sudah tersedia secara default sejak instalasi dasar Ubuntu Server pada Bab 2 tanpa perlu dipasang terpisah.

Langkah Praktik

1. Jalankan vmstat dengan interval 2 detik, diulang 5 kali.

   vmstat 2 5

Verifikasi dan Troubleshooting

• Kolom r pada bagian procs menunjukkan jumlah proses yang antre menunggu giliran CPU. Angka r yang terus lebih besar dari jumlah core CPU server secara konsisten menandakan CPU benar-benar menjadi bottleneck, bukan sekadar sibuk sesaat.
• Kolom si dan so pada bagian swap paling penting untuk diperhatikan. Angka bukan nol di kedua kolom ini berarti kernel benar-benar sedang menukar data antara RAM dan swap secara aktif, tanda memory fisik sudah tidak mencukupi, jauh lebih meyakinkan dibanding hanya melihat kolom free yang rendah, karena Linux memang sengaja memakai memory kosong untuk page cache dalam kondisi normal.
• Kolom wa pada bagian cpu menunjukkan persentase waktu CPU menunggu operasi I/O selesai. Angka wa yang tinggi mengarahkan kecurigaan ke disk, saatnya lanjut ke iostat pada Bagian 38.1.4 untuk memastikan disk mana yang jadi penyebabnya.

38.1.4 Memantau I/O Disk dengan iostat

iostat membedah beban I/O per disk secara individual, melengkapi ringkasan wa yang sudah terlihat di vmstat dengan detail disk mana sebenarnya yang menjadi penyebabnya.

Langkah Praktik

1. Pasang paket sysstat, sumber perintah iostat yang tidak ikut terpasang secara default.

   sudo apt install -y sysstat

2. Jalankan iostat dengan opsi -x untuk statistik lengkap dan -z untuk menyembunyikan device yang sama sekali tidak ada aktivitas, interval 2 detik diulang 5 kali.

   iostat -xz 2 5

Verifikasi dan Troubleshooting

• Kolom %util mendekati 100 secara terus-menerus menandakan disk yang bersangkutan nyaris selalu sibuk melayani request, indikator paling langsung dari bottleneck I/O.
• Kolom await menunjukkan rata-rata waktu tunggu (dalam milidetik) sebuah request I/O sampai selesai diproses, termasuk waktu antre. Angka await yang jauh lebih tinggi dari biasanya, meski %util belum menyentuh 100, sering jadi tanda awal disk fisik mulai bermasalah, terutama pada storage berbasis HDD yang sudah dibahas karakteristiknya di Bab 7.
• Output baris pertama iostat selalu berisi rata-rata sejak boot terakhir, bukan kondisi saat ini. Abaikan baris pertama ini dan fokus ke baris-baris berikutnya yang benar-benar mencerminkan interval 2 detik yang baru saja berlalu.

38.2 Pengenalan Monitoring Modern: Netdata

38.2.1 Kenapa Perlu Monitoring Modern Selain Tool CLI

Ketiga tool pada Bagian 38.1 punya satu keterbatasan yang sama, yaitu hanya menampilkan kondisi sistem pada saat perintah dijalankan, dan datanya hilang begitu sesi SSH ditutup. Untuk melihat tren sepanjang malam, misalnya menelusuri lonjakan CPU pukul tiga pagi yang sudah lewat, ketiga tool ini tidak banyak membantu tanpa ada yang benar-benar menungguinya secara langsung. Netdata mengisi celah ini sebagai contoh tool monitoring modern open source yang berjalan sebagai service di background, mengumpulkan ribuan metrik per detik, lalu menyajikannya lewat dashboard web yang bisa dibuka kapan saja tanpa perlu tetap terhubung SSH selama proses pengumpulan data berlangsung.

38.2.2 Instalasi Netdata

Netdata menyediakan kickstart script resmi sebagai cara instalasi tercepat, mendeteksi otomatis distro yang dipakai lalu memasang seluruh komponennya sekaligus, mirip pola convenience script Docker yang sudah kita praktikkan pada Bagian 26.1.2.

Langkah Praktik

1. Unduh dulu script-nya secara terpisah agar isinya bisa ditinjau sebelum dieksekusi, kebiasaan baik yang sama seperti saat memasang Docker di Bagian 26.1.2.

   curl https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
   less /tmp/netdata-kickstart.sh

2. Jalankan script dengan opsi --non-interactive agar instalasi berjalan tanpa prompt, termasuk melewati ajakan mendaftarkan node ke Netdata Cloud yang tidak kita butuhkan untuk lab ini.

   sudo sh /tmp/netdata-kickstart.sh --non-interactive

3. Pastikan service netdata aktif dan otomatis menyala saat boot.

   systemctl status netdata

Verifikasi dan Troubleshooting

• Catatan jujur soal keamanan: menjalankan script instalasi lewat sh sebagai root berarti mempercayakan eksekusinya sepenuhnya pada isi script yang diunduh dari internet. Meninjau isinya lebih dulu seperti langkah pertama di atas tetap disarankan, terutama untuk server produksi, sejalan dengan catatan yang sama saat membahas get.docker.com di Bagian 26.1.2.
• Uji dari server itu sendiri tanpa perlu browser, cukup memastikan API Netdata sudah merespons di port bawaannya, 19999.

  curl -s http://localhost:19999/api/v1/info

  Output berupa data JSON berisi versi Netdata dan jumlah chart yang sedang dikumpulkan menandakan service sudah berjalan normal.

38.2.3 Menjelajahi Dashboard Netdata

Dashboard Netdata bisa diakses lewat port 19999, tetapi mengeksposnya langsung ke jaringan luar berarti menambah satu attack surface baru tanpa mekanisme login bawaan, bertentangan dengan prinsip meminimalkan port terbuka yang sudah dibahas di Bab 30 dan 31. Cara paling aman untuk lab ini adalah membuka aksesnya lewat SSH local port forwarding, memanfaatkan koneksi SSH yang memang sudah dipercaya sejak Bab 3, tanpa perlu membuka port tambahan apa pun di UFW.

Langkah Praktik

1. Dari komputer lokal (bukan dari dalam server), buat tunnel SSH yang meneruskan port 19999 lokal ke port 19999 di server.

   ssh -L 19999:localhost:19999 [email protected]

2. Selagi sesi SSH tersebut tetap terbuka, akses dashboard lewat browser di komputer lokal.

   http://localhost:19999

3. Jelajahi bagian System Overview untuk ringkasan CPU, memory, disk, dan network sekaligus, lalu turun ke section Disks untuk melihat grafik %util per disk yang setara dengan output iostat pada Bagian 38.1.4, hanya saja kali ini tersaji sebagai grafik historis yang terus merekam meski tidak sedang dipelototi.

Verifikasi dan Troubleshooting

• Seluruh grafik di dashboard Netdata memperbarui diri tiap detik tanpa perlu me-refresh halaman, memakai resolusi data per second secara default, jauh lebih detail dibanding interval umum 15-60 detik yang biasa dipakai stack monitoring lain seperti Prometheus pada Bagian 38.3.
• Jika koneksi lewat http://localhost:19999 gagal, pastikan sesi SSH pada langkah pertama masih terbuka di terminal terpisah. Menutup sesi SSH tersebut otomatis memutus tunnel-nya, sekalipun service netdata di server sendiri tetap berjalan normal.
• Untuk akses dari beberapa komputer sekaligus di LAN kantor tanpa perlu tunnel satu-satu, alternatifnya adalah membuka port lewat UFW dengan membatasi source ke subnet lokal, mengikuti pola pembatasan subnet yang sama seperti PostgreSQL pada Bagian 18.4.2.

  sudo ufw allow from 192.168.1.0/24 to any port 19999 proto tcp

  Pendekatan tunnel tetap lebih disarankan untuk server yang terekspos ke internet, sementara pola UFW ini lebih cocok untuk server yang memang hanya diakses dari jaringan kantor internal.

38.3 Pengenalan Prometheus dan Grafana (Konsep Dasar)

38.3.1 Arsitektur Prometheus: Pull Model, Exporter, dan Time Series

Netdata pada Bagian 38.2 sangat cocok untuk memantau satu server secara mendalam, tetapi begitu jumlah server bertambah lewat kemudahan cloud-init pada Bab 37, membuka dashboard satu per satu di tiap server jelas tidak praktis. Prometheus menjawab kebutuhan ini sebagai monitoring system dan time series database open source yang dirancang khusus untuk mengumpulkan metrik dari banyak target sekaligus ke satu tempat terpusat.

Perbedaan paling mendasar dari pendekatan Netdata terletak pada arah pengambilan datanya. Prometheus memakai pull model, artinya Prometheus server yang secara aktif mendatangi tiap target lalu menarik (scrape) datanya lewat HTTP pada interval tertentu, kebalikan dari model push di mana target yang mengirim data sendiri ke server pusat. Supaya bisa di-scrape, tiap target perlu menyediakan endpoint /metrics berisi data metrik dalam format teks yang dikenali Prometheus. Komponen yang menyediakan endpoint ini disebut exporter, dan untuk metrik level sistem operasi seperti CPU, memory, dan disk, exporter resminya bernama node_exporter, pada dasarnya menyajikan data yang konsepnya sama seperti yang sudah dibaca manual lewat vmstat dan iostat pada Bagian 38.1, hanya saja kini tersedia dalam format yang bisa ditarik otomatis dari jarak jauh.

38.3.2 Instalasi Prometheus dan Node Exporter

Langkah Praktik

1. Pasang Prometheus server beserta node_exporter dari repository resmi Ubuntu.

   sudo apt update
   sudo apt install -y prometheus prometheus-node-exporter

2. Periksa kedua service sudah aktif secara otomatis setelah instalasi.

   systemctl status prometheus prometheus-node-exporter

3. Buka file konfigurasi utama Prometheus.

   sudo nano /etc/prometheus/prometheus.yml

4. Tambahkan blok job_name baru di dalam scrape_configs agar Prometheus ikut menarik metrik dari node_exporter yang berjalan di port 9100, di bawah job prometheus bawaan yang memantau dirinya sendiri di port 9090.

   scrape_configs:
     - job_name: prometheus
       static_configs:
         - targets: ['localhost:9090']
   
     - job_name: node
       static_configs:
         - targets: ['localhost:9100']

5. Muat ulang konfigurasi dengan restart service Prometheus.

   sudo systemctl restart prometheus

Verifikasi dan Troubleshooting

• Pastikan Prometheus server sendiri sehat lewat endpoint health check bawaannya.

  curl http://localhost:9090/-/healthy

  Output Prometheus Server is Healthy. menandakan service berjalan normal.
• Buka halaman http://192.168.1.10:9090/targets lewat browser (memakai SSH tunnel atau rule UFW seperti pola Bagian 38.2.3 bila diakses dari luar server) untuk memastikan kedua job, prometheus dan node, berstatus UP. Status DOWN pada job node biasanya berarti service prometheus-node-exporter belum aktif atau port 9100-nya belum bisa dijangkau.
• Kesalahan indentasi YAML pada prometheus.yml membuat service gagal start sama sekali. Jalankan sudo systemctl status prometheus setelah restart dan periksa sudo journalctl -u prometheus -n 50 bila service tidak kunjung active, pola troubleshooting yang sama seperti dibahas untuk service systemd lain sejak Bab 5.

38.3.3 Instalasi Grafana dan Menghubungkan Data Source Prometheus

Prometheus pada Bagian 38.3.2 memang punya web interface bawaan, tetapi kemampuan visualisasinya sangat terbatas. Grafana melengkapi Prometheus sebagai tool visualisasi open source yang jauh lebih kaya, mampu menyusun dashboard dari berbagai data source sekaligus, termasuk Prometheus. Grafana tidak tersedia di repository resmi Ubuntu, sehingga perlu ditambahkan lewat repository APT resminya sendiri, mengikuti pola GPG key dan repository yang sama seperti dipraktikkan untuk MongoDB pada Bagian 21.2.

Langkah Praktik

1. Pasang dependency yang dibutuhkan, lalu tambahkan GPG key resmi Grafana.

   sudo apt install -y apt-transport-https software-properties-common wget
   sudo mkdir -p /etc/apt/keyrings/
   wget -q -O - https://apt.grafana.com/gpg.key | gpg --dearmor | sudo tee /etc/apt/keyrings/grafana.gpg > /dev/null

2. Daftarkan repository resmi Grafana.

   echo "deb [signed-by=/etc/apt/keyrings/grafana.gpg] https://apt.grafana.com stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list

3. Perbarui daftar paket lalu pasang Grafana.

   sudo apt update
   sudo apt install -y grafana

4. Aktifkan dan jalankan service-nya.

   sudo systemctl enable --now grafana-server

5. Buka dashboard Grafana lewat browser di port 3000, memakai SSH tunnel atau rule UFW yang sama seperti pola Bagian 38.2.3, lalu login memakai user dan password default admin/admin. Grafana langsung memaksa penggantian password pada login pertama ini.
6. Setelah login, buka menu Connections > Data sources > Add data source, pilih Prometheus, isi kolom URL dengan http://localhost:9090 karena Grafana dan Prometheus berjalan di server yang sama, lalu klik Save & test.

Verifikasi dan Troubleshooting

• Pesan Successfully queried the Prometheus API setelah Save & test menandakan koneksi data source sudah benar. Pesan error koneksi biasanya berarti URL yang dimasukkan keliru atau service Prometheus belum berjalan, cek ulang dengan curl http://localhost:9090/-/healthy seperti Bagian 38.3.2.
• Di lingkungan produksi sungguhan, Prometheus dan Grafana lazimnya dipisah ke server tersendiri di luar server aplikasi yang dipantau, agar beban monitoring tidak ikut mengganggu resource aplikasi utama. Menjalankan keduanya di satu server yang sama pada bab ini murni demi kesederhanaan lab, bukan pola yang disarankan untuk skala produksi dengan banyak server.

38.3.4 Membuat Dashboard Sederhana di Grafana

Langkah Praktik

1. Buka menu Dashboards > New > Import.
2. Isi kolom Import via grafana.com dengan ID 1860, yaitu ID dashboard komunitas Node Exporter Full, salah satu dashboard paling populer untuk memvisualisasikan metrik node_exporter secara lengkap tanpa perlu menyusun panel satu per satu dari nol.
3. Pilih data source Prometheus yang sudah dibuat pada Bagian 38.3.3 saat diminta, lalu klik Import.

Verifikasi dan Troubleshooting

• Dashboard yang berhasil di-import langsung menampilkan puluhan panel berisi grafik CPU, memory, disk, dan network dari node_exporter, terisi data nyata dalam beberapa saat mengikuti interval scrape yang sudah diatur di prometheus.yml pada Bagian 38.3.2.
• Panel yang tampil kosong atau bertuliskan No data biasanya berarti data source yang dipilih saat import keliru, atau job node pada Prometheus belum berstatus UP seperti diperiksa pada Bagian 38.3.2.
• Dashboard komunitas seperti ini sangat baik sebagai titik awal karena sudah mencakup hampir semua metrik penting node_exporter, tetapi tetap layak disesuaikan lebih lanjut begitu kebutuhan monitoring semakin spesifik, misalnya menambah panel khusus untuk metrik aplikasi Nginx atau PostgreSQL yang tidak tercakup node_exporter.

38.4 Alerting Sederhana

38.4.1 Konsep Alerting: Threshold, Kondisi, dan Notification Channel

Dashboard secanggih apa pun pada Bagian 38.2 dan 38.3 tetap punya satu kelemahan, yaitu hanya berguna selama ada yang benar-benar melihatnya. Alerting menutup celah ini dengan mengevaluasi kondisi tertentu terhadap metrik secara otomatis dan berkelanjutan, lalu mengirim notifikasi begitu kondisi tersebut terpenuhi, tanpa perlu ada Sysadmin yang sedang memelototi dashboard secara langsung. Tiga elemen inti alerting adalah threshold, yaitu batas nilai yang jadi acuan (misalnya penggunaan disk di atas 90%), kondisi evaluasi, yaitu berapa lama threshold tersebut harus terlampaui sebelum benar-benar dianggap masalah, dan notification channel atau contact point, yaitu ke mana notifikasi tersebut dikirim, misalnya email, Slack, atau Telegram.

38.4.2 Alert Bawaan Netdata dan Cara Memeriksanya

Salah satu kelebihan Netdata dari Bagian 38.2 adalah puluhan health check siap pakai yang otomatis aktif begitu instalasi selesai, mencakup skenario umum seperti pemakaian CPU tinggi berkepanjangan, memory nyaris habis, hingga disk yang hampir penuh, seluruhnya tanpa perlu satu baris konfigurasi tambahan.

Langkah Praktik

1. Dari server yang sama, periksa daftar seluruh alarm yang dipantau Netdata lewat API-nya, termasuk yang berstatus normal. Tambahkan parameter ?all, karena tanpa parameter ini API hanya menampilkan alarm yang sedang tidak normal (WARNING atau CRITICAL).

   curl -s http://localhost:19999/api/v1/alarms?all | less

2. Buka dashboard Netdata seperti Bagian 38.2.3, lalu lihat tab Alarms di sisi kanan untuk melihat daftar yang sama dalam tampilan visual, lengkap dengan status warna tiap alarm.

Verifikasi dan Troubleshooting

• Status CLEAR pada tiap alarm menandakan kondisi masih normal. Status berubah menjadi WARNING atau CRITICAL begitu threshold bawaannya terlampaui, dan berubah warna jadi kuning atau merah di dashboard, tanpa perlu konfigurasi tambahan apa pun karena memang sudah didefinisikan Netdata sejak awal di direktori /etc/netdata/health.d/.
• Notifikasi alarm ini secara default hanya tampil di dashboard, belum otomatis terkirim ke email atau Slack. Mengaktifkan pengiriman notifikasi keluar memerlukan konfigurasi tambahan di /etc/netdata/health_alarm_notify.conf, di luar cakupan bab ini, tetapi threshold dan evaluasi kondisinya sendiri sudah berjalan penuh sejak instalasi.

38.4.3 Membuat Alert Rule di Grafana untuk Metrik Prometheus

Berbeda dari alarm bawaan Netdata yang sudah otomatis aktif, Grafana Alerting memerlukan alert rule yang didefinisikan sendiri sesuai metrik yang relevan. Bagian ini mempraktikkan skenario paling umum sekaligus paling penting untuk dipantau, yaitu mendeteksi ketika sebuah target berhenti mengirim metrik sama sekali, tanda paling awal server tersebut sedang bermasalah atau bahkan mati.

Langkah Praktik

1. Buka menu Alerting > Alert rules > New alert rule.
2. Pada bagian query, pilih data source Prometheus, lalu tulis ekspresi PromQL berikut untuk mendeteksi target node yang statusnya down.

   up{job="node"} == 0

3. Atur Evaluation group dan interval evaluasi, misalnya tiap 1m, lalu isi Pending period selama 1m juga, artinya kondisi harus bertahan minimal 1 menit sebelum alert dianggap benar-benar Firing, menghindari false alarm akibat gangguan jaringan sesaat.
4. Beri nama alert rule, misalnya Node Exporter Down, lalu simpan.

Verifikasi dan Troubleshooting

• Uji alert rule ini secara nyata dengan mematikan sementara node_exporter.

  sudo systemctl stop prometheus-node-exporter

• Tunggu selama Pending period yang sudah diatur, lalu periksa halaman Alerting > Alert rules. Status alert rule Node Exporter Down semestinya berubah dari Normal menjadi Pending, lalu Firing setelah kondisinya bertahan cukup lama.
• Nyalakan kembali node_exporter, lalu pastikan status alert kembali ke Normal begitu Prometheus berhasil scrape target tersebut lagi.

  sudo systemctl start prometheus-node-exporter

• Catatan jujur soal batasan demonstrasi ini: alert rule di atas sudah terbukti berpindah status dengan benar, tetapi belum benar-benar mengirim notifikasi ke mana pun karena contact point default Grafana memerlukan konfigurasi SMTP server di grafana.ini yang belum kita siapkan. Untuk lingkungan produksi, langkah lanjutannya adalah menyambungkan contact point ke email lewat SMTP relay atau webhook Slack/Telegram, sesuatu yang sengaja tidak dibahas mendalam di sini karena bergantung penuh pada infrastruktur notifikasi masing-masing organisasi.

Sampai di sini, kita sudah menempuh seluruh spektrum monitoring, dari tool command line klasik untuk investigasi cepat lewat SSH, Netdata sebagai dashboard modern siap pakai untuk satu server, hingga Prometheus dan Grafana sebagai stack terpusat untuk mengawasi banyak server sekaligus, ditutup dengan alerting yang mengubah data pasif menjadi notifikasi aktif. Namun demikian, metrik numerik seperti yang sudah kita kumpulkan sepanjang bab ini punya batasan mendasar, yaitu hanya menjawab pertanyaan apa yang terjadi, misalnya CPU melonjak atau target down, tanpa pernah menjelaskan mengapa hal itu terjadi. Menjawab pertanyaan mengapa itulah yang menjadi tugas log, dan mengelola log dari banyak server sekaligus secara terpusat menjadi topik yang dibahas tuntas pada Bab 39 berikutnya.