Bài 70: Syslog — Facility Và Severity Level, Thu Thập Log Tập Trung

💡 Liên hệ thực tế

Một tòa nhà văn phòng có hàng chục camera an ninh ở mọi tầng, mọi cửa ra vào. Nếu bảo vệ phải chạy đến từng tầng xem trực tiếp từng camera thì không thể phát hiện sự cố kịp thời. Giải pháp thực tế: toàn bộ camera đều truyền tín hiệu về 1 phòng điều khiển trung tâm, nơi bảo vệ chỉ cần ngồi 1 chỗ theo dõi tất cả — và quan trọng hơn, mỗi sự kiện được gắn nhãn mức độ khẩn cấp (có người lạ đột nhập ≠ cửa tự động đóng mở bình thường) để bảo vệ biết cái nào cần xử lý ngay, cái nào chỉ cần ghi nhận.

📹 Syslog trong mạng máy tính đóng đúng vai trò "phòng điều khiển trung tâm" này — thay vì Admin phải SSH vào từng Router/Switch riêng lẻ để xem log, mọi thiết bị đều gửi log về 1 Syslog Server tập trung, mỗi dòng log đều có mức độ nghiêm trọng (Severity Level) rõ ràng để dễ dàng lọc và cảnh báo.

📘 Kiến thức cốt lõi

8 mức Severity Level — số càng nhỏ càng nghiêm trọng:

🎯 Mẹo ghi nhớ thứ tự (từ 0 đến 7): "Emergency – Alert – Critical – Error – Warning – Notice – Informational – Debug". Quy tắc quan trọng nhất cần nhớ: khi cấu hình 1 mức Severity, thiết bị sẽ gửi mức đó và tất cả các mức nghiêm trọng hơn (số nhỏ hơn) — ví dụ đặt mức warnings (4) thì sẽ nhận được cả mức 0, 1, 2, 3, 4, nhưng không nhận mức 5, 6, 7.

Facility — phân loại "nguồn gốc" của log message:

Facility xác định log message đến từ nhóm chức năng nào của hệ thống (không phải mức độ nghiêm trọng). Trên Cisco IOS, mặc định dùng local7, nhưng có thể đổi để phân loại log theo từng loại thiết bị khi gom về cùng 1 Syslog Server — ví dụ dùng local0 cho Router, local1 cho Switch — giúp Syslog Server tự động tách log vào các file riêng biệt thay vì trộn lẫn tất cả vào 1 chỗ.

Ví dụ trên 2 thiết bị khác nhau gửi log về cùng 1 Syslog Server:

Router(config)# logging facility local0

Switch(config)# logging facility local1

📎 Cả 2 lệnh đều dùng chung cú pháp logging facility local<0-7>, chỉ khác số hiệu để Syslog Server phân biệt được nguồn gốc — Router gắn nhãn local0, Switch gắn nhãn local1. Phía Syslog Server (ví dụ rsyslog/syslog-ng) sau đó có thể cấu hình quy tắc lọc theo facility để tự động ghi log của Router và Switch vào 2 file log riêng biệt, thay vì gộp chung khó tra cứu khi có sự cố.

💡 Có thể hình dung: Severity Level = "mức độ khẩn cấp" của sự việc, còn Facility = "phòng ban nào báo cáo" sự việc đó — 2 khái niệm độc lập, dùng kết hợp để lọc log hiệu quả hơn.

Định dạng 1 dòng Syslog message thực tế:

%LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down

📎 Phân tích cấu trúc: LINK là tên module phát sinh message (liên quan đến trạng thái đường truyền), 3 chính là Severity Level (Error), UPDOWN là mnemonic — mã ngắn gọn giúp Admin nhận diện nhanh loại sự kiện khi lướt qua hàng trăm dòng log mà không cần đọc hết câu mô tả.

Cấu hình gửi log về Syslog Server tập trung (đầy đủ thực chiến — có hostname, đồng bộ giờ NTP):

