Network monitoring เป็นการตรวจสอบคุณภาพการเชื่อมต่อเครือข่ายใน 3 มิติหลัก คือ bandwidth (ปริมาณข้อมูลที่รับส่งได้), latency (เวลาตอบกลับ) และ packet loss (อัตราการสูญเสียแพ็กเก็ต) ทั้งสามตัวชี้วัดนี้ส่งผลโดยตรงต่อประสบการณ์ใช้งาน — เว็บโหลดช้า, video call กระตุก, database query timeout ล้วนสืบย้อนถึงปัญหาด้านเครือข่ายได้ทั้งสิ้น

บทความนี้จะอธิบาย metric ที่สำคัญ พร้อมเครื่องมือสำหรับตรวจสอบ (iperf3, MTR, SmokePing, Prometheus Blackbox Exporter) และตัวอย่าง alert rule สำหรับเคสที่พบบ่อยในระบบ production

Metric หลักของ Network

• Bandwidth/Throughput — ปริมาณข้อมูลที่ถ่ายโอนได้ต่อวินาที (Mbps, Gbps) — วัดด้วย iperf3, nload, vnstat
• Latency (RTT) — เวลาที่แพ็กเก็ตเดินทางไป-กลับ (ms) — วัดด้วย ping, mtr, hping3
• Packet Loss — % ของแพ็กเก็ตที่สูญหาย — ping ยาว ๆ, mtr –report
• Jitter — ความแปรปรวนของ latency — สำคัญสำหรับ VoIP/video
• DNS Resolution Time — เวลาที่ใช้ resolve domain — dig +stats, Prometheus blackbox
• Connection Count — จำนวน TCP connection พร้อมกัน — ss -s, netstat

Threshold อ้างอิงสำหรับแต่ละ Metric

Metric	ยอดเยี่ยม	ยอมรับได้	มีปัญหา
Latency (LAN)	< 1 ms	1-5 ms	> 10 ms
Latency (Internet, same country)	< 30 ms	30-100 ms	> 150 ms
Latency (Cross-continent)	< 150 ms	150-250 ms	> 300 ms
Packet Loss	0%	< 0.5%	> 1%
Jitter (VoIP)	< 10 ms	10-30 ms	> 50 ms
DNS Resolution	< 20 ms	20-100 ms	> 200 ms

iperf3 — วัด Bandwidth

iperf3 เป็นเครื่องมือมาตรฐานสำหรับวัด throughput ระหว่าง 2 เครื่อง ทำงานแบบ client-server — server รอรับ connection แล้ว client ส่งข้อมูลเพื่อวัดความเร็ว

# Server side
iperf3 -s -p 5201

# Client side - TCP test 10 วินาที
iperf3 -c server-ip -p 5201 -t 10

# UDP test พร้อมกำหนด bandwidth
iperf3 -c server-ip -u -b 100M -t 30

# Parallel streams - จำลอง load จริง
iperf3 -c server-ip -P 4 -t 60

ผลลัพธ์จะแสดง bitrate ต่อช่วงเวลา และค่าเฉลี่ยตลอดการทดสอบ ถ้าได้ bandwidth ต่ำกว่าที่คาดหวัง ให้ตรวจ MTU, TCP window size และ bottleneck บน switch/router

MTR — รวม Ping + Traceroute

MTR (My Traceroute) แสดง latency และ packet loss ของแต่ละ hop ระหว่างต้นทางถึงปลายทาง ช่วยหาจุดที่เป็น bottleneck บนเส้นทาง — เหมาะสำหรับวิเคราะห์ปัญหา latency ที่ไม่แน่ชัดว่าเกิดที่ไหน

# interactive mode
mtr google.com

# report mode - 100 packets แล้วจบ
mtr --report --report-cycles 100 google.com

# TCP mode สำหรับทดสอบพอร์ตเฉพาะ
mtr --tcp --port 443 api.example.com

# JSON output สำหรับ automation
mtr --json --report-cycles 50 target.com

อ่านผลลัพธ์ได้ง่าย — คอลัมน์ Loss% แสดง packet loss ต่อ hop, Avg คือ latency เฉลี่ย ถ้า loss สูงเฉพาะ hop กลางทางแต่ hop ท้ายกลับเป็น 0% แสดงว่า router ตรงนั้น rate limit ICMP ไม่ใช่ปัญหาจริง

SmokePing — Long-term Latency Monitor

SmokePing ส่ง ping 10-20 ครั้งต่อรอบ แล้วแสดงเป็นกราฟ — ส่วนที่เรียกว่า “smoke” คือการกระจายตัวของ latency ซึ่งบอกถึง jitter ได้ดีกว่า ping ธรรมดา ใช้สำหรับ baseline analysis ระยะยาว (เดือน, ปี)

# /etc/smokeping/config.d/Targets
+ Production
menu = Production Servers
title = Production Network

++ web01
menu = Web 01
title = web01.example.com
host = 10.0.0.10

