Network Monitoring Data Platform: Prometheus, Grafana และ SNMP Exporter

Networking / Network Monitoring / Observability

Network Monitoring Data Platform: สร้างระบบ Prometheus, Grafana และ SNMP Exporter สำหรับ Cisco Network

เมื่อทีม Network Operations มี Python Script หรือ Cisco CLI สำหรับตรวจสอบอุปกรณ์แล้ว ขั้นตอนถัดไปคือสร้างระบบที่เก็บข้อมูลต่อเนื่อง แสดงแนวโน้มย้อนหลัง และแจ้งเตือนเมื่อเกิดเหตุผิดปกติ บทความนี้สาธิตการวางสถาปัตยกรรม Prometheus + SNMP Exporter + Grafana บน Docker Compose โดยเริ่มจาก Lab ก่อนขยายสู่ Production

ขอบเขต: ใช้เฉพาะ Cisco Switch/Router ที่ได้รับอนุญาตให้ Monitoring ตัวอย่าง IP Address เป็นค่าจำลอง ต้องเปลี่ยนให้ตรงกับระบบจริง

1. Network Monitoring Data Platform คืออะไร

จากการตรวจสอบรายครั้งสู่ข้อมูลแบบ Time-Series

การใช้ show interfaces บอกสถานะ ณ เวลาที่ตรวจ แต่ระบบ Monitoring ต้องตอบได้ว่า Uplink ใช้งานหนักช่วงใด เกิด Packet Discard บ่อยเพียงใด และเหตุการณ์สัมพันธ์กับ Incident หรือไม่ ข้อมูลประเภทนี้เหมาะกับ Time-Series Database (TSDB) ที่เก็บค่า Metric พร้อม Timestamp และ Labels

Prometheus ทำหน้าที่ Scrape และจัดเก็บ Metrics, SNMP Exporter แปลงค่า SNMP ของอุปกรณ์เป็น Metrics ที่ Prometheus อ่านได้, Grafana แสดง Dashboard ส่วน Alerting สามารถใช้ Prometheus Rules ร่วมกับ Alertmanager ได้

ความแตกต่างระหว่าง Metrics, Logs และ Traces

Metrics: ค่าเชิงตัวเลข เช่น Interface Traffic, CPU, Memory, Error Counters
Logs: ข้อความเหตุการณ์ เช่น Link Up/Down, Authentication Failure และ Configuration Change
Traces: เส้นทางการประมวลผลคำขอข้ามบริการ เหมาะกับ Application มากกว่า SNMP Device Monitoring โดยตรง

Prometheus ไม่ใช่ระบบเก็บ Syslog โดยตรง หากต้องการค้นหา Log ควรเชื่อมระบบ Syslog/Loki/Log Platform แยกต่างหาก

2. ออกแบบ Architecture สำหรับ Cisco Network

โครงสร้าง Lab

 Cisco SW01 192.168.99.11 ─┐
 Cisco SW02 192.168.99.12 ─┼── SNMPv3 ── SNMP Exporter :9116
 Cisco R01  192.168.99.13 ─┘                    │
                                                 │ HTTP /snmp
                                      Prometheus :9090
                                                 │ PromQL
                                          Grafana :3000
                                                 │
                                         NOC Dashboard

 Optional: Prometheus Alert Rules → Alertmanager → Email/Webhook

หลักการสำคัญ: Prometheus เป็นฝ่ายเรียก HTTP Endpoint ของ Exporter และ Exporter เป็นฝ่าย Poll SNMP ไปยัง Cisco Device ดังนั้นต้องออกแบบ Firewall Rules ทั้งสองช่วง ไม่ควรเปิด SNMP จาก Internet

แผนผัง Service และ Port

Component	Port/Protocol	หน้าที่
Grafana	TCP 3000	Dashboard / Visualization
Prometheus	TCP 9090	Scrape, Query และ Rule Evaluation
SNMP Exporter	TCP 9116	HTTP Endpoint สำหรับ SNMP Scrape
Cisco Device	UDP 161	SNMPv3 Agent
Alertmanager (Optional)	TCP 9093	Notification Routing

Production: จำกัด Port ให้เฉพาะ Management Network, ใช้ Reverse Proxy/TLS/SSO สำหรับ Web UI และหลีกเลี่ยงการเปิด Port ตรงสู่ Public Internet