Router(config)# hostname HN-R1
HN-R1(config)# clock timezone ICT 7
HN-R1(config)# ntp server 10.10.10.100
HN-R1(config)# logging on
HN-R1(config)# logging buffered 16384 informational
HN-R1(config)# logging host 10.10.10.60
HN-R1(config)# logging trap informational
HN-R1(config)# logging facility local0
HN-R1(config)# logging source-interface loopback0
HN-R1(config)# logging origin-id hostname
HN-R1(config)# service timestamps log datetime msec localtime

📎 Giải thích từng dòng lệnh:

• hostname HN-R1 — đặt tên thiết bị là HN-R1, tên này sẽ xuất hiện ở đầu dấu nhắc lệnh và quan trọng hơn, sẽ được chèn vào từng dòng log khi kết hợp với logging origin-id hostname bên dưới — đây chính là "chìa khóa" để biết log đến từ máy nào.
• clock timezone ICT 7 — đặt múi giờ hiển thị là ICT (Indochina Time — giờ Việt Nam), lệch +7 giờ so với UTC. Cú pháp chuẩn là clock timezone <tên-múi-giờ> <số-giờ-lệch>; cần cấu hình trước khi đồng bộ NTP để đồng hồ hiển thị đúng giờ địa phương thay vì giờ UTC mặc định.
• ntp server 10.10.10.100 — chỉ định Router đồng bộ thời gian với NTP Server tại 10.10.10.100. Đây là bước bắt buộc phải có trước khi log có ý nghĩa đối chiếu giữa nhiều thiết bị — nếu đồng hồ mỗi Router lệch nhau vài phút, khi tổng hợp log từ nhiều máy để điều tra sự cố sẽ không thể xác định đúng thứ tự sự kiện nào xảy ra trước, sự kiện nào xảy ra sau.
• logging host 10.10.10.60 — khai báo địa chỉ IP của Syslog Server sẽ nhận log, mặc định gửi qua UDP cổng 514.
• logging trap informational — đặt ngưỡng Severity Level là informational (mức 6), nghĩa là Router sẽ gửi mọi mức từ 0 đến 6, chỉ loại trừ mức 7 (Debug) — đây là mức khuyến nghị phổ biến, đủ thông tin quan trọng mà không gây quá tải Syslog Server.
• logging facility local0 — gắn nhãn Facility local0 cho log gửi đi từ Router này, giúp Syslog Server phân biệt được log đến từ Router chứ không phải Switch (nếu Switch được cấu hình local1).
• logging source-interface loopback0 — ép Router luôn dùng địa chỉ IP của Interface Loopback0 làm địa chỉ nguồn khi gửi log, thay vì địa chỉ của Interface vật lý có thể thay đổi tùy đường đi — giúp địa chỉ nguồn trong log ổn định, dễ nhận diện thiết bị trên Syslog Server.
• logging origin-id hostname — chèn thêm tên hostname của thiết bị (đã đặt ở dòng đầu tiên) vào đầu mỗi dòng log gửi đi, ví dụ Router HN-R1 sẽ gửi log dạng HN-R1: %LINK-3-UPDOWN: ... — đây là cách nhận diện log rõ ràng và trực quan nhất, không cần tra ngược qua địa chỉ IP.
• service timestamps log datetime msec localtime — thêm dấu thời gian chi tiết (đến mili-giây, theo giờ địa phương đã đặt ở clock timezone) vào đầu mỗi dòng log — cực kỳ quan trọng để đối chiếu thứ tự sự kiện khi xử lý sự cố giữa nhiều thiết bị, và chỉ thực sự chính xác khi đồng hồ đã được đồng bộ qua NTP.

Làm sao biết 1 dòng log gửi từ thiết bị nào?

Trong thực tế cần kết hợp cả 3 cách sau, vì mỗi cách phục vụ 1 mục đích khác nhau:

⚠️ Nếu chỉ dùng Facility mà không có logging origin-id hostname, nhiều thiết bị cùng cấu hình local0 sẽ không thể phân biệt thiết bị nào với thiết bị nào — Facility chỉ gom nhóm, không định danh riêng từng máy. Vì vậy khuyến nghị luôn bật kèm logging origin-id hostname để đọc log nhanh mà không phải tra ngược qua IP.

