Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Mạng
#SNMP#NMS#FCAPS#MIB#텔레메트리
Cập nhật lần cuối · 2026-10-29

SNMP và Hệ thống Quản lý Mạng (NMS)

1. Tổng quan

A. Định nghĩa

SNMP (Simple Network Management Protocol) mô hình hóa thông tin trạng thái của các thiết bị kết nối vào mạng IP (router, switch, máy chủ, máy in, cảm biến IoT, v.v.) thành một tập biến chuẩn hóa (MIB) và cho phép Manager cùng các Agent thu thập, cấu hình và thông báo trạng thái đó qua các bản tin dựa trên UDP, như một giao thức quản lý ở tầng ứng dụng.

Hệ thống Quản lý Mạng (NMS, Network Management System) là một thể chế phần mềm sử dụng các giao thức quản lý như SNMP để giám sát và điều khiển nhiều thiết bị từ một điểm trung tâm, quản lý tích hợp sự cố, hiệu năng, cấu hình, bảo mật và tính cước.

Quản lý mạng không chỉ dừng ở câu hỏi "thiết bị còn sống hay không". Đó là một lĩnh vực kỹ thuật vận hành nhìn hàng nghìn đến hàng vạn thiết bị khác chủng loại qua một màn hình duy nhất bằng một mô hình nhất quán, phát hiện sự cố sớm, dự báo dung lượng và kiểm soát tác động của thay đổi cấu hình. Kể từ khi IETF ban hành SNMP làm chuẩn quản lý cho môi trường TCP/IP năm 1988, nó đã trở thành chuẩn công nghiệp trên thực tế, cung cấp nền tảng cho khả năng tương tác mà ở đó trạng thái có thể được truy vấn theo cùng một cách bất kể nhà cung cấp hay chủng loại thiết bị.

B. Bối cảnh ra đời và sự cần thiết

Cuối thập niên 1980, khi Internet tăng trưởng bùng nổ, cách kiểm tra từng thiết bị của các hãng khác nhau bằng CLI thủ công đã chạm đến giới hạn. Khi mỗi nhà cung cấp đưa ra một giao diện quản lý riêng, người vận hành phải học số hệ lệnh nhiều bằng số thiết bị, và dễ bỏ sót dấu hiệu báo trước của sự cố. SNMP giải quyết điều này bằng ý tưởng đơn giản mà mạnh mẽ rằng "mọi trạng thái của đối tượng được quản lý đều được trừu tượng hóa thành một biến (object) được định địa chỉ bằng OID." Không cần biết nội bộ thiết bị, một manager chỉ cần biết OID 1.3.6.1.2.1.2.2.1.10 (ifInOctets) là có thể đọc số byte nhận của giao diện ở mọi nhà cung cấp theo cùng một cách.

Sự cần thiết được phân rã theo ba trục. Thứ nhất, Khả năng quan sát (Visibility) — chỉ khi nhìn trạng thái của các thiết bị phân tán một cách tập trung và theo thời gian thực mới có thể giữ được SLA. Thứ hai, Vận hành chủ động (Proactive Operation) — các trap dựa trên ngưỡng cho phép nhận biết sự cố trước chứ không phải sau khi nó xảy ra, giảm thời gian khắc phục trung bình (MTTR). Thứ ba, Tự động hóa và Kiểm toán (Automation & Audit) — thay đổi cấu hình và mở rộng dung lượng trở nên lặp lại được bằng script, và lịch sử thay đổi được lưu giữ để đáp ứng quy định và giám sát. Thực tế tại các trung tâm dữ liệu viễn thông và tài chính, hàng trăm nghìn chỉ số mỗi giây do NMS thu thập được dùng làm dữ liệu sơ cấp cho lập kế hoạch dung lượng và phân tích tương quan sự cố.

C. Phạm vi quản lý mạng — FCAPS

ISO/ITU-T phân loại các chức năng quản lý mạng thành năm lĩnh vực FCAPS. SNMP và NMS đóng vai trò nền tảng chung hỗ trợ cả năm lĩnh vực này.

