Tweet
CPU chạy 20%, RAM còn dư gần nửa, ổ đĩa gần như rảnh rỗi - nhưng ứng dụng vẫn ì ạch, người dùng vẫn than phiền. Rất nhiều người sẽ đi kiểm tra đúng ba chỉ số quen thuộc đó trước tiên, trong khi thủ phạm thật sự lại nằm ở chỗ ít ai nhìn tới: network utilization đang kịch trần. Đây chính là kiểu bottleneck dễ bị bỏ sót nhất, vì "máy chủ khỏe" không đồng nghĩa với "mạng khỏe".
Muốn phát hiện được kiểu lệch pha đó, trước hết phải có đường cơ sở - baseline - được đo từ lúc hệ thống mới vận hành ổn định. Không có baseline, người quản trị không có gì để so sánh "bình thường" là bao nhiêu, và mọi phán đoán chỉ dựa vào cảm tính. Giám sát cũng chia hai tầng: tầng vi mô nhìn vào từng máy cụ thể qua Task Manager, Performance Monitor, Resource Monitor - nơi Counter là một chỉ số đo cụ thể còn Object là nhóm thiết bị hay tiến trình chứa các Counter đó; tầng vĩ mô thì gom toàn bộ hạ tầng về một hệ thống giám sát tập trung, vì không ai đủ sức ngồi canh từng máy một khi hệ thống có vài trăm thiết bị.
Cách các thiết bị mạng báo cáo tình trạng của mình lên hệ thống giám sát tập trung chủ yếu qua SNMP. Mỗi switch, router, máy in đều có thể chạy một SNMP Agent, lưu trữ hàng loạt thông số dưới dạng OID trong một cơ sở dữ liệu gọi là MIB. Phần lớn thời gian, SNMP Manager chủ động gửi GET để hỏi định kỳ - nhưng tình huống đáng chú ý hơn là khi Agent tự động gửi TRAP. Ví dụ thực tế: một cổng uplink trên switch tầng 3 đột ngột rớt link lúc 2 giờ sáng. Agent trên switch đó lập tức bắn một TRAP qua UDP 162 về NMS - vì chạy trên UDP nên đây là kiểu gửi và quên, switch không hề biết NMS có nhận được hay không; từ SNMPv2c/v3, nhiều hệ thống chuyển sang dùng INFORM thay thế, vẫn qua đúng cổng đó nhưng bắt buộc NMS phải gửi ACK xác nhận đã nhận, tránh mất cảnh báo oan uổng khi mạng đang nghẽn đúng lúc cần báo động nhất. Dù bằng TRAP hay INFORM, hệ thống giám sát đẩy cảnh báo cho kỹ sư trực chỉ trong vài giây - thay vì phải đợi đến 8 giờ sáng khi nhân viên văn phòng tầng đó bắt đầu than phiền mất mạng. Đây cũng là lý do SNMPv1/v2c bị xem là rủi ro: community string mặc định "public" truyền dạng plain text, ai chặn được gói tin trên đường truyền là đọc được luôn; SNMPv3 giải quyết bằng xác thực và mã hóa, nên gần như là lựa chọn bắt buộc cho môi trường doanh nghiệp hiện nay.
TRAP báo cho biết có chuyện xảy ra, nhưng muốn biết chính xác chuyện gì thì cần đọc log. Một dòng log Cisco IOS điển hình trông như thế này: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down. Con số 3 ở giữa chính là mức độ nghiêm trọng theo thang Syslog từ 0 đến 7, với 0 là Emergency và 7 chỉ là Debug - số càng nhỏ càng khẩn cấp. Nhìn quen thang này, kỹ sư chỉ cần liếc qua con số là biết ngay nên bỏ qua hay bật dậy xử lý ngay lập tức, không cần đọc hết cả dòng mô tả dài dòng. Khi có hàng chục thiết bị cùng gửi log, dồn tất cả về một Syslog Server qua UDP 514 (hoặc TCP 514, TCP 6514 nếu cần mã hóa TLS) giúp tra cứu tập trung, thay vì phải SSH vào từng thiết bị lục log thủ công mỗi khi có sự cố.
TRAP và log cho biết có sự cố và mô tả sự cố, nhưng để trả lời câu hỏi "ai đang chiếm hết băng thông" thì cần NetFlow. Một tình huống rất quen thuộc: đường WAN của chi nhánh đột nhiên chậm hẳn vào cuối giờ chiều, người dùng phàn nàn, đội mạng bị đổ lỗi trước tiên dù không đổi gì trong cấu hình. Bật NetFlow trên router biên và nhìn vào NetFlow Collector, top talker lộ ra ngay: một máy trong phòng kế toán đang chạy phần mềm sao lưu tự động đẩy dữ liệu lên cloud, chiếm gần 80% băng thông đường WAN suốt hai tiếng liền. NetFlow không hề chặn hay sửa gì cả, nhưng nó biến một cuộc tranh cãi "lỗi ở đâu" thành một con số cụ thể, chấm dứt tranh luận trong vài phút thay vì cả buổi họp đổ lỗi qua lại.
Bên cạnh các chỉ số phần mềm, hạ tầng vật lý cũng cần cảm biến riêng - nhiệt độ, độ ẩm, rò nước, hay cảm biến mở tủ rack - vì một phòng máy quá nóng có thể âm thầm rút ngắn tuổi thọ thiết bị nhiều tháng trước khi bất kỳ ai nhận ra vấn đề qua chỉ số phần mềm. Hệ sinh thái công cụ giám sát hiện nay cũng rất đa dạng, từ các nền tảng thương mại như SolarWinds NPM hay PRTG đến các công cụ mã nguồn mở quen thuộc như Zabbix, Nagios, Cacti, hay Wireshark cho việc soi từng gói tin khi cần đào sâu.
Nhìn lại cả ba lớp công cụ - SNMP báo có chuyện, Syslog mô tả chuyện gì, NetFlow chỉ ra ai gây ra chuyện - sẽ thấy giám sát mạng hiệu quả không phải là nhìn chằm chằm vào một dashboard duy nhất, mà là biết dùng đúng công cụ cho đúng câu hỏi mình đang cần trả lời.
Lần gần nhất bạn phải lần theo dấu vết qua nhiều công cụ giám sát mới tìm ra thủ phạm thật sự là khi nào? Kể lại xem thử nhé.
Muốn phát hiện được kiểu lệch pha đó, trước hết phải có đường cơ sở - baseline - được đo từ lúc hệ thống mới vận hành ổn định. Không có baseline, người quản trị không có gì để so sánh "bình thường" là bao nhiêu, và mọi phán đoán chỉ dựa vào cảm tính. Giám sát cũng chia hai tầng: tầng vi mô nhìn vào từng máy cụ thể qua Task Manager, Performance Monitor, Resource Monitor - nơi Counter là một chỉ số đo cụ thể còn Object là nhóm thiết bị hay tiến trình chứa các Counter đó; tầng vĩ mô thì gom toàn bộ hạ tầng về một hệ thống giám sát tập trung, vì không ai đủ sức ngồi canh từng máy một khi hệ thống có vài trăm thiết bị.
Cách các thiết bị mạng báo cáo tình trạng của mình lên hệ thống giám sát tập trung chủ yếu qua SNMP. Mỗi switch, router, máy in đều có thể chạy một SNMP Agent, lưu trữ hàng loạt thông số dưới dạng OID trong một cơ sở dữ liệu gọi là MIB. Phần lớn thời gian, SNMP Manager chủ động gửi GET để hỏi định kỳ - nhưng tình huống đáng chú ý hơn là khi Agent tự động gửi TRAP. Ví dụ thực tế: một cổng uplink trên switch tầng 3 đột ngột rớt link lúc 2 giờ sáng. Agent trên switch đó lập tức bắn một TRAP qua UDP 162 về NMS - vì chạy trên UDP nên đây là kiểu gửi và quên, switch không hề biết NMS có nhận được hay không; từ SNMPv2c/v3, nhiều hệ thống chuyển sang dùng INFORM thay thế, vẫn qua đúng cổng đó nhưng bắt buộc NMS phải gửi ACK xác nhận đã nhận, tránh mất cảnh báo oan uổng khi mạng đang nghẽn đúng lúc cần báo động nhất. Dù bằng TRAP hay INFORM, hệ thống giám sát đẩy cảnh báo cho kỹ sư trực chỉ trong vài giây - thay vì phải đợi đến 8 giờ sáng khi nhân viên văn phòng tầng đó bắt đầu than phiền mất mạng. Đây cũng là lý do SNMPv1/v2c bị xem là rủi ro: community string mặc định "public" truyền dạng plain text, ai chặn được gói tin trên đường truyền là đọc được luôn; SNMPv3 giải quyết bằng xác thực và mã hóa, nên gần như là lựa chọn bắt buộc cho môi trường doanh nghiệp hiện nay.
TRAP báo cho biết có chuyện xảy ra, nhưng muốn biết chính xác chuyện gì thì cần đọc log. Một dòng log Cisco IOS điển hình trông như thế này: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down. Con số 3 ở giữa chính là mức độ nghiêm trọng theo thang Syslog từ 0 đến 7, với 0 là Emergency và 7 chỉ là Debug - số càng nhỏ càng khẩn cấp. Nhìn quen thang này, kỹ sư chỉ cần liếc qua con số là biết ngay nên bỏ qua hay bật dậy xử lý ngay lập tức, không cần đọc hết cả dòng mô tả dài dòng. Khi có hàng chục thiết bị cùng gửi log, dồn tất cả về một Syslog Server qua UDP 514 (hoặc TCP 514, TCP 6514 nếu cần mã hóa TLS) giúp tra cứu tập trung, thay vì phải SSH vào từng thiết bị lục log thủ công mỗi khi có sự cố.
TRAP và log cho biết có sự cố và mô tả sự cố, nhưng để trả lời câu hỏi "ai đang chiếm hết băng thông" thì cần NetFlow. Một tình huống rất quen thuộc: đường WAN của chi nhánh đột nhiên chậm hẳn vào cuối giờ chiều, người dùng phàn nàn, đội mạng bị đổ lỗi trước tiên dù không đổi gì trong cấu hình. Bật NetFlow trên router biên và nhìn vào NetFlow Collector, top talker lộ ra ngay: một máy trong phòng kế toán đang chạy phần mềm sao lưu tự động đẩy dữ liệu lên cloud, chiếm gần 80% băng thông đường WAN suốt hai tiếng liền. NetFlow không hề chặn hay sửa gì cả, nhưng nó biến một cuộc tranh cãi "lỗi ở đâu" thành một con số cụ thể, chấm dứt tranh luận trong vài phút thay vì cả buổi họp đổ lỗi qua lại.
Bên cạnh các chỉ số phần mềm, hạ tầng vật lý cũng cần cảm biến riêng - nhiệt độ, độ ẩm, rò nước, hay cảm biến mở tủ rack - vì một phòng máy quá nóng có thể âm thầm rút ngắn tuổi thọ thiết bị nhiều tháng trước khi bất kỳ ai nhận ra vấn đề qua chỉ số phần mềm. Hệ sinh thái công cụ giám sát hiện nay cũng rất đa dạng, từ các nền tảng thương mại như SolarWinds NPM hay PRTG đến các công cụ mã nguồn mở quen thuộc như Zabbix, Nagios, Cacti, hay Wireshark cho việc soi từng gói tin khi cần đào sâu.
Nhìn lại cả ba lớp công cụ - SNMP báo có chuyện, Syslog mô tả chuyện gì, NetFlow chỉ ra ai gây ra chuyện - sẽ thấy giám sát mạng hiệu quả không phải là nhìn chằm chằm vào một dashboard duy nhất, mà là biết dùng đúng công cụ cho đúng câu hỏi mình đang cần trả lời.
Lần gần nhất bạn phải lần theo dấu vết qua nhiều công cụ giám sát mới tìm ra thủ phạm thật sự là khi nào? Kể lại xem thử nhé.