Lưu ý về giao thức truyền tải:

Syslog mặc định hoạt động trên UDP — nghĩa là không đảm bảo log message chắc chắn đến được Syslog Server (không có cơ chế xác nhận, khác với TCP). Nếu đường truyền bị nghẽn hoặc gián đoạn ngắn, một số dòng log có thể bị thất lạc mà thiết bị gửi không hề biết. Đây là lý do với các sự kiện cực kỳ quan trọng, Admin thường kết hợp thêm logging buffered (lưu cục bộ trên chính thiết bị) song song với gửi về Syslog Server từ xa, để vẫn có bản sao dự phòng ngay trên Router.

💬 Hỏi & Đáp nhanh

❓ Đặt logging trap debugging (mức 7) có phải là lựa chọn "an toàn nhất" vì nhận được nhiều thông tin nhất không?

❌ Không nên — mức 7 (Debug) sẽ gửi tất cả 8 mức, bao gồm cả những thông tin cực kỳ chi tiết không cần thiết trong vận hành hàng ngày. Điều này dễ làm Syslog Server bị quá tải dung lượng lưu trữ và băng thông, đồng thời khiến Admin khó tìm ra sự kiện quan trọng giữa hàng loạt log vụn vặt. Mức khuyến nghị phổ biến cho vận hành thường xuyên là informational (6); mức debugging chỉ nên bật tạm thời khi đang chủ động troubleshoot 1 sự cố cụ thể.

❓ Vì sao Syslog dùng UDP thay vì TCP, trong khi UDP không đảm bảo tin cậy?

✅ Vì mục tiêu của Syslog là gửi log nhanh, nhẹ, không làm chậm thiết bị đang xử lý sự cố — TCP với cơ chế bắt tay 3 bước và xác nhận gói tin sẽ tạo thêm độ trễ và tải xử lý không cần thiết, đặc biệt bất lợi khi chính thiết bị đang gặp sự cố nghiêm trọng (ví dụ CPU quá tải) lại cần gửi log khẩn cấp ra ngoài. Đánh đổi là chấp nhận rủi ro mất một số message nếu mạng có sự cố tại đúng thời điểm gửi.

❓ Facility và Severity Level, cái nào quyết định thiết bị có gửi log đi hay không?

✅ Chỉ có Severity Level (qua lệnh logging trap <level>) quyết định message có được gửi đi hay không — dựa trên ngưỡng đã cấu hình. Facility chỉ là nhãn phân loại đi kèm mỗi message đã được gửi, giúp Syslog Server sắp xếp/lọc log theo nguồn gốc thiết bị, không ảnh hưởng đến việc message có được gửi hay bị chặn.

📝 Bài tập đánh giá

Câu 1: Nếu Router được cấu hình logging trap warnings, Router sẽ gửi những mức Severity Level nào về Syslog Server?

• A. Chỉ mức 4 (Warning)
• B. Mức 0, 1, 2, 3, 4 (từ Emergency đến Warning)
• C. Mức 4, 5, 6, 7 (từ Warning đến Debug)
• D. Tất cả 8 mức từ 0 đến 7

Câu 2: Vai trò của Facility trong 1 dòng Syslog message là gì?

• A. Quyết định message có được gửi đi hay không
• B. Xác định thời gian message được tạo ra
• C. Phân loại nguồn gốc/nhóm chức năng phát sinh message, giúp Syslog Server sắp xếp log theo thiết bị
• D. Mã hóa nội dung message trước khi gửi

👉 Đáp án:

Câu 1: B — Khi đặt ngưỡng Severity Level, thiết bị gửi mức đó và tất cả các mức nghiêm trọng hơn (số nhỏ hơn); warnings là mức 4, nên gửi các mức 0, 1, 2, 3, 4.

Câu 2: C — Facility là nhãn phân loại nguồn gốc log (ví dụ local0 cho Router, local1 cho Switch), giúp Syslog Server tự động sắp xếp log vào đúng nhóm/file theo thiết bị, không quyết định việc gửi hay chặn message.

📚 Bài viết thuộc khóa học CCNA của VNExperts

🧭 Điều hướng