3. เตรียม Cisco Switch และ Router สำหรับ SNMPv3

แนวทาง Configuration ใน Lab

ใช้ SNMPv3 แบบ authPriv เพื่อยืนยันตัวตนและเข้ารหัส Traffic คำสั่งและรูปแบบ Algorithm ที่รองรับอาจต่างกันตาม IOS/IOS XE และรุ่นอุปกรณ์ ต้องตรวจสอบด้วย snmp-server ? ก่อนใช้งาน

conf t
snmp-server view NMSVIEW iso included
snmp-server group NMS-GRP v3 priv read NMSVIEW
snmp-server user nmsreader NMS-GRP v3 auth sha AUTH_SECRET priv aes 128 PRIV_SECRET
end
show snmp user
show snmp group

ข้อควรระวัง: เปลี่ยน AUTH_SECRET และ PRIV_SECRET เป็นรหัสผ่านที่แข็งแรง ไม่ใช้ตัวอย่างนี้จริง และกำหนด ACL/Control Plane Policy จำกัด Source IP ของ Monitoring Server ตามความสามารถของแพลตฟอร์ม ตรวจสอบว่ารุ่นอุปกรณ์รองรับ SNMPv3 authPriv และ Algorithm ที่เลือก

Verification ก่อนเชื่อม Prometheus

ตรวจสอบ show snmp user, show snmp group, Reachability ระหว่าง Exporter กับอุปกรณ์ และ SNMPv3 Walk ด้วยเครื่องมือที่ได้รับอนุญาต หลีกเลี่ยงการใช้ SNMPv2c Community แบบ Read-Write ในระบบ Production

4. ติดตั้ง Docker Compose และจัดโครงสร้างโปรเจกต์

Project Structure

network-monitoring/
├── compose.yaml
├── prometheus/
│   ├── prometheus.yml
│   └── rules.yml
├── snmp/
│   └── snmp.yml        # generated and secured
└── grafana/
    └── provisioning/
        └── datasources/
            └── datasource.yml

ตัวอย่างใช้ Docker Compose Plugin (docker compose) บน Linux Server หรือเครื่อง Lab ที่ติดตั้ง Docker แล้ว ควรตรวจสอบ Version และ Image Tag ที่ใช้งานจริงก่อน Deploy และตรึง Version ใน Production

Docker Compose ตัวอย่าง

services:
  prometheus:
    image: prom/prometheus:v3.4.0
    command:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus
      - --storage.tsdb.retention.time=30d
    volumes:
      - ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./prometheus/rules.yml:/etc/prometheus/rules.yml:ro
      - prometheus_data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    restart: unless-stopped

  snmp-exporter:
    image: prom/snmp-exporter:v0.29.0
    volumes:
      - ./snmp/snmp.yml:/etc/snmp_exporter/snmp.yml:ro
    ports:
      - "127.0.0.1:9116:9116"
    restart: unless-stopped

  grafana:
    image: grafana/grafana:12.0.2
    environment:
      GF_SECURITY_ADMIN_USER: admin
      GF_SECURITY_ADMIN_PASSWORD: ${GRAFANA_ADMIN_PASSWORD:?Set GRAFANA_ADMIN_PASSWORD}
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped

volumes:
  prometheus_data:
  grafana_data:

Version หมายเหตุ: Image Tag ด้านบนเป็นตัวอย่างเพื่ออธิบายรูปแบบ ไม่ใช่คำรับรองว่าเป็นรุ่นล่าสุดหรือรองรับกันทุกชุด ให้ตรวจสอบ Tag ที่มีอยู่จริง, Release Notes, Compatibility และ Security Updates ก่อนใช้งาน หากใช้งานจากเครื่องอื่นต้องผ่าน Reverse Proxy หรือ SSH Tunnel เพราะตัวอย่าง Bind เฉพาะ 127.0.0.1

อย่าเก็บรหัสผ่าน Grafana ใน Git; สำหรับ Production ใช้ Docker Secrets หรือ Secret Manager และจัดการสิทธิ์ไฟล์ Environment อย่างเหมาะสม

5. ตั้งค่า SNMP Exporter และ Authentication

SNMP Exporter Configuration

