CPU, memori, dan disk sepenuhnya berada di dalam mesin; jaringan tidak. Kesehatannya bergantung pada pihak luar — klien yang menyerbu, tetangga yang memakan bandwidth, tautan yang putus — sehingga gejalanya paling sering membingungkan. Pemantauan jaringan praktis berkisar pada dua pertanyaan: siapa saja yang sedang terhubung atau mendengarkan, dan berapa banyak data yang mengalir lewat interface. Pada chapter ini kita menjawab keduanya dengan ss dan byte counter kernel, lalu mengenali alat bantu real-time seperti iftop.

ss: Foto Koneksi Sistem #

Perintah ss menggantikan netstat sebagai alat standar memeriksa socket — perannya di dunia networking sudah kita bahas tuntas di Chapter ss dan netstat . Untuk pemantauan harian, empat variasi ini menutup hampir semua kebutuhan:

PerintahPertanyaan yang dijawab
ss -tlnservice apa saja yang sedang mendengarkan koneksi TCP baru
ss -tunkoneksi TCP/UDP apa saja yang sedang ada (dengan alamat numerik)
ss -sringkasan satu layar: total socket, established, timewait
ss -tunpkoneksi ditambah nama proses pemiliknya (perlu hak lebih tinggi)

Huruf flagnya berbicara sendiri: -t TCP, -u UDP, -l (listening) hanya socket yang menerima koneksi baru, -n alamat dalam bentuk angka tanpa resolusi DNS, -p proses. Baris koneksi yang bekerja memiliki kolom state ESTAB (established), sedangkan baris yang mendengarkan ditandai LISTEN. Ringkasan ss -s berguna untuk mencium anomali cepat — misalnya ribuan koneksi timewait yang menandakan aplikasi membuat koneksi baru terus-menerus alih-alih memakai ulang koneksi lama. Daftar lengkap state dan opsinya ada di ss(8) .

Latihan: Membuktikan Port Benar-benar Mendengarkan #

Skenario paling sering: sebuah service baru diklaim “sudah jalan”, tetapi klien tetap menolak terhubung. Bukti paling cepat adalah melihat socket LISTEN-nya sendiri. Kita tiru keadaan itu dengan server web kecil python3 -m http.server di port 8642, lalu periksa dengan ss:

bash 
python3 -m http.server 8642 >/dev/null 2>&1 &
pid_server=$!
sleep 1
ss -tln | grep 8642 | sed 's/[[:space:]]*$//'
kill "$pid_server"

Output yang Dihasilkan:

text 
LISTEN 0      5            0.0.0.0:8642       0.0.0.0:*

Bedah blok di atas:

  1. Baris 1–2 (server latar): tanda & menjalankan server di belakang layar, dan $! menangkap PID-nya agar bisa dihentikan nanti. Redirect >/dev/null 2>&1 membuang log request server supaya output blok tetap bersih — pola yang sama penting untuk semua proses latar di dalam skrip.
  2. Baris 3 (sleep 1): memberi satu detik bagi server untuk mengikat port sebelum difoto; tanpa jeda ini, ss bisa berjalan lebih cepat daripada server.
  3. Baris 4 (ss -tln | grep 8642): -tln menampilkan hanya socket TCP yang mendengarkan, lalu grep 8642 menyaring baris milik server kita. sed 's/[[:space:]]*$//' hanya merapikan spasi kosong di ujung kanan baris — ss memang mengisi kolomnya dengan spasi berlebih.
  4. Baris 5 (kill): memberhentikan server sehingga port 8642 kembali bebas dan blok berakhir bersih.

Baris LISTEN pada output menjelaskan dirinya sendiri: state mendengarkan, Recv-Q masih nol (tidak ada koneksi menunggu diterima), Send-Q bernilai 5 — pada baris LISTEN, kolom ini menampilkan ukuran backlog, yaitu antrean koneksi baru yang sanggup ditampung sebelum ditolak. Alamat 0.0.0.0:8642 berarti server menerima koneksi dari semua interface; bila kelak muncul 127.0.0.1:8642, service itu hanya terbuka untuk mesin sendiri — pilihan yang justru dianjurkan untuk service internal, seperti yang kita praktikkan di Chapter Linux Security Basics .

Byte Counter di /sys/class/net #

Pertanyaan kedua — berapa banyak data mengalir — dijawab kernel lewat sysfs. Setiap interface punya direktori /sys/class/net/<nama>/statistics/ berisi file rx_bytes (data diterima) dan tx_bytes (data dikirim) yang nilainya terus bertambah sejak mesin menyala. Nama interface sendiri berbeda antar mesin — eth0, enp3s0, wlan0, dan di container bisa saja ens4 — aturan penamaannya sudah kita bahas di Chapter Network Interfaces .

