Monitoring & Observabilitas Server

Konteks & Ringkasan

Pada lingkungan hosting game berkepadatan tinggi dan server virtual, kendala teknis dapat terjadi tiba-tiba — thread aplikasi yang macet atau I/O disk yang jenuh bisa memperburuk latensi ratusan pemain dalam hitungan detik. Agen pemantau komersial yang berat membutuhkan alokasi memori signifikan yang kurang efisien untuk server berkapasitas hemat. Kondisi ini mendorong perancangan kolektor telemetri khusus yang ringan dan sistem notifikasi terpusat via webhook Discord.

Peran & Tanggung Jawab

• Merancang arsitektur pengumpulan metrik terdistribusi pada beberapa node host secara serentak.
• Mengembangkan skrip shell berbobot ringan yang membaca data /proc dan penghitung kernel secara langsung tanpa membebani CPU host.
• Membangun layanan agregasi pusat menggunakan Node.js dan pola pub/sub Redis.
• Menyusun alur notifikasi webhook cerdas dengan logika debounce agar tidak terjadi banjir pesan saat lonjakan beban sementara.
• Mengonfigurasi isolasi unit layanan systemd serta mekanisme restart otomatis saat terjadi kegagalan proses.

Permasalahan & Tantangan Operasional

• Beban Konsumsi Memori: Paket pemantauan umum (seperti Prometheus node_exporter standar) memakan hingga 300MB RAM di setiap server, mengurangi ruang komputasi yang tersedia bagi beban kerja inti.
• Kelelahan Notifikasi (Alert Fatigue): Peringatan berbasis ambang batas kaku memicu pesan beruntun saat memori naik sesaat selama proses penyimpanan data game atau restart berkala.
• Deteksi yang Terlambat: Operator kerap baru mengetahui gangguan setelah adanya laporan komplain pengguna di grup dukungan, bukan dari alarm sistem.

Pendekatan Arsitektur & Keputusan Rekayasa

1. Kolektor Ringan POSIX Shell & Procfs: Menggantikan agen pihak ketiga dengan skrip POSIX shell sederhana yang membaca langsung /proc/stat, /proc/meminfo, dan status antrean disk, menghasilkan muatan data JSON ringkas setiap 2 detik.
2. Buffer Memori Redis & Logika Debounce: Layanan penerima metrik menulis langsung ke ring buffer Redis. Evaluasi peringatan mewajibkan metrik melampaui batas toleransi selama 3 siklus berturut-turut sebelum mengirim sinyal bahaya, menyaring lebih dari 98% lonjakan sementara.
3. Integrasi Webhook Terstruktur: Memformat kartu informasi Discord ke saluran operasi privat, dilengkapi kode warna status bahaya (Peringatan, Kritis, Pulih), label server terkait, serta rekomendasi perintah penanganan pertama.

Arsitektur Sistem

[ Node Host 01 ]                 [ Node Host 02 ]
  │ Pembacaan langsung /proc       │ Pembacaan langsung /proc
  ▼ (Tiap 2 detik via Systemd)     ▼
[ Agen Daemon Lokal ]            [ Agen Daemon Lokal ]
        │                                │
        └───────────────┬────────────────┘
                        ▼ (Koneksi WebSocket / HTTPS Aman)
               [ API Ingest Terpusat ]
                        │
                        ▼
               [ Cache / Buffer Redis ]
                        │
             [ Mesin Evaluasi Peringatan ]
             (Pemeriksaan Batas & Debounce)
                        │
        ┌───────────────┴───────────────┐
        ▼                               ▼
 [ Dasbor Operasional ]       [ Alur Webhook Discord ]
 (Siaran WS Waktu Nyata)      (Pengiriman Notifikasi Tindakan)

Halaman Status Publik

Pengumpul yang sama juga menyuplai halaman status publik di status.arqonara.com. Telemetri internal diubah menjadi informasi yang bisa dibaca pengunjung tanpa harus bertanya ke siapa pun:

• Dua sumber yang saling bebas. Kondisi host datang dari heartbeat agen yang berjalan di tiap node, sementara endpoint yang diakses pelanggan diperiksa terpisah lewat probe HTTP dan TCP dari host status. Node yang berhenti melapor dan port yang berhenti menjawab adalah dua kegagalan berbeda, dan halaman ini membedakannya.
• Riwayat, bukan sekadar lampu. Setiap layanan menyimpan riwayat uptime dan feed insiden, sehingga gangguan singkat tetap terlihat setelah pulih, bukan hilang begitu pemeriksaan kembali hijau.
• Jendela pemeliharaan dan sematan. Pemeliharaan terencana dicatat sebagai rencana, bukan sebagai kegagalan, dan kondisi terkini bisa disematkan di tempat lain sebagai badge sehingga data yang sama melayani situs maupun Discord komunitas.
• Pemisahan yang disengaja. Backend status hanya listen di loopback di belakang nginx dan tidak menyimpan kredensial apa pun untuk host yang dilaporkannya. Ia bisa menjelaskan kondisi armada tanpa bisa menyentuhnya.

Hasil Operasional & Keterbatasan

• Efisiensi Memori Ekstrem: Daemon telemetri hanya mengonsumsi kurang dari 15MB RAM pada setiap server fisik, memangkas beban resource lebih dari 90% dibanding solusi umum.
• Penanganan Proaktif: Waktu deteksi insiden (Time to Detect / TTD) terpangkas dari hitungan menit menjadi di bawah 10 detik, memberi ruang bagi operator untuk memitigasi kendala sebelum pemain terputus.
• Nol Kebisingan Notifikasi: Penerapan jeda adaptif berhasil mengeliminasi banjir pesan alarm palsu.
• Keterbatasan Terbuka: Sistem bergantung pada jalur komunikasi WebSocket ke server pengumpul utama; jika terjadi putus koneksi jaringan total pada host, sistem mendeteksi henti detak jantung (heartbeat silence) hingga tautan pulih. Trafik publik ke halaman status melewati bot challenge di sisi edge, jadi pemeriksaan curl otomatis menerima 403 walaupun halamannya sendiri sehat.

Teknologi yang Digunakan

• Inti Telemetri: Node.js, POSIX Shell (Bash), Linux Procfs
• Lapisan Data: Redis (Pub/Sub & Caching Berbasis Waktu), SQLite bawaan Node.js (node:sqlite)
• Protokol: WebSocket (ws), HTTPS, Enkripsi TLS
• Notifikasi: Discord Webhook API (Format Rich Embed)
• Halaman Status: Express, front end React + Vite, reverse proxy nginx, unit systemd
• Manajemen Proses: Unit Systemd, Timer Systemd