Lewati ke konten
mikrotik.ai.id
RT/RW Net

Monitoring Jaringan MikroTik: Trafik, Sinyal, dan Pelanggan RT/RW Net

Redaksi MikroTik
· 8 menit baca
Monitoring Jaringan MikroTik: Trafik, Sinyal, dan Pelanggan RT/RW Net
Daftar isi8 bagian
Baca jugaSetting PPPoE Server MikroTik untuk Pelanggan RT/RW NetRT/RW Net

Pelanggan ke-23 menelepon jam sembilan malam: internet mati sejak sore. Anda membuka Winbox, melihat daftar PPPoE aktif, dan akun itu memang tidak ada di sana. Pertanyaan berikutnya selalu sama: putus sejak kapan, karena apa, dan apakah pelanggan lain ikut kena. Tanpa data historis, jawabannya hanya tebakan.

Router yang sudah melayani RT/RW Net sebenarnya menyimpan hampir semua jawaban itu. Yang kurang cuma kebiasaan membacanya. Artikel ini menyusun pemantauan bertahap di RouterOS v7, dari statistik interface yang bisa dilihat dalam tiga puluh detik sampai graphing, netwatch, SNMP, dan log. Semua perintah bisa ditempel langsung ke terminal Winbox atau sesi SSH.

Apa yang perlu dipantau lebih dulu

ObjekMenu atau perintahTanda bahayaArtinya
Uplink ISP/interface/monitor-traffic ether1rx mendekati kapasitas langganan berjam-jamuplink jenuh, bukan router lambat
Link fisik/interface/print stats-detaillink-downs terus bertambahkabel, SFP, atau PoE bermasalah
Trafik pelangganmenu Queues, kolom Raterate menempel di max-limitpelanggan kena batas atau unduh besar
Sesi PPPoE/ppp/active/printuptime pendek dan berulangputus nyambung di sisi pelanggan
Sinyal wireless/interface/wifi/registration-table/printsignal melemah di bawah -75 dBmjarak, halangan, atau interferensi
Beban router/tool graphing resourceCPU tinggi walau trafik normalterlalu banyak queue atau aturan firewall

Angka di kolom tanda bahaya bukan patokan mutlak. Yang lebih berguna adalah baseline: catat nilai normal jaringan Anda selama seminggu, lalu bandingkan dengan kondisi saat pelanggan mengeluh.

Langkah 1: statistik interface dan trafik sesaat

Dua perintah ini paling cepat memberi gambaran.

kode
/interface/print stats-detail
/interface/monitor-traffic ether1 duration=5

stats-detail menambah dua kolom penting yang tidak muncul di print biasa: link-downs dan waktu link terakhir naik. Port yang link-downs-nya naik terus hampir selalu berarti masalah fisik, bukan konfigurasi. Periksa kabel, konektor, adaptor PoE, atau suhu perangkat di ujung kabel. Kolom tx-queue-drop menunjukkan paket yang dibuang antrean interface, tanda awal uplink mulai sesak sebelum pelanggan mengeluh lambat.

monitor-traffic menampilkan kecepatan per detik: rx-bits-per-second dan tx-bits-per-second, ditambah jumlah paket dan drop antrean. Jalankan dengan duration=5 supaya perintah berhenti sendiri. Bandingkan angka rx dengan kapasitas langganan ISP. Kalau rx sudah 90 persen ke atas selama jam sibuk, masalahnya kapasitas, dan menambah queue hanya memindahkan kelambatan.

Langkah 2: trafik per pelanggan dari simple queue

Kalau setiap rumah punya simple queue, RouterOS sudah menghitung kecepatan dan volume tiap pelanggan. Nilai rate, bytes, dan dropped adalah properti baca saja yang bisa diambil dari script.

kode
:foreach q in=[/queue/simple/find] do={
  :local n [/queue/simple/get $q name]
  :local r [/queue/simple/get $q rate]
  :put ($n . " " . $r)
}

Hasilnya daftar nama queue dengan pasangan kecepatan unggah dan unduh. Queue yang rate-nya menempel di max-limit sepanjang hari biasanya pelanggan yang sedang mengunduh besar atau perangkatnya terserang malware. Queue dengan dropped tinggi tapi rate rendah justru sering menandakan batas terlalu kecil untuk pola pemakaian rumah itu, misalnya karena ada dua TV streaming.

Pembagian bandwidth yang adil antar pelanggan dibahas di cara limit bandwidth di MikroTik dengan queue, termasuk penggunaan PCQ. Untuk pemantauan, cukup ingat satu hal: queue hanya berguna kalau angkanya rutin dilihat, bukan dipasang lalu dilupakan.

Langkah 3: graphing, riwayat trafik tanpa server tambahan