SNMP Exporter ใช้ไฟล์ snmp.yml ที่มี Modules และ Authentication Profiles ซึ่งโครงสร้างขึ้นกับเวอร์ชัน Exporter ควรสร้างจาก snmp_exporter generator และ MIB ที่ถูกต้อง ไม่ควรคัดลอกไฟล์จากเวอร์ชันอื่นมาใช้โดยไม่ตรวจสอบ

# Conceptual example only — merge with generated snmp.yml
# Use an exporter-compatible auth profile for your installed version.
auths:
  cisco_v3:
    version: 3
    username: nmsreader
    security_level: authPriv
    password: "REPLACE_AUTH_SECRET"
    auth_protocol: SHA
    priv_protocol: AES
    priv_password: "REPLACE_PRIV_SECRET"

# Modules such as if_mib must exist in generated snmp.yml.
# Do not replace a full generated config with this excerpt.

Security: SNMPv3 Secrets ในไฟล์ Exporter เป็นข้อมูลอ่อนไหว ให้จำกัด Permission และการเข้าถึง Container; หากระบบรองรับ ให้ใช้ Secret Injection ที่เหมาะสมและไม่ Commit ลง Repository

ทดสอบ Exporter แบบ Manual

curl -G 'http://127.0.0.1:9116/snmp'   --data-urlencode 'target=192.168.99.11'   --data-urlencode 'module=if_mib'   --data-urlencode 'auth=cisco_v3'

ผลลัพธ์ที่ถูกต้องควรเป็น Prometheus Text Metrics ไม่ใช่ HTTP Error หากมี Timeout ให้ตรวจสอบ UDP 161, ACL, SNMPv3 Credential และ Exporter Logs

6. ตั้งค่า Prometheus Scrape Jobs

prometheus.yml สำหรับ Cisco Devices

global:
  scrape_interval: 60s
  evaluation_interval: 60s

rule_files:
  - /etc/prometheus/rules.yml

scrape_configs:
  - job_name: cisco_snmp
    metrics_path: /snmp
    params:
      module: [if_mib]
      auth: [cisco_v3]
    static_configs:
      - targets:
          - 192.168.99.11
          - 192.168.99.12
          - 192.168.99.13
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter:9116

ใน Prometheus UI เปิด Status → Targets เพื่อตรวจสอบสถานะ UP/DOWN และข้อความ Error หากอุปกรณ์ไม่ตอบกลับ ควรตรวจสอบ Exporter ก่อนสรุปว่าอุปกรณ์ล่ม เพราะ Target DOWN อาจเกิดจาก SNMP Authentication, Firewall หรือ Exporter เอง

ตรวจสอบ Configuration

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 snmp-exporter
docker compose logs --tail=100 prometheus

หากใช้ Prometheus Image ที่มี promtool สามารถตรวจสอบไฟล์ Configuration และ Alert Rules ก่อน Reload เพื่อลดความเสี่ยงจาก YAML ผิดรูปแบบ

7. เข้าใจ SNMP Interface Metrics และ PromQL

Counters และ Units

ค่าที่พบบ่อย ได้แก่ ifHCInOctets, ifHCOutOctets, ifInErrors, ifOutErrors, ifOperStatus และ ifHighSpeed ชื่อ Metric จริงขึ้นกับ Generated Module และ Exporter Configuration; ตรวจสอบชื่อจาก Endpoint ก่อนนำไปสร้าง Dashboard

คำนวณ Bandwidth จาก Octet Counters

# Inbound bits per second
rate(ifHCInOctets[5m]) * 8

# Outbound bits per second
rate(ifHCOutOctets[5m]) * 8

# Example: Mbps
rate(ifHCInOctets[5m]) * 8 / 1000000

เหตุผลที่ใช้ rate(): Octet Counters เป็นค่าที่เพิ่มสะสม จึงต้องคำนวณอัตราการเปลี่ยนแปลงตามเวลา Prometheus rate() รองรับ Counter Reset แต่ยังต้องตรวจสอบช่วง Scrape และข้อมูลขาดหาย

คำนวณ Interface Utilization (%)

100 * (rate(ifHCInOctets[5m]) * 8)
  / (ifHighSpeed * 1000000)

ข้อควรระวัง: สูตรนี้ใช้ได้เมื่อ ifHighSpeed ถูก Export เป็น Metric หน่วย Mbps และ Labels จับคู่กันได้ ต้องกรอง Interface ที่ความเร็วมากกว่า 0 รวมถึงพิจารณา Link Aggregation, Negotiated Speed และ Interface ประเภท Virtual