Lĩnh vực Câu hỏi cốt lõi Ví dụ sử dụng SNMP/NMS
Fault (sự cố) "Cái gì hỏng?" Nhận trap/inform, phân tích tương quan cảnh báo, phân tích nguyên nhân gốc
Configuration (cấu hình) "Cái gì được cấu hình và như thế nào?" Lệnh SET, sao lưu cấu hình/quản lý phiên bản, theo dõi thay đổi
Accounting (tính cước) "Ai đã dùng bao nhiêu?" Thu thập ifInOctets/ifOutOctets, quyết toán lưu lượng
Performance (hiệu năng) "Hoạt động tốt đến đâu?" Thu thập chỉ số dựa trên polling, phân tích ngưỡng, dự báo xu hướng
Security (bảo mật) "Ai được phép truy cập?" Xác thực/mã hóa SNMPv3, kiểm soát truy cập (VACM)

FCAPS là một phân loại trừu tượng nhưng mang hàm ý thực tiễn quan trọng. Ví dụ, dữ liệu hiệu năng (P) trở thành chỉ báo dẫn dắt của sự cố (F), và lịch sử thay đổi cấu hình (C) trở thành manh mối then chốt cho phân tích nguyên nhân gốc của sự cố. Vì vậy một NMS trưởng thành liên kết chéo dữ liệu FCAPS trên một mô hình topology duy nhất, cho phép truy vết nhân quả kiểu "thay đổi cấu hình chiều qua đã gây ra sự cố rạng sáng nay."

2. Cấu thành tổng thể của NMS và cơ chế hoạt động của SNMP

NMS gồm Manager thực hiện việc quản lý, các Agent thường trú trên thiết bị được quản lý và công bố trạng thái của chúng, MIB đặc tả các biến có thể quản lý, và các ứng dụng tầng trên lưu trữ, trực quan hóa và tạo cảnh báo trên dữ liệu thu thập. Sơ đồ cấu trúc dưới đây thể hiện quan hệ và luồng dữ liệu của chúng.

graph TB
  subgraph NMS["Nền tảng NMS (trung tâm)"]
    MGR["SNMP Manager<br/>(bộ poll/bộ nhận trap)"]
    TSDB["CSDL chuỗi thời gian<br/>(lưu chỉ số)"]
    ALARM["Bộ cảnh báo/phân tích tương quan"]
    DASH["Bảng điều khiển/báo cáo"]
  end
  subgraph DEV1["Router/switch"]
    AG1["SNMP Agent"]
    MIB1["MIB (đối tượng theo thiết bị)"]
  end
  subgraph DEV2["Máy chủ/lưu trữ"]
    AG2["SNMP Agent"]
    MIB2["MIB"]
  end
  MGR -- "GET/GETBULK (polling, UDP 161)" --> AG1
  MGR -- "GET/SET" --> AG2
  AG1 -- "TRAP/INFORM (UDP 162)" --> MGR
  AG2 -- "TRAP/INFORM" --> MGR
  AG1 --- MIB1
  AG2 --- MIB2
  MGR --> TSDB --> DASH
  MGR --> ALARM --> DASH

A. Các thành phần

Manager là trung tâm của logic quản lý: nó định kỳ truy vấn (poll) các agent để kéo chỉ số về (pull), đồng thời nhận các trap mà agent gửi (push) để nhận biết ngay tình huống bất thường. Manager thường gửi yêu cầu đến cổng UDP 161 và nhận trap trên UDP 162. Agent là một module phần mềm nhúng trong OS của thiết bị, công bố ra bên ngoài dưới dạng biến MIB các bộ đếm do kernel và driver tổng hợp. Agent có tính thụ động (passive): nó đáp ứng khi bị truy vấn, và tự phát bắn một trap khi một điều kiện định trước xảy ra.