Graphing menyimpan data pemakaian di router dan menampilkannya sebagai halaman web. Tidak perlu Zabbix atau server Linux.

kode
/tool/graphing/interface/add interface=ether1 allow-address=192.168.88.10/32
/tool/graphing/resource/add allow-address=192.168.88.10/32
/tool/graphing/queue/add simple-queue=all allow-address=192.168.88.10/32 allow-target=no

Buka https://192.168.88.1/graphs/ dari komputer yang alamatnya ada di allow-address. Setiap halaman berisi empat grafik: harian dengan rata-rata 5 menit, mingguan 30 menit, bulanan 2 jam, dan tahunan 1 hari. Nilai pertama muncul setelah rata-rata 5 menit pertama selesai, jadi grafik kosong di menit awal itu normal.

Tiga hal yang sering salah saat memasang graphing. Pertama, allow-address default 0.0.0.0/0 membuat grafik terbuka untuk siapa pun yang bisa menjangkau web server router, jadi selalu batasi ke alamat operator. Kedua, allow-target=yes adalah default pada rule queue, artinya pelanggan yang alamatnya masuk target queue bisa melihat grafik queue itu, termasuk queue tetangga kalau targetnya berupa subnet lebar. Setel allow-target=no pada rule simple-queue=all dan buat rule terpisah untuk queue yang memang boleh dilihat pelanggannya. Ketiga, interface PPPoE dinamis berganti ID setiap pelanggan menyambung ulang, sehingga rule grafiknya berubah jadi interface tak dikenal seperti *F00000. Kalau butuh grafik permanen per pelanggan, buat static PPPoE server binding lalu graph interface binding itu.

store-on-disk=yes membuat data bertahan setelah perangkat dinyalakan ulang, tetapi setiap rule menulis ke flash. Pada perangkat dengan storage kecil, matikan opsi itu untuk rule interface=all yang grafiknya tidak perlu dilihat lagi besok.

Langkah 4: netwatch, tahu sebelum pelanggan menelepon

Netwatch menguji satu host secara berkala dan menjalankan script saat statusnya berubah. Ada enam tipe probe: simple untuk satu ping, icmp untuk sepuluh ping dengan statistik loss dan latency, tcp-conn untuk cek port, http-get dan https-get untuk cek kode balasan web, serta dns untuk cek resolusi nama.

kode
/tool/netwatch/add host=8.8.8.8 type=icmp interval=10s \
  down-script=":log warning \"uplink ISP tidak terjangkau\"" \
  up-script=":log info \"uplink ISP kembali normal\""

Probe ke perangkat pelanggan sebaiknya memakai type=simple dengan interval 60 detik, karena tujuannya mendeteksi mati total, bukan mengukur kualitas.

kode
/tool/netwatch/add host=192.168.88.23 type=simple interval=60s \
  down-script="/tool e-mail send to=noc@example.com subject=\"Pelanggan 23 down\" body=\"Cek kabel atau radio\""

Satu jebakan yang perlu diketahui: probe icmp sudah punya ambang bawaan, misalnya thr-avg=100ms. Link yang hidup tapi lambat karena gangguan ISP bisa dilaporkan down tanpa ada yang benar-benar mati. Kalau itu terjadi, lihat /tool/netwatch/print stats untuk tahu ambang mana yang terpicu, lalu naikkan nilainya. Script netwatch berjalan sebagai user internal dengan hak terbatas read, write, test, dan izin menyalakan ulang perangkat, jadi jangan berharap script itu bisa memanggil menu di luar hak tersebut.

Langkah 5: sinyal pelanggan wireless

Untuk jaringan yang sebagian pelanggannya memakai radio, sinyal adalah angka yang paling sering berubah tanpa terlihat.

kode
/interface/wifi/registration-table/print

Perhatikan kolom signal, tx-rate, rx-rate, uptime, dan last-activity. Pelanggan dengan uptime beberapa menit lalu hilang dan muncul lagi biasanya mengalami putus nyambung, bukan sekadar lambat. Perangkat lama dengan paket wireless memakai menu /interface/wireless/registration-table/print, isinya serupa.

Script kecil ini menandai pelanggan yang sinyalnya lemah:

kode
:foreach r in=[/interface/wifi/registration-table/find] do={
  :local s [/interface/wifi/registration-table/get $r signal]
  :if ($s < -75) do={ :log warning ("sinyal lemah: " . $s) }
}

Jalankan lewat scheduler tiap jam, lalu baca hasilnya di /log/print where topics~"warning". Sinyal yang turun bertahap dalam beberapa hari biasanya berarti antena bergeser atau pohon tumbuh menutup jalur, bukan radio rusak.

Langkah 6: SNMP dan log untuk yang sudah punya server