++ api
menu = API
title = api.example.com
host = api.example.com

++ database
menu = DB
title = database latency
host = db.internal.example.com

Prometheus Blackbox Exporter

Blackbox Exporter เป็น exporter ของ Prometheus สำหรับ probe endpoint ภายนอก รองรับ HTTP, TCP, ICMP, DNS — เหมาะกับการ monitor ทั้ง uptime, latency, SSL expiry ในระบบที่มี Prometheus อยู่แล้ว

# blackbox.yml
modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      valid_status_codes: [200]
      method: GET

  icmp:
    prober: icmp
    timeout: 5s

  dns_tcp:
    prober: dns
    dns:
      query_name: example.com
      query_type: A
      transport_protocol: tcp

# prometheus.yml
scrape_configs:
  - job_name: blackbox-icmp
    metrics_path: /probe
    params:
      module: [icmp]
    static_configs:
      - targets:
        - 8.8.8.8
        - 1.1.1.1
        - api.example.com
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Alert Rule ตัวอย่าง

groups:
- name: network
  rules:
  - alert: HighNetworkLatency
    expr: probe_duration_seconds{job="blackbox-icmp"} > 0.15
    for: 5m
    annotations:
      summary: "Latency ไปยัง {{ $labels.instance }} สูงเกิน 150ms"

  - alert: PacketLoss
    expr: (1 - avg_over_time(probe_success{job="blackbox-icmp"}[10m])) > 0.05
    for: 10m
    annotations:
      summary: "Packet loss ไปยัง {{ $labels.instance }} เกิน 5% ใน 10 นาที"

  - alert: InterfaceHighBandwidth
    expr: rate(node_network_transmit_bytes_total{device="eth0"}[5m]) * 8 > 800e6
    for: 10m
    annotations:
      summary: "{{ $labels.instance }} eth0 ใช้แบนด์วิธเกิน 800 Mbps ต่อเนื่อง"

  - alert: TooManyConnections
    expr: node_netstat_Tcp_CurrEstab > 10000
    for: 5m
    annotations:
      summary: "TCP connection บน {{ $labels.instance }} เกิน 10k"

Troubleshooting Workflow

• Step 1: ping เพื่อยืนยันว่า host ยังตอบสนองและดู latency พื้นฐาน
• Step 2: mtr หา hop ที่เป็นปัญหา (latency กระโดด/loss สูง)
• Step 3: iperf3 วัด bandwidth จริงระหว่างจุด — ถ้า bandwidth ต่ำแต่ latency ปกติ → link saturation
• Step 4: ตรวจ interface counter ด้วย ip -s link หรือ ethtool -S eth0 ดู error/drop
• Step 5: tcpdump/wireshark ถ้าสงสัย retransmission หรือ protocol error
• Step 6: ถ้าเป็น application level ให้ดู connection pool, DNS cache, TLS handshake time

Best Practices

• วัด baseline ก่อน — รู้ค่าปกติช่วงไม่มีปัญหา (SmokePing 1-2 สัปดาห์) แล้วค่อยตั้ง threshold
• Multi-vantage point — probe จากหลายที่ (data center, office, cloud region) เพื่อแยกปัญหาฝั่ง server จากฝั่ง client
• Alert packet loss ก่อน latency — loss 1% ส่งผลรุนแรงกว่า latency สูง 100ms ในหลายกรณี
• ตรวจ DNS แยก — DNS ช้ามักถูกมองข้าม แต่ส่งผลต่อ app startup time ทันที
• ระวัง ICMP rate limit — router เปิด ICMP limit ทำให้ MTR แสดง loss หลอก
• อย่าลืม IPv6 — ถ้ารองรับทั้ง 2 stack ต้อง monitor คู่กัน

สรุป

Network monitoring ที่ดีต้องครอบคลุม 3 มิติหลัก ได้แก่ bandwidth, latency และ packet loss และใช้เครื่องมือที่เหมาะกับงาน — iperf3 สำหรับ throughput, MTR สำหรับ hop-by-hop diagnosis, SmokePing สำหรับ baseline ระยะยาว และ Blackbox Exporter สำหรับรวมกับ Prometheus/Grafana ที่มีอยู่แล้ว การตั้ง alert ที่ fire เฉพาะเมื่อมีปัญหาจริงจะช่วยลด alert fatigue และทำให้ทีมพุ่งเป้าไปที่ปัญหาที่สำคัญได้

การวิเคราะห์ปัญหาเครือข่ายที่มีประสิทธิภาพ อาศัย methodology ที่เป็นลำดับขั้น — เริ่มจาก ping → mtr → iperf3 → interface counter → tcpdump ถ้าทำตามลำดับจะหาสาเหตุเจอในเวลาน้อยกว่าการเดาสุ่ม และการเก็บ historical data ไว้ช่วยให้เห็น degradation ค่อย ๆ เพิ่มขึ้นก่อนที่จะกลายเป็น incident ใหญ่