MIB (Management Information Base) là một đặc tả mô hình dữ liệu mô tả "thiết bị này có những biến nào và mỗi biến có ý nghĩa gì." MIB là một schema chứ không phải dữ liệu thực; dữ liệu thực được agent điền động tại thời điểm truy vấn và trả về. Các ứng dụng tầng trên (CSDL chuỗi thời gian, phân tích tương quan, bảng điều khiển) lưu trữ và xử lý các chỉ số thô thu thập được thành dạng mà người vận hành có thể diễn giải ý nghĩa.

B. Luồng bản tin SNMP

Hoạt động cơ bản của SNMP chia thành hai chế độ: polling (yêu cầu-đáp ứng) và trap (thông báo bất đồng bộ). Chuỗi trình tự dưới đây cho thấy hai chế độ đan xen nhau thực tế ra sao.

sequenceDiagram
  participant M as "SNMP Manager (NMS)"
  participant A as "SNMP Agent (thiết bị)"
  Note over M,A: Chế độ polling (thu thập hiệu năng định kỳ)
  M->>A: "GetRequest (OID như ifInOctets)"
  A-->>M: "GetResponse (giá trị, nhãn thời gian)"
  M->>A: "GetBulkRequest (truy vấn bảng lớn)"
  A-->>M: "GetResponse (nhiều OID một lần)"
  Note over M,A: Thay đổi cấu hình
  M->>A: "SetRequest (ghi một biến được quản lý)"
  A-->>M: "Response (thành công/lỗi)"
  Note over M,A: Chế độ trap (thông báo sự cố bất đồng bộ)
  A-->>M: "Trap (link down v.v., không đáp ứng)"
  A->>M: "Inform (thông báo yêu cầu xác nhận)"
  M-->>A: "Response (ACK xác nhận nhận)"

Ý nghĩa của các PDU (Protocol Data Unit) chính như sau. GetRequest truy vấn giá trị của một OID cụ thể, còn GetNextRequest duyệt đối tượng kế tiếp trong cây MIB, dùng khi quét toàn bộ một bảng. GetBulkRequest, được thêm trong SNMPv2c, lấy một khối lớn các OID liên tiếp trong một yêu cầu như một biện pháp tối ưu hiệu năng giảm số lần khứ hồi. SetRequest thay đổi một biến có thể ghi. Trap là thông báo không xác nhận mà agent gửi tự phát, còn Inform của SNMPv2c là thông báo tin cậy yêu cầu ACK từ manager, bù lại khả năng mất gói của UDP.

3. Cấu trúc MIB và OID

MIB được tổ chức thành một cây phân cấp, và mỗi nút được định địa chỉ duy nhất toàn cục bằng một OID (Object Identifier), một đường dẫn số nguyên phân tách bằng dấu chấm (.). Nhờ cấu trúc này, đối tượng của bất kỳ nhà cung cấp nào ở bất kỳ đâu trên thế giới đều được nhận dạng không trùng lặp. Ví dụ, nhóm giao diện của MIB-II chuẩn Internet nằm ở 1.3.6.1.2.1.2 (iso.org.dod.internet.mgmt.mib-2.interfaces), và bên dưới nó ifInOctets là 1.3.6.1.2.1.2.2.1.10. Các đối tượng riêng của nhà cung cấp được đăng ký dưới vùng Private Enterprise bên dưới 1.3.6.1.4.1.<số doanh nghiệp>.

graph TD
  ROOT["root"] --> ISO["iso (1)"]
  ISO --> ORG["org (3)"]
  ORG --> DOD["dod (6)"]
  DOD --> INET["internet (1)"]
  INET --> MGMT["mgmt (2)"]
  INET --> PRIV["private (4)"]
  MGMT --> MIB2["mib-2 (1)"]
  MIB2 --> SYS["system (1)"]
  MIB2 --> IF["interfaces (2)"]
  PRIV --> ENT["enterprises (1)"]
  ENT --> VENDOR["MIB riêng của nhà cung cấp<br/>(theo số doanh nghiệp)"]
  IF --> IFT["ifTable -> ifInOctets v.v."]