Kalau Anda sudah menjalankan The Dude, LibreNMS, Zabbix, atau Cacti, SNMP memberi data yang bisa digabung dengan perangkat lain.

kode
/snmp/set enabled=yes contact="NOC" location="Rumah panel RT 04"
/snmp/community/add name=monit addresses=192.0.2.0/24 security=none read-access=yes

Agent SNMP mendengarkan UDP port 161. Community bawaan public punya alamat ::/0 dan bisa dibaca dari mana saja, jadi batasi atau hapus setelah community baru dibuat. Uji dari kolektor dengan snmpwalk -v2c -c monit 192.0.2.1 1.3.6.1.4.1.14988 untuk memastikan jawabannya datang. Ingat bahwa SNMPv1 dan v2c mengirim community dalam teks biasa; pakai SNMPv3 dengan security=private kalau jalur polling melewati jaringan yang tidak dipercaya.

Log melengkapi angka. Tambahkan aturan untuk topik PPPoE supaya setiap sesi naik dan turun tercatat.

kode
/system/logging/add topics=pppoe,info action=memory
/system/logging/action/set remote remote=192.168.88.5 remote-log-format=syslog
/system/logging/add topics=pppoe,info action=remote

Buffer memory menyimpan 1000 entri terakhir dan hilang saat perangkat dinyalakan ulang, karena itu syslog ke komputer kantor lebih berguna untuk investigasi sehari kemudian. Kumpulan perintah setup awal RT/RW Net, termasuk address list dan mangle, ada di panduan setting RT/RW Net.

Rutinitas sepuluh menit

  1. Jalankan /interface/print stats-detail, cek port yang link-downs-nya bertambah sejak kemarin.
  2. Buka grafik resource, lihat apakah CPU memuncak di jam yang sama tiap hari.
  3. Jalankan script queue, catat tiga pelanggan dengan rate tertinggi.
  4. Bandingkan jumlah sesi /ppp/active/print dengan jumlah pelanggan yang seharusnya aktif.
  5. Cek pelanggan bersinyal di bawah -75 dBm.
  6. Baca entri pppoe di log, cari pola putus pada jam tertentu.

Kalau uplink sering penuh dan Anda punya dua ISP, pemantauan ini jadi dasar sebelum memindahkan trafik, seperti di load balancing dua ISP dengan PCC. Tanpa data per jam, failover hanya menambah biaya tanpa menyelesaikan akar masalah.

Pemantauan yang berhasil bukan yang paling banyak alatnya, tapi yang angkanya dicatat. Satu halaman catatan berisi trafik puncak, CPU puncak, dan jumlah sesi tiap sore sudah cukup untuk menjawab pertanyaan pelanggan dengan kalimat pasti, bukan dugaan.

Pertanyaan yang sering diajukan

Apakah graphing MikroTik butuh server monitoring tambahan?

Tidak. Graphing berjalan di router dan menyimpan data di storage perangkat, lalu menampilkannya di halaman /graphs/ yang bisa dibuka dari browser. Server monitoring baru diperlukan kalau Anda ingin menggabungkan data banyak router, dan untuk itu pakai SNMP.

Berapa nilai sinyal wireless yang masih layak untuk pelanggan RT/RW Net?

Patokan umum, sinyal di atas -70 dBm masih nyaman untuk streaming, -70 sampai -75 dBm mulai terasa saat trafik berat, dan di bawah -75 dBm keluhan putus nyambung biasanya muncul. Angka ini perlu dibandingkan dengan kondisi lapangan karena noise di sekitar juga berpengaruh.

Kenapa grafik interface pelanggan PPPoE hilang setelah pelanggan menyambung ulang?

Interface PPPoE dinamis dibuat ulang setiap sesi, sehingga ID-nya berubah dan rule graphing menunjuk interface lama yang tidak ada lagi. Solusinya membuat static PPPoE server binding untuk pelanggan itu lalu memasang rule graphing pada interface binding tersebut.

Apakah netwatch bisa mengirim notifikasi WhatsApp atau Telegram?

Netwatch hanya menjalankan script, jadi notifikasi keluar tergantung script yang Anda tulis. Yang paling sederhana adalah email lewat /tool e-mail atau syslog ke server kantor. Untuk Telegram atau WhatsApp perlu request HTTP dari script ke API layanan tersebut, dan itu berada di luar cakupan artikel ini.

Berapa banyak data yang dipakai graphing di storage router?

Setiap rule graphing menyimpan data ke flash dengan interval tulis 5 menit secara default, dan jumlahnya bertambah sesuai jumlah interface atau queue yang digraph. Pada perangkat berstorage kecil, matikan store-on-disk untuk rule yang tidak perlu dipertahankan setelah perangkat dinyalakan ulang.

Artikel terkait