Error Rate และ Interface Status

rate(ifInErrors[5m])
rate(ifOutErrors[5m])
ifOperStatus

ตรวจสอบว่า Metric ชื่อดังกล่าวถูก Export จริงและมี Label ที่จำเป็น ค่า Error เป็นจำนวนเหตุการณ์ต่อวินาที ไม่ใช่เปอร์เซ็นต์ของ Packet โดยตรง หากต้องการ Error Percentage ต้องเลือกตัวหารเป็น Packet Counters ที่สอดคล้องกัน

8. ออกแบบ Grafana Dashboard สำหรับ Network Operations

เชื่อม Prometheus Data Source

apiVersion: 1

datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
    editable: false

บันทึกไฟล์เป็น grafana/provisioning/datasources/datasource.yml จากนั้น Restart Grafana และตรวจสอบว่า Data Source เชื่อมต่อได้

Dashboard Panels ที่ควรมี

Panel	ตัวชี้วัด	วัตถุประสงค์
Network Overview	Device / Exporter Reachability	มองเห็นจุดที่ข้อมูล Monitoring ขาดหาย
Interface Traffic	Inbound / Outbound Mbps	ดูแนวโน้ม Bandwidth
Interface Utilization	% of Interface Speed	ค้นหา Link ที่เสี่ยงอิ่มตัว
Errors / Discards	Error & Discard Rate	ค้นหาปัญหา Physical/Queue
Incident Trends	จำนวนเหตุการณ์ตามช่วงเวลา	เชื่อมข้อมูลกับ Ticket/Syslog ภายนอก
Monitoring Quality	Scrape Duration / Failure	ตรวจสอบสุขภาพระบบ Monitoring เอง

ควรเพิ่ม Variables เช่น site, device, interface เพื่อให้เจ้าหน้าที่เลือกสถานีหรืออุปกรณ์ได้ง่าย และตั้งชื่อ Dashboard ให้สอดคล้องกับ Asset Inventory

9. Alert Rules และ Alert Fatigue

ตัวอย่าง Alert Rules

groups:
  - name: cisco-interface
    rules:
      - alert: CiscoInterfaceHighUtilization
        expr: |
          (100 * rate(ifHCInOctets[5m]) * 8
            / (ifHighSpeed * 1000000)) > 80
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "High interface utilization on {{ $labels.instance }}"
          description: "Investigate sustained inbound utilization."

      - alert: CiscoSNMPScrapeFailed
        expr: up{job="cisco_snmp"} == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "SNMP scrape failed for {{ $labels.instance }}"

กำหนด for: เพื่อกรองเหตุการณ์ชั่วคราว แต่ Threshold 80% เป็นเพียงตัวอย่าง ต้องปรับจาก Baseline, Peak Hour, Link Type และ SLA จริง สำหรับ Link ที่มี Traffic Burst อาจต้องวิเคราะห์ Percentile เพิ่มเติม

สำคัญ: Rule นี้ยังไม่ส่ง Notification จนกว่าจะกำหนด Alertmanager หรือระบบแจ้งเตือนที่รองรับ และควรเพิ่ม Routing, Deduplication, Silence และ Maintenance Window เพื่อหลีกเลี่ยง Alert Flood

แยก Incident กับ Monitoring Failure

Device Down และ SNMP Scrape Failed ไม่ใช่เหตุการณ์เดียวกัน ต้องตรวจสอบ ICMP/SSH/Syslog หรือข้อมูลจากแหล่งอื่นประกอบ ก่อนเปิด Incident ว่าอุปกรณ์หยุดให้บริการจริง

10. Data Retention, Storage และ Backup

กำหนดระยะเวลาเก็บข้อมูล

ตัวอย่าง Compose กำหนด --storage.tsdb.retention.time=30d เพื่อเก็บ Metrics 30 วัน แต่ปริมาณ Storage ขึ้นกับจำนวน Time Series, Cardinality, Scrape Interval และ Retention ควรติดตามการเติบโตของ Disk จริง ไม่ควรประมาณจากจำนวน Device เพียงอย่างเดียว

Cardinality และ Label Design