Karena counternya kumulatif, trafik sebuah periode harus dihitung dari selisih dua pembacaan. Nilai di mesin kita masing-masing berbeda, jadi latihan memakai dua pasang snapshot fixture yang meniru isi file asli, diambil dengan jeda 5 detik:

bash 
printf '104857600\n' > rx-awal.txt
printf '110100480\n' > rx-akhir.txt
printf '5242880\n'  > tx-awal.txt
printf '7864320\n'  > tx-akhir.txt

delta_rx=$(( $(cat rx-akhir.txt) - $(cat rx-awal.txt) ))
delta_tx=$(( $(cat tx-akhir.txt) - $(cat tx-awal.txt) ))

awk -v rx="$delta_rx" -v tx="$delta_tx" 'BEGIN {
  printf "delta rx: %.1f MiB | delta tx: %.1f MiB\n", rx/1048576, tx/1048576
  printf "rata-rata 5 detik: rx %.1f Mbit/s | tx %.1f Mbit/s\n", rx*8/5/1000000, tx*8/5/1000000
}'

Output yang Dihasilkan:

text 
delta rx: 5.0 MiB | delta tx: 2.5 MiB
rata-rata 5 detik: rx 8.4 Mbit/s | tx 4.2 Mbit/s

Mari kita telaah perhitungannya:

  1. Baris 6–7 (delta_rx=...): aritmetika $(( )) bash menghitung selisih byte antar snapshot. Angka counter bisa sangat besar (ratusan GiB pada mesin yang lama menyala), dan bash 64-bit menanganinya tanpa masalah.
  2. Baris 9–12 (awk -v ...): hasil selisih dikirim ke awk sebagai variabel rx dan tx agar pembagian satuan dan pembulatan terjadi di satu tempat. Pembagian 1048576 mengubah byte menjadi MiB; angka 8 mengubah byte menjadi bit, dibagi 5 detik dan 1.000.000 menjadi Mbit/s — satuan yang dipakai dunia networking untuk kapasitas.
  3. Tafsiran hasil: 5 MiB diterima dalam 5 detik berarti rata-rata 8.4 Mbit/s — jauh di bawah kapasitas gigabit (1000 Mbit/s), jadi interface ini bukan sumber kemacetan. Skrip pengawas tinggal mengulang pembacaan counter secara berkala dan membandingkan hasilnya dengan ambang yang dianggap wajar.

iftop dan nload: Trafik Real-Time #

Dua angka delta tadi menjawab “berapa”; pertanyaan “siapa yang memakai bandwidth” dijawab iftop. Alat ini menampilkan daftar koneksi berjalan lengkap dengan laju data dua arahnya, diperbarui terus-menerus layaknya top untuk CPU. Mesin latihan kita tidak memasangnya, jadi berikut contoh tampilan tipikalnya (bandwidth ditampilkan dalam dua kolom: dua detik terakhir dan rata-rata sejak iftop berjalan):

text 
              12.5Mb         25.0Mb        37.5Mb        50.0Mb    62.5Mb
└────────────┴──────────────┴──────────────┴────────────┴─────────────
server-kantor      => backup-server   4.12Mb  3.05Mb  2.86Mb
                    <=                 1.24Mb  0.95Mb  0.88Mb
192.0.2.10          => 198.51.100.7    2.86Mb  2.44Mb  2.31Mb
                    <=               480Kb    410Kb    392Kb
TX:  cum   18.4MB   peak   5.2Mb   rates   5.38Mb  4.01Mb  3.74Mb
RX:         4.1MB          1.9Mb           1.72Mb  1.36Mb  1.28Mb

Bacaan di atas menunjukkan jalur backup ke backup-server menyeret 4.12 Mb/s — saat backup mingguan berjalan pada pukul sibuk, inilah biang keladi lambatnya aplikasi. Alat pendampingnya, nload, memilih sudut pandang berbeda: satu grafik batang besar per interface yang menunjukkan rx/tx dari waktu ke waktu, enak untuk memastikan apakah trafik sedang menanjak atau stabil. Keduanya biasanya dijalankan dengan hak lebih tinggi karena membutuhkan akses promiscuous mode pada interface; panduan kolomnya ada di iftop(8) .

Empat sumber daya kini terpantau lengkap. Tersisa satu indikator yang merangkum semuanya dalam tiga angka kecil — antrean kerja yang dikenal sebagai load average, dan kaitannya dengan lamanya sistem menyala. Kita tutup rangkaian pemantauan ini di Chapter Uptime dan Load Average .