Khi Giám sát “Tạm Được” Không Còn Đủ Nữa
Sáu tháng trước, team hạ tầng của chúng tôi đang vận hành một hệ thống lai — khoảng 180 thiết bị mạng trải dài trên ba site, bao gồm switch Cisco, server Linux và một mớ máy Windows cũ kỹ. Zabbix đảm nhiệm kiểm tra uptime cơ bản, cùng với đống shell script chắp vá gửi cảnh báo qua email. Chạy được, cho đến khi không còn chạy được nữa.
Điểm vỡ trận: một core switch âm thầm xuống cấp suốt ba ngày trước khi chết hẳn. Không ai phát hiện ra. CPU tăng đều đặn trong suốt thời gian đó, nhưng hệ thống giám sát không có baseline lịch sử để so sánh — và cũng không có ngưỡng tự động để bắn cảnh báo kiểu “CPU ở mức 75% liên tục 6 tiếng”.
Sự cố đó buộc chúng tôi phải đánh giá lại nghiêm túc. Sau sáu tháng chạy OpenNMS Horizon trên môi trường production, tôi có những con số thực tế và các file cấu hình được đúc kết từ kinh nghiệm thực chiến đáng để chia sẻ.
Nguyên Nhân Gốc Rễ: Kiến trúc Giám sát Không Thể Mở Rộng
Vấn đề căn bản của hầu hết các stack giám sát nhẹ không phải là thiếu tính năng — mà là kiến trúc. Khi bạn poll 200 thiết bị mỗi phút qua SNMP, bạn cần:
- Thu thập SNMP hiệu quả với lịch trình thích ứng
- Time-series database không sụp dưới tải ghi
- Auto-discovery có thể vẽ topology mà không cần nhập thủ công từng thiết bị
- Cảnh báo ngưỡng có hysteresis để tránh alert flapping
Setup Zabbix của chúng tôi ổn với giám sát server. Nhưng SNMP bulk walk qua 6 VLAN lại là chuyện khác — thời gian polling trôi dài ra đều đặn, log đầy tiếng ồn timeout. Vấn đề cốt lõi: SNMP poller của Zabbix coi thiết bị mạng như một host bình thường. Ổn với 10 thiết bị. Đến 180, việc thiếu nhận thức topology trở thành vấn đề vận hành thực sự.
So Sánh Các Giải Pháp Thay Thế
Trước khi quyết định chọn OpenNMS, tôi đã chạy đánh giá ba tuần so sánh ba ứng viên.
LibreNMS
LibreNMS rất xuất sắc cho giám sát thiết bị mạng đơn giản. SNMP auto-discovery hoạt động ngay sau khi cài, UI gọn gàng và biểu đồ băng thông tốt. Tuy nhiên ở quy mô của chúng tôi, backend PHP bộc lộ độ trễ trong quá trình chạy discovery. Mở rộng logic cảnh báo đòi hỏi quá nhiều workaround mà tôi không muốn gánh lâu dài.
Zabbix (giữ làm baseline)
Đã có sẵn. Mạnh cho giám sát server và ứng dụng, nhưng rõ ràng yếu hơn về topology mạng và SNMP auto-discovery. Template thiết bị đòi hỏi cấu hình thủ công nặng nề, và không có model discovery topology native.
OpenNMS Horizon
Nền Java, mã nguồn mở, được xây dựng chuyên biệt cho các trung tâm vận hành mạng. Đường cong học tập dốc nhất trong ba lựa chọn — giao diện web trông có vẻ cũ và cấu hình nặng XML ở nhiều chỗ. Tuy nhiên SNMP collector thực sự được thiết kế đúng mục đích. Nó dùng provisioning daemon (Provisiond) cho auto-discovery, engine polling riêng với lịch trình cấu hình được theo từng service, và RRD/JRobin cho lưu trữ time-series. Sau sáu tháng, độ tin cậy polling là tốt nhất tôi từng thấy ở quy mô này.
Cài đặt OpenNMS Horizon trên Ubuntu 22.04
OpenNMS yêu cầu PostgreSQL và Java 17+. Đây là trình tự cài đặt sẵn sàng production:
Bước 1: Cài đặt Prerequisites
# Cài đặt Java 17
sudo apt update
sudo apt install -y openjdk-17-jdk
# Kiểm tra phiên bản Java
java -version
# Cài đặt PostgreSQL
sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable postgresql
sudo systemctl start postgresqlBước 2: Cấu hình PostgreSQL cho OpenNMS
sudo -u postgres psql -c "CREATE USER opennms WITH PASSWORD 'yourpassword';"
sudo -u postgres psql -c "CREATE DATABASE opennms OWNER opennms;"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE opennms TO opennms;"Bước 3: Thêm Repository OpenNMS và Cài đặt
# Import GPG key
curl -fsSL https://debian.opennms.org/OPENNMS-GPG-KEY | \
sudo gpg --dearmor -o /usr/share/keyrings/opennms.gpg
# Thêm repository
echo "deb [signed-by=/usr/share/keyrings/opennms.gpg] https://debian.opennms.org stable main" | \
sudo tee /etc/apt/sources.list.d/opennms.list
sudo apt update
sudo apt install -y opennms-horizonBước 4: Khởi tạo Schema Database
# Tự động phát hiện Java runtime
sudo /usr/share/opennms/bin/runjava -s
# Cài đặt schema database và hàm IPLIKE
sudo /usr/share/opennms/bin/install -disCác flag install -dis thực hiện cài đặt schema database, cài extension IPLIKE cho PostgreSQL (dùng cho truy vấn dải IP), và khởi tạo cấu hình ban đầu. Lần chạy đầu mất 2–3 phút.
Bước 5: Khởi động OpenNMS
sudo systemctl enable opennms
sudo systemctl start opennms
sudo systemctl status opennmsWeb UI lắng nghe trên port 8980. Thông tin đăng nhập mặc định là admin / admin — hãy đổi ngay sau khi đăng nhập lần đầu qua Admin → Change Password.
Cấu hình SNMP Auto-Discovery
Hầu hết công cụ giám sát ở quy mô này yêu cầu bạn thêm từng thiết bị thủ công. OpenNMS hoạt động khác. Chỉ cần định nghĩa dải IP, trỏ Provisiond daemon vào đó, và việc discovery, phân loại SNMP cùng phát hiện service sẽ diễn ra tự động — không cần cấu hình từng thiết bị riêng lẻ.
Định nghĩa Dải Discovery
Chỉnh sửa /etc/opennms/discovery-configuration.xml:
<discovery-configuration xmlns="http://xmlns.opennms.org/xsd/config/discovery"
packets-per-second="1"
initial-sleep-time="30000"
restart-sleep-time="86400000"
retries="1"
timeout="2000">
<include-range retry="1" timeout="2000">
<begin>192.168.10.1</begin>
<end>192.168.10.254</end>
</include-range>
<include-range retry="1" timeout="2000">
<begin>192.168.20.1</begin>
<end>192.168.20.254</end>
</include-range>
</discovery-configuration>Thiết lập SNMP Community String
Thông tin xác thực được quản lý theo từng subnet qua REST API hoặc màn hình Admin → SNMP Configuration:
# Đặt SNMPv2c community string cho toàn bộ subnet /24
curl -u admin:yourpassword -X PUT \
-H "Content-Type: application/xml" \
-d '<snmp-info><community>public</community><version>v2c</version><port>161</port><retries>2</retries><timeout>1800</timeout></snmp-info>' \
http://localhost:8980/opennms/rest/snmpConfig/192.168.10.0/24Khởi động lại discovery daemon và OpenNMS bắt đầu ping các dải đã định nghĩa, thực hiện SNMP walk trên bất kỳ thiết bị nào phản hồi. Mỗi thiết bị được tự động phân loại theo sysObjectID — Cisco IOS, Juniper JunOS, Linux, Windows — rồi khớp với profile thu thập dữ liệu phù hợp. Mạng 180 thiết bị của tôi được map hoàn chỉnh trong chưa đến năm phút ở lần chạy đầu tiên.
Thiết lập Thu thập Hiệu suất và Cảnh báo Ngưỡng
Đây chính là phần lẽ ra đã cứu được cái switch đó. Ngưỡng được định nghĩa trong /etc/opennms/thresholds.xml và hỗ trợ hysteresis — giá trị rearm — để tránh bão cảnh báo.
Ngưỡng CPU cho Thiết bị Cisco
<group name="cisco" rrdRepository="/var/lib/opennms/rrd/snmp/" ds-type="node">
<!-- Kích hoạt nếu CPU vượt 80% trong 5 lần poll liên tiếp (25 phút với chu kỳ 5 phút) -->
<threshold type="high"
ds-name="CiscoLocalCPU5SecUtil"
ds-label=""
value="80.0"
rearm="70.0"
trigger="5"
description="Sử dụng CPU cao trên thiết bị Cisco"
triggeredUEI="uei.opennms.org/threshold/highThresholdExceeded"
rearmedUEI="uei.opennms.org/threshold/highThresholdRearmed" />
</group>rearm="70.0" là điểm hysteresis — cảnh báo chỉ tắt khi CPU giảm xuống dưới 70%, không phải ngay lúc nó chớp thoáng dưới 80%. Kết hợp với trigger="5" (phải duy trì trong 5 chu kỳ poll liên tiếp ở khoảng 5 phút, tức 25 phút tổng cộng), tình trạng alert flapping giảm hẳn. Trong hai tuần đầu, số lượng false positive của chúng tôi giảm khoảng 90%.
Ngưỡng Băng thông Interface
<group name="mib2-interfaces" rrdRepository="/var/lib/opennms/rrd/snmp/" ds-type="if">
<threshold type="high"
ds-name="ifHCInOctets"
ds-label="ifDescr"
value="800000000"
rearm="700000000"
trigger="3"
description="Lưu lượng ingress interface vượt 800 Mbps" />
</group>Tải lại Ngưỡng Không Cần Khởi động Lại
# Báo hiệu OpenNMS tải lại cấu hình ngưỡng trực tiếp
/usr/share/opennms/bin/send-event.pl \
uei.opennms.org/internal/eventsConfig/reloadDaemonConfig \
--host localhost \
--parm "daemonName Threshd"Kết nối Thông báo
Routing thông báo nằm ở Admin → Configure Notifications. Trong môi trường production, tôi gửi các sự kiện ngưỡng nghiêm trọng đến PagerDuty webhook và các sự kiện ưu tiên thấp hơn qua email. Bộ gửi email tích hợp sử dụng SMTP chuẩn — cấu hình trong /etc/opennms/javamail-configuration.xml.
Trước khi đưa vào vận hành thực tế, hãy kiểm tra toàn bộ pipeline thông báo từ đầu đến cuối:
# Gửi event thử nghiệm để kiểm tra routing thông báo
/usr/share/opennms/bin/send-event.pl \
uei.opennms.org/nodes/nodeLostService \
--host 192.168.10.1 \
--interface 192.168.10.1 \
--service ICMPSố Liệu Thực Tế Sau Sáu Tháng Production
Chạy cấu hình này trên 200+ node trong sáu tháng, đây là những con số thực từ hệ thống của tôi:
- Discovery ban đầu: 180 thiết bị được phân loại hoàn chỉnh trong chưa đến 5 phút
- Overhead polling: ~3% CPU trên VM 4 nhân chuyên dụng với 8 GB RAM
- Nguồn dữ liệu SNMP: 1.200+ metric thu thập mỗi 5 phút mà không bỏ sót lần poll nào
- Nhiễu cảnh báo: giảm từ ~40 false positive mỗi tuần xuống dưới 5 sau khi tinh chỉnh ngưỡng
- Uptime: không cần khởi động lại service OpenNMS trong suốt 180 ngày
Những Hạn chế Thực tế Trước khi Quyết định
OpenNMS không phải công cụ phù hợp với mọi team. Mô hình cấu hình XML có đường cong học tập thực sự đáng kể — hãy dành một tuần đọc tài liệu trước khi kiến trúc thực sự thấm vào đầu. Giao diện web dùng được nhưng sẽ không giành được giải thưởng thiết kế nào. Java runtime nghĩa là cần tối thiểu 4 GB RAM cho deployment vừa phải; 8 GB cho bất kỳ thứ gì vượt 100 node.
Môi trường nhỏ hoặc team không có người ops chuyên trách có lẽ sẽ dùng LibreNMS thích hơn. Với các team hạ tầng cần giám sát SNMP-native ở quy mô thực — thu thập đáng tin cậy, discovery nhận thức topology, cảnh báo ngưỡng mà không cần hợp đồng vendor — OpenNMS đáp ứng được. Không có lần khởi động lại ngoài kế hoạch nào trong 180 ngày là con số không cần thêm bất kỳ điều kiện nào.