Labels ที่เปลี่ยนบ่อย เช่น Timestamp, Ticket ID หรือ Log Message ไม่ควรใช้เป็น Prometheus Label เพราะทำให้จำนวน Time Series เพิ่มมากอย่างรวดเร็ว ควรเก็บข้อมูลลักษณะนี้ใน Log/Ticket Database และใช้ Labels ที่คงที่ เช่น site, device, interface

Backup และ Disaster Recovery

สำรอง Prometheus Configuration, Alert Rules, SNMP Generator Files และ Grafana Provisioning พร้อมจัดการ Secrets แยก
สำรอง Grafana Dashboard JSON, Users/Permissions ตามวิธีที่เหมาะกับ Deployment
สำรอง TSDB ด้วยวิธีที่รองรับ เช่น Snapshot/API หรือระบบ Storage Backup ที่ Consistent ไม่คัดลอกไฟล์ขณะเขียนโดยไม่มีแผนรองรับ
ทดสอบ Restore เป็นระยะ และกำหนด RPO/RTO ของ Monitoring Platform

11. Security Hardening สำหรับ Monitoring Platform

แนวทางขั้นต่ำก่อนขึ้น Production

Network Segmentation: วางระบบใน Management VLAN และอนุญาตเฉพาะเส้นทางที่จำเป็น
SNMPv3 authPriv: จำกัด Source IP และใช้บัญชี Read-Only ตามสิทธิ์ที่อุปกรณ์รองรับ
HTTPS และ Authentication: ป้องกัน Grafana/Prometheus ด้วย TLS, SSO/Authentication และ Role-Based Access
Secrets Management: ไม่ใส่ Password ใน Repository หรือ Dashboard Query
Image Lifecycle: Pin Version ที่ผ่านการทดสอบ, ตรวจ Security Advisories และอัปเดตอย่างมี Change Control
Backup/Restore: ทดสอบกู้คืนทั้ง Configuration และ Dashboard
Audit: เก็บประวัติการเปลี่ยน Rule, Dashboard, User และ Data Source

การเปิดใช้งานในเครือข่ายสถานี

กรณีมีหลายสถานี ควรจัด Group ตามสายงาน/สถานี และกำหนด Access Control เพื่อไม่ให้ผู้ใช้งานทั่วไปเข้าถึง Management IP หรือรายละเอียด Topology โดยไม่จำเป็น การเปิด Monitoring ไม่ควรทำให้เกิด Polling Load สูงจนกระทบอุปกรณ์ Production

12. Hands-on Lab: จาก SNMPv3 ถึง Dashboard

Lab Checklist

ขั้นตอน	สิ่งที่ต้องทำ	เกณฑ์ผ่าน
1	ตรวจ SNMPv3 User และ ACL	SNMP Walk จาก Server ที่ได้รับอนุญาตสำเร็จ
2	เตรียม snmp.yml ด้วย Generator	Exporter เริ่มทำงานและไม่มี Config Error
3	ทดสอบ /snmp Endpoint	เห็น Interface Metrics ของอุปกรณ์
4	Deploy Prometheus	Target แสดง UP และมี Metrics
5	Provision Grafana	Query PromQL และแสดงกราฟได้
6	สร้าง Alert Rule	Rule ผ่าน Validation และแสดงใน Prometheus
7	จำลอง Link Load ใน Lab	กราฟสะท้อน Traffic และ Alert ตามเงื่อนไข
8	ทดสอบ Backup/Restore	กู้คืน Dashboard และ Config ได้

คำสั่งตรวจสอบที่ใช้บ่อย

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 prometheus
docker compose logs --tail=100 snmp-exporter
docker compose logs --tail=100 grafana
curl -s http://127.0.0.1:9090/-/healthy

หมายเหตุ: /-/healthy ตรวจสุขภาพ Prometheus Process ไม่ได้ยืนยันว่า Cisco Devices ทุกตัวถูก Scrape สำเร็จ ต้องตรวจ up{job="cisco_snmp"} และหน้า Targets เพิ่มเติม

13. Troubleshooting: เมื่อ Monitoring ไม่แสดงข้อมูล

