Belajar Network Engineer - Monitoring & Troubleshooting

#Pendahuluan

Setelah di episode 9 jaringan kalian terlindungi, pertanyaannya berubah: bagaimana kalian tahu semuanya masih sehat? Dan saat user melapor "internet lambat", apa yang membedakan engineer dari penonton adalah data: interface error, utilisasi link, flow anomali — semuanya harus sudah dikumpulkan sebelum masalah terjadi.

Episode ini menata dua kemampuan yang tak terpisahkan: monitoring (mengamati sebelum ada yang komplain) dan troubleshooting (metodologi diagnosis saat alarm bunyi).

#Tiga Pilar Data Monitoring

#SNMP: Klasik yang Masih Bertahan

SNMP (Simple Network Management Protocol) membaca/menulis data perangkat lewat OID — angka identitas di dalam MIB. Dua pola komunikasinya:

• Polling: NMS bertanya berkala ("berapa in-octets interface ini 5 menit lalu vs sekarang?") → dasar grafik bandwidth.
• Trap: perangkat melapor sendiri saat kejadian (link down) → notifikasi cepat tanpa nunggu poll.

Versi yang dipakai: v2c sederhana tapi community string berjalan plaintext; v3 wajib di produksi karena punya autentikasi + enkripsi. Contoh query cepat dari Linux:

snmpwalk -v3 -l authPriv -u netmon -a SHA -A 'Passw0rd!' \
  -x AES -X 'Passw0rd!' 192.168.2.1 IF-MIB::ifOperStatus

#NetFlow/sFlow: Melihat Isi Trafik

SNMP memberi tahu berapa banyak; flow memberi tahu apa: siapa bicara ke siapa, port apa, berapa byte. Bedanya:

• NetFlow/IPFIX (sampling atau full): router mengirim record flow ke collector.
• sFlow: sampling paket pada hardware — ringan untuk switch ASIC kecepatan tinggi.

Kegunaan nyata: mencari host yang tiba-tiba makan bandwidth, memetakan trafik top-talkers, mendeteksi scan/exfil, dan menyusun baseline aplikasi.

#Syslog: Kronologi Kejadian

Setiap perangkat mencatat kejadian dengan severity standar:

Praktiknya: kirim semua log ke syslog server terpusat (jangan andalkan memori perangkat), pisah level debug hanya saat investigasi, dan set timestamp/NTP benar — log dengan jam kacang hampir tak berguna saat insiden lintas perangkat.

#Memilih Tool Monitoring

Pasar menawarkan spektrum luas; pahami kategorinya:

Tidak ada yang salah memilih dua lapisan: NMS klasik untuk SNMP/trap perangkat jaringan, Prometheus/Grafana untuk metrics aplikasi dan cloud. Yang membedakan tim matang bukan tool-nya, tetapi disiplin alert: setiap alarm harus actionable, punya ambang bermakna, dan terhubung runbook.

#Baseline: Mengetahui "Normal" Dulu

Monitoring tanpa baseline hanyalah deretan grafik. Baseline menjawab: utilisasi WAN normal jam kerja berapa persen? Latency ke SaaS biasanya berapa ms? Berapa jumlah session firewall hari Selasa?

Cara membangunnya sederhana namun disiplin: kumpulkan data minimal 2-4 minggu (menutup siklus mingguan), tandai pola harian/pekanan, catat anomali yang sudah dijelaskan (backup malam Minggu, payroll tanggal 25). Saat insiden datang, pertanyaan kalian instan: "bandingkan dengan normal".

#Metodologi Troubleshooting Layer-by-Layer

Kini sisi kedua: insiden terjadi, alarm tidak cukup spesifik. Metode yang teruji:

#Langkah 0 — Definisikan Masalah

Siapa yang kena (satu user? satu VLAN? semua)? Sejak kapan? Apa yang berubah terakhir (change history dulu selalu!)? Mayoritas "insiden misterius" adalah perubahan Jumat sore.

#Pendekatan Bottom-Up vs Top-Down

• Bottom-up (fisik → IP → aplikasi): cocok saat gejala total/"semua mati".
• Top-down (aplikasi → turun): efisien saat keluhan spesifik ("email saja").
• Divide-and-conquer: mulai tengah (ping gateway) — favorit engineer berpengalaman karena cepat membelah ruang masalah.

#Toolkit Diagnosis Bertingkat

ip -br addr                 # dapat IP? subnet benar?
ping -c3 192.168.0.254      # gateway reachable?
ping -c3 8.8.8.8            # keluar internet?
dig google.com              # DNS jalan?
traceroute 8.8.8.8          # di hop mana macet?

Lanjut ke perangkat sesuai temuan:

show interfaces status           # fisik: up/down, speed/duplex
show interfaces gi1/0/10 | i err|crc   # error counter naik?
show mac address-table | i a4b1  # MAC user belajar di port mana?
show ip route 8.8.8.8            # jalur keluar ada?
show spanning-tree               # topologi L2 sehat?

#Studi Kasus End-to-End

Gejala: "Finance tidak bisa buka ERP, cabang lain normal."

1. Ping gateway dari PC finance → gagal; ping antar-PC satu VLAN → berhasil. Masalah di gateway VLAN, bukan fisik.
2. show standby brief di distribusi → HSRP state kedua router Active bersamaan (split brain!).
3. Log menunjukkan VRRP/HSRP hello hilang sejak maintenance switch core pagi itu; show interfaces trunk menemukan VLAN management hilang dari allowed list.
4. Perbaiki allowed VLAN → HSRP pulih single-active → ERP reachable. Total 12 menit karena data, bukan tebakan.

Dokumentasikan resolusinya (root cause, fix, preventif) — inilah yang menjadi aset tim.

#Common Pitfalls

• Monitor hanya uptime — perangkat "up" dengan interface error 40% atau CPU 95% bukan sehat; pantau indikator kualitas, bukan cuma reachability.
• Tanpa NTP konsisten — korelasi log antar perangkat mustahil; sinkronisasi waktu adalah prasyarat insiden, bukan bonus.
• Memburu tool mahal sebelum proses — ticket triage, eskalasi, dan post-mortem lebih menentukan MTTR daripada brand NMS.
• Troubleshooting tanpa change window — mengubah konfigurasi saat diagnosa bisa menciptakan insiden kedua; pisahkan fase amati dan fase ubah.

#Penutup

Inti yang harus dibawa pulang:

• Tiga pilar data: SNMP untuk metrik & trap, flow untuk isi trafik, syslog untuk kronologi — semua terpusat, semua dengan waktu tersinkron.
• Pilih tool sesuai skala dan tim; disiplin alert actionable > fitur melimpah.
• Baseline mengubah grafik menjadi alat deteksi; tanpanya kamu hanya menonton garis.
• Troubleshooting profesional: definisikan masalah, cek perubahan, bagi ruang masalah, uji satu variabel per langkah, dokumentasikan akhirnya.

Di episode 11 selanjutnya kita atur prioritas trafik: QoS dan traffic engineering — classification & marking DSCP, antrian, policing vs shaping, dan praktik memberikan jaminan untuk voice/video di jaringan yang sama dengan download besar-besaran. Sampai jumpa!