Điểm cốt lõi của hệ OID là bản thân cấu trúc mang ý nghĩa. Đường dẫn trên cùng biểu thị chủ thể chuẩn hóa (ISO->IETF), đường dẫn ở giữa biểu thị nhóm chức năng (system, interfaces, ip, tcp), và lá biểu thị biến cụ thể. MIB được định nghĩa bằng cú pháp SMI (Structure of Management Information) dựa trên ASN.1, và mỗi đối tượng chỉ định kiểu dữ liệu (Counter32, Gauge32, TimeTicks, v.v.), quyền truy cập (read-only, read-write) và trạng thái (current, deprecated). Các đối tượng dạng bảng (ví dụ danh sách giao diện) phân biệt hàng bằng một chỉ mục (index), chính vì vậy GetNext/GetBulk là bắt buộc khi duyệt bảng.

Trong thực tế, các chỉ số chung (lưu lượng giao diện, CPU, bộ nhớ, thời gian hoạt động) được thu thập bằng MIB-II chuẩn, và các chỉ số riêng của thiết bị (ví dụ nhiệt độ backplane của một switch cụ thể, cường độ ánh sáng thu của một module quang) được bổ sung bằng MIB riêng của nhà cung cấp. Để chuyển các OID thu thập được thành tên mà con người đọc được, NMS nạp trước các tệp MIB bằng một trình biên dịch MIB.

4. So sánh theo phiên bản và bảo mật của SNMP

SNMP đã trải qua ba thế hệ, trong đó đặc biệt bảo mật được tăng cường rất nhiều. Phiên bản đầu v1/v2c kiểm soát truy cập bằng một mật khẩu chia sẻ dạng văn bản thuần gọi là "community string", vốn trên thực tế chạy qua mạng ở dạng không mã hóa và không có khả năng phòng vệ trước việc nghe lén. Điểm yếu chí mạng này là động cơ lớn nhất của thiết kế v3.

Hạng mục SNMPv1 SNMPv2c SNMPv3
Xác thực Community string (văn bản thuần) Community string (văn bản thuần) USM — xác thực dựa trên người dùng (MD5/SHA)
Mã hóa Không Không Mã hóa payload bằng DES/AES
Kiểm soát truy cập Đơn giản Đơn giản VACM — kiểm soát truy cập chi tiết dựa trên view
Truy vấn khối lớn Không hỗ trợ Hỗ trợ GetBulk Hỗ trợ GetBulk
Thông báo tin cậy Chỉ Trap Thêm Inform Inform
Mức bảo mật Thấp Thấp Cao (toàn vẹn, bảo mật, xác thực)

Cốt lõi của SNMPv3 là USM (User-based Security Model) và VACM (View-based Access Control Model). USM cung cấp ba mức bảo mật — noAuthNoPriv (không xác thực hay mã hóa), authNoPriv (chỉ xác thực) và authPriv (xác thực cộng mã hóa) — để có thể chọn theo độ nhạy cảm của môi trường vận hành. Xác thực bảo đảm tính toàn vẹn của bản tin và danh tính người gửi bằng HMAC-SHA, còn mã hóa bảo vệ tính bảo mật của payload bằng AES. VACM kiểm soát tinh vi "người dùng nào được đọc/ghi phần nào (view) của cây MIB", chẳng hạn một người vận hành thuê ngoài chỉ được cấp quyền đọc các chỉ số hiệu năng còn việc thay đổi cấu hình bị chặn.

Lấy một trường hợp cụ thể, các trung tâm dữ liệu trong ngành tài chính thường đặt chính sách cấm mọi thứ ngoài SNMPv3 authPriv để tuân thủ bảo mật. Ngược lại, các cảm biến IoT cấu hình thấp bên trong mạng kín buộc phải dùng v2c vì gánh nặng tính toán mã hóa, nhưng một biện pháp kiểm soát bù trừ được áp dụng bằng cách tách mạng quản lý về vật lý/logic (mạng quản lý OOB, Out-of-Band) để triệt tiêu rủi ro. Như vậy, lựa chọn phiên bản được quyết định trên sự đánh đổi giữa yêu cầu bảo mật và hiệu năng/khả năng tương thích.