อาการ	สาเหตุที่เป็นไปได้	วิธีตรวจสอบ
Exporter Timeout	UDP 161 ถูกบล็อก / SNMPv3 ไม่ตรง	ตรวจ ACL, Credentials, Routing, Exporter Logs
Target DOWN	Exporter Error หรือ HTTP Endpoint ผิด	ตรวจ Prometheus Targets และ Query URL
Grafana No Data	Data Source ผิด / Metric ไม่ถูก Export	ตรวจ Data Source, PromQL และ Metric Names
Bandwidth ผิดปกติ	Counter, Units หรือ Interface Speed ไม่ตรง	ตรวจ ifHC*, ifHighSpeed และ Scrape Interval
Alert ไม่ส่ง	ยังไม่ตั้ง Alertmanager/Receiver	ตรวจ Alert Rule, Alertmanager Route, Receiver
Disk เต็ม	Retention/Cardinality สูงเกินไป	ตรวจ TSDB Storage, Series Count, Disk
กราฟขาดช่วง	Packet Loss / Scrape Timeout / Restart	ตรวจ Scrape Duration, Logs และ Network Path

ควรเก็บหลักฐานก่อนแก้ไข เช่น Timestamp, Prometheus Target Error, Exporter Logs, Cisco CLI และ Network Path เพื่อทำ Root Cause Analysis หลังเหตุการณ์

14. Roadmap จาก Lab สู่ Production

ระยะที่ 1: Proof of Concept

เริ่มจาก Switch 1–2 ตัว ตรวจสอบ SNMPv3, Metrics, Grafana และ Dashboard ให้ถูกต้องก่อน

ระยะที่ 2: Pilot Deployment

ขยายเป็น 1 สถานีหรือ 1 Network Zone พร้อมเก็บ Baseline อย่างน้อยหลายช่วงเวลา รวม Peak Hour และทดสอบ Alert Threshold

ระยะที่ 3: Production Rollout

เพิ่ม Inventory, Site Labels, Backup, Alert Routing, Access Control, Monitoring Health และ Maintenance Window โดยค่อย ๆ ขยายจำนวนอุปกรณ์เพื่อประเมิน Scrape Load และ Storage

ระยะที่ 4: Continuous Improvement

นำ Incident, SLA, Capacity Trend และ Change Log มาปรับ Dashboard/Alert ลด False Positive และทำรายงานสำหรับผู้รับผิดชอบเครือข่าย

15. FAQ

Prometheus ใช้แทน Syslog Server ได้หรือไม่?

ไม่ได้โดยตรง Prometheus เน้น Metrics ส่วน Syslog ควรใช้ Log Collector หรือ Log Database แยก แล้วเชื่อม Dashboard ตามความเหมาะสม

ต้องติดตั้ง Agent บน Cisco Switch หรือไม่?

โดยทั่วไปไม่ต้องติดตั้ง Agent บนอุปกรณ์ Cisco เมื่อใช้ SNMP Exporter เพราะ Exporter ทำหน้าที่ Poll SNMP ผ่านเครือข่าย แต่ต้องเปิดและกำหนด SNMP บนอุปกรณ์ให้ถูกต้อง

ใช้ SNMPv2c แทน SNMPv3 ได้ไหม?

อาจใช้ได้ใน Lab หรืออุปกรณ์เก่าที่จำเป็น แต่ SNMPv2c ไม่มีการเข้ารหัส Community String จึงควรใช้ SNMPv3 authPriv เมื่ออุปกรณ์รองรับ

ต้องเก็บ Metrics กี่วัน?

ขึ้นกับ SLA, Capacity Planning, ข้อกำหนดองค์กร และ Storage Budget เริ่มจากระยะที่วัดผลได้ เช่น 30 วัน แล้วประเมินการใช้งานจริงก่อนเพิ่ม Retention

16. สรุป

Network Monitoring Data Platform ที่ดีต้องมีมากกว่ากราฟสวยงาม ต้องเก็บข้อมูลถูกต้อง ตรวจสอบแหล่งข้อมูลได้ แจ้งเตือนอย่างเหมาะสม ปลอดภัย และรองรับการกู้คืนเมื่อระบบ Monitoring เองขัดข้อง

สำหรับทีม Network Operations ควรเริ่มจาก SNMPv3 → SNMP Exporter → Prometheus → Grafana จากนั้นค่อยเพิ่ม Alertmanager, Syslog Correlation, SLA Reporting และ Capacity Forecasting โดยยึดการทดสอบใน Lab และ Change Control ก่อนใช้งาน Production

อ่านต่อ: Network Monitoring Alert Engineering — Alertmanager, Event Correlation, Noise Reduction, Escalation และ On-Call Runbook