5. Giám sát chuyên sâu — polling và trap, RMON

Việc thu thập dữ liệu hiệu năng dùng hai phương pháp bổ trợ lẫn nhau: polling (pull) và trap (push). Polling là phương pháp trong đó manager duyệt tất cả thiết bị theo một chu kỳ cố định (thường 1–5 phút, dưới 30 giây với các tuyến trọng yếu) để kéo chỉ số về; nó phù hợp cho phân tích xu hướng nhưng gây tải cho manager và mạng khi số thiết bị và tuyến tăng lên. Ở quy mô hàng nghìn thiết bị, tích của chu kỳ polling, số đối tượng và số OID chi phối lưu lượng, nên một thiết kế giảm số lần khứ hồi bằng GetBulk và phân tán các bộ poll là bắt buộc.

Trap thì ngược lại thông báo ngay thời điểm thiết bị phát hiện một điều kiện bất thường (link down, vượt ngưỡng, xác thực thất bại), nên độ trễ gần như bằng không. Tuy nhiên vì dựa trên UDP và không xác nhận, chúng có thể bị mất khi mạng tắc nghẽn, và khi sự cố dồn dập một trap storm có thể làm tê liệt manager. Để bù lại, Inform tin cậy cùng với khử rung trap (trap dampening) và phân tích tương quan được thiết kế đồng thời. Khuyến nghị thực tiễn là chia vai trò theo kiểu "polling cho xu hướng và dung lượng, trap cho tính tức thời của sự cố", đồng thời kiểm chứng chéo cả hai trong một engine phân tích tương quan.

Để giảm tải polling của các môi trường lớn, MIB RMON (Remote Monitoring) đã ra đời. RMON để agent (probe) tổng hợp trước thống kê và ra quyết định ngưỡng tại chỗ, rồi chỉ chuyển bản tóm tắt cho manager, nhờ đó thu được các thống kê chi tiết (lịch sử, cảnh báo, sự kiện, ma trận lưu lượng theo từng host) mà không cần manager polling liên tục. Ví dụ, thay vì manager cào số gói mỗi giây theo từng cổng của một switch chi nhánh mỗi phút, một RMON probe tổng hợp theo từng giây và chỉ nâng cảnh báo khi vượt ngưỡng, cắt giảm đồng thời cả băng thông WAN lẫn tải của manager.

6. Chuyên sâu: chuyển dịch sang quản lý dựa trên mô hình và telemetry dạng luồng

SNMP đã là chuẩn trên thực tế hơn 30 năm, nhưng khi bước vào kỷ nguyên đám mây và mạng siêu quy mô, các giới hạn cấu trúc đã bộc lộ. Thứ nhất, vì dựa trên polling nên nó kém hiệu quả cho thu thập độ phân giải cao theo từng giây; thứ hai, các thao tác cấu hình (write) có tính giao dịch và khả năng rollback yếu; và thứ ba, hệ OID khó đọc với con người nên kém thân thiện với tự động hóa. Trước tình hình đó, mô hình quản lý dựa trên mô hình (model-driven) đã nổi lên.

NETCONF (RFC 6241) thay đổi an toàn cấu hình thiết bị như một giao dịch ứng viên (candidate) -> kiểm chứng -> commit dựa trên XML với hỗ trợ rollback, còn YANG là một ngôn ngữ mô hình hóa dữ liệu hiện đại mô tả cấu hình và trạng thái của thiết bị dưới dạng mô hình phân cấp mà con người đọc được. Về phía truy vấn/thực thi, gNMI (gRPC Network Management Interface) do Google đề xuất hỗ trợ telemetry dạng luồng — phương thức trong đó thiết bị đẩy (push) các thay đổi trạng thái đến người đăng ký — trên gRPC/HTTP2, thu được hàng nghìn chỉ số độ phân giải cao mỗi giây mà không cần polling. Các nhà cung cấp đám mây và các ISP lớn đã có xu hướng thay thế hoặc song song hóa polling SNMP bằng telemetry dạng luồng.

Sự chuyển dịch này cũng ăn khớp với Intent-Based Networking (IBN) và AIOps. Một controller dịch "ý định (intent)" được trừu tượng hóa bằng mô hình YANG thành cấu hình thiết bị, và telemetry dạng luồng phản hồi trạng thái thời gian thực để tự động hiệu chỉnh khoảng cách giữa ý định và thực tế. Tuy nhiên, các thiết bị cũ (legacy), IoT, máy in, v.v. vẫn chỉ hỗ trợ SNMP, nên một NMS trong thực tế được thiết kế như một tầng thu thập lai dung nạp cả SNMP (tài sản hiện có) và telemetry (tài sản mới). Nghĩa là SNMP không biến mất mà đang được định nghĩa lại thành "tầng tương thích rộng cho hệ thống cũ".

7. Những điểm cần cân nhắc và hàm ý

Từ góc độ Kỹ sư chuyên nghiệp, cần cân nhắc tổng thể những điều sau khi áp dụng và vận hành SNMP/NMS.

  • Thiết kế ưu tiên bảo mật: Các triển khai mới nên mặc định dùng SNMPv3 authPriv, và với các phân đoạn v2c không thể tránh thì rủi ro nên được triệt tiêu bằng tách mạng quản lý OOB, ACL và luân chuyển định kỳ community string. Quyền ghi SNMP (SET) nên tách các view VACM theo nguyên tắc đặc quyền tối thiểu, và các cổng quản lý (161/162) chỉ nên được cho phép từ mạng quản lý tại tường lửa.
  • Khả năng mở rộng và kiến trúc thu thập: Ở quy mô hàng nghìn đến hàng vạn thiết bị, các bộ poll nên được phân tán theo vùng/phân đoạn và kết hợp với GetBulk, RMON và telemetry dạng luồng. Vì chu kỳ polling × số đối tượng × số OID chi phối tải manager/WAN, nên độ phân giải thu thập cần được phân tầng (tiered polling) theo tầm quan trọng của chỉ số.
  • Phân tích tương quan sự cố và khử nhiễu: Một cơn bão cảnh báo (alarm storm), trong đó một sự cố vật lý đơn lẻ kích hoạt hàng trăm trap, nên được sàng lọc bằng phân tích tương quan, phân tích nguyên nhân gốc (RCA) và khử dựa trên topology để người vận hành tập trung vào tín hiệu then chốt. Các ngưỡng được đặt dưới dạng độ lệch so với đường cơ sở (ngưỡng động) thay vì giá trị tĩnh sẽ giảm cảnh báo giả.
  • Chuẩn mực và sẵn sàng cho tương lai (lộ trình công nghệ): Thiết lập một chiến lược cùng tồn tại dạng lai cho SNMP cũ và NETCONF/YANG cùng telemetry gNMI mới, và tiến hóa hướng tới vận hành dự đoán bằng cách liên kết dữ liệu thu thập với các nền tảng Observability, AIOps và IBN. Việc thống nhất mô hình dữ liệu bằng YANG giúp tự động hóa đa nhà cung cấp và kiểm chứng trước dựa trên digital twin dễ dàng hơn.
  • Quản trị vận hành: Hệ thống hóa quản lý cấu hình các phiên bản MIB, giấy phép MIB riêng và firmware của agent, và tối đa hóa hiệu quả trên vốn đầu tư bằng cách tái sử dụng các chỉ số thu thập cho lập kế hoạch dung lượng, báo cáo SLA và bằng chứng giám sát.

Tài liệu tham khảo

Tóm tắt một câu: SNMP là chuẩn quản lý mạng trừu tượng hóa các đối tượng được quản lý thành các biến MIB được định địa chỉ bằng OID để manager và agent thu thập, cấu hình và thông báo trạng thái qua polling và trap; nó bảo đảm vận hành bằng USM/VACM của v3 và hỗ trợ toàn bộ các lĩnh vực FCAPS, nhưng trong kỷ nguyên đám mây đang tiến hóa thành một thể chế quản lý lai cùng tồn tại với NETCONF/YANG và telemetry dạng luồng.