Tweet
CÁC GIAO THỨC QUẢN TRỊ THIẾT BỊ (tiếp theo)
Cấu hình và xác minh ghi nhật ký hệ thống.
Bảng 9 - 2 Cách cấu hình mức độ thông báo ghi nhật ký cho mỗi dịch vụ nhật ký
Dựa trên thông tin từ Bảng 9-2, việc cấu hình syslog trên router hoặc switch Cisco IOS khá đơn giản. Ví dụ 9-2 minh họa một mẫu cấu hình dựa trên Hình 9-4, trong đó máy chủ syslog có địa chỉ IP 172.16.3.9.
Cả hai switch và router trong hệ thống đều áp dụng chung cấu hình được mô tả trong Ví dụ 9-2. Tuy nhiên, ví dụ này chỉ minh họa quá trình cấu hình trên một thiết bị duy nhất, cụ thể là router R1.
Các mức độ này có thể được đặt bằng số hoặc tên của mức độ nghiêm trọng, như minh họa trong Hình 9-3.
Lệnh show logging được sử dụng để kiểm tra các thiết lập cấu hình hiện tại và xem danh sách các thông báo nhật ký đã được lưu trong bộ đệm (logging buffered).
Ví dụ 9-3 minh họa một mẫu đầu ra, trong đó các cài đặt cấu hình tương ứng với ví dụ 9-2 được tô sáng bằng màu xanh để dễ nhận diện.
Như được minh họa trong Ví dụ 9-3, các phần tô sáng bằng màu xanh hiển thị hai cấp độ thông báo là 'debug' và hai cấp độ khác là 'warning'. Tuy nhiên, trong một số lệnh cấu hình, các cấp độ này lại được tham chiếu thông qua số thay vì tên.
"Hơn nữa, mặc dù không thể xác định trực tiếp từ đầu ra, nhưng trong Ví dụ 9-3, bộ định tuyến R1 không có thông báo nhật ký nào được lưu trong bộ đệm. (Lưu ý rằng bộ đếm hiển thị giá trị 0 cho các thông báo nhật ký trong bộ đệm.)
Nếu có bất kỳ thông báo nào được lưu trong bộ đệm, chúng sẽ xuất hiện ở cuối đầu ra của lệnh. Tuy nhiên, trong trường hợp này, do bộ định tuyến vừa được khởi động, nên chưa có thông báo nào được ghi nhận. (Bạn cũng có thể xóa các thông báo cũ khỏi bộ đệm bằng lệnh clear loggingEXEC.)
Ví dụ tiếp theo minh họa sự khác biệt giữa các mức độ nghiêm trọng của các thông báo nhật ký. Trong ví dụ này, người dùng đã sử dụng lệnh shutdown để tắt giao diện G0/1 trên R1, sau đó kích hoạt lại giao diện này bằng lệnh no shutdown.
Nếu quan sát kỹ các thông báo được tô sáng, bạn sẽ thấy có một số thông báo thuộc mức độ nghiêm trọng 5 và một thông báo thuộc mức độ nghiêm trọng 3. Lệnh cấu hình toàn cục logging buffered 4 trên R1 (xem Ví dụ 9-2) quy định rằng R1 sẽ không lưu trữ các thông báo có mức độ nghiêm trọng 5, nhưng sẽ ghi lại các thông báo có mức độ nghiêm trọng 3 trong bộ đệm.
Ví dụ 9-4 kết thúc bằng việc hiển thị thông báo nhật ký mức độ nghiêm trọng 3 ở cuối đầu ra của lệnh show logging.
Trong tám mức độ nghiêm trọng của thông báo nhật ký, mức debug (7) có vai trò đặc biệt: nó ghi lại các thông báo được tạo ra khi người dùng đăng nhập vào bộ định tuyến hoặc bộ chuyển mạch và thực thi các lệnh debug.
Lệnh debug EXEC cho phép kỹ sư mạng yêu cầu IOS theo dõi các sự kiện nội bộ cụ thể trong thời gian thực và ghi lại chúng dưới dạng thông báo nhật ký. Sau khi lệnh debug được kích hoạt, IOS sẽ tiếp tục giám sát và tạo thông báo mỗi khi xảy ra sự kiện liên quan, ngay cả khi người dùng thực hiện các tác vụ khác hoặc đăng xuất khỏi thiết bị. Việc giám sát này chỉ dừng lại khi người dùng thực thi lệnh no debug với các tham số tương ứng để vô hiệu hóa nó.
Lưu ý: Lệnh debug cung cấp nhiều tùy chọn khác nhau, tương tự như lệnh show, giúp người dùng linh hoạt theo dõi các khía cạnh cụ thể của hoạt động hệ thống theo nhu cầu.
Để hiểu rõ cách lệnh debug hoạt động và cách nó sử dụng các thông báo nhật ký, cách tốt nhất là xem một ví dụ thực tế. Ví dụ 9-5 minh họa quá trình debug các thông báo OSPF Hello trên bộ định tuyến R1 (Hình 9-4). Bộ định tuyến này đã kích hoạt OSPF trên hai giao diện và thiết lập quan hệ láng giềng với bộ định tuyến R2 (RID 2.2.2.2).
Kết quả đầu ra của lệnh debug hiển thị các thông báo nhật ký liên quan đến việc gửi Hello trên bốn giao diện được bật OSPF, cũng như các thông báo Hello nhận được từ ba láng giềng OSPF khác.
Tuy nhiên, với cài đặt hiện tại, các thông báo debug này sẽ không được lưu trong bộ đệm nhật ký cục bộ (do lệnh logging buffered warning chỉ lưu từ mức 4 trở lên). Tương tự, chúng cũng không được gửi đến máy chủ syslog (do lệnh logging trap 4, chỉ gửi thông báo từ mức 4 trở lên).
Người dùng console sẽ tự động thấy các thông báo nhật ký như trong Ví dụ 9-4. Tuy nhiên, như đã đề cập trong phần mô tả Hình 9-1, người dùng kết nối từ xa qua SSH hoặc Telnet vào R1 cần nhập lệnh terminal monitor để xem các thông báo debug.
Ví dụ, nếu một người dùng đăng nhập qua SSH tại thời điểm thu thập đầu ra của Ví dụ 9-4, họ sẽ không thấy các thông báo debug, ngay cả khi lệnh logging monitor debug đã được cấu hình trên R1, trừ khi họ đã chạy lệnh terminal monitor trước đó.
"Việc bật các tùy chọn debug sẽ tiêu tốn tài nguyên CPU của bộ định tuyến và có thể ảnh hưởng đến hiệu suất hoạt động. Bạn có thể theo dõi mức sử dụng CPU bằng lệnh show process cpu, nhưng cần cẩn thận khi sử dụng lệnh debug trên các thiết bị production.
Ngoài ra, mức tiêu thụ CPU sẽ tăng lên nếu có nhiều người dùng CLI nhận được các thông báo debug. Vì vậy, để giảm tải cho CPU, một số hệ thống được cấu hình không hiển thị thông báo debug trên console và thiết bị đầu cuối mà yêu cầu người dùng kiểm tra bộ đệm nhật ký hoặc syslog
Cấu hình và xác minh ghi nhật ký hệ thống.
| Service | To Enable Logging | To Set Message Levels |
| Console | logging console | logging console level-name | level-number |
| Monitor | logging monitor | logging monitor level-name | level-number |
| Buffered | logging buffered | logging buffered level-name | level-number |
| Syslog | logging host address | hostname |
logging trap level-name | level-number |
Dựa trên thông tin từ Bảng 9-2, việc cấu hình syslog trên router hoặc switch Cisco IOS khá đơn giản. Ví dụ 9-2 minh họa một mẫu cấu hình dựa trên Hình 9-4, trong đó máy chủ syslog có địa chỉ IP 172.16.3.9.
Cả hai switch và router trong hệ thống đều áp dụng chung cấu hình được mô tả trong Ví dụ 9-2. Tuy nhiên, ví dụ này chỉ minh họa quá trình cấu hình trên một thiết bị duy nhất, cụ thể là router R1.
Hình 9 - 4 Mô hình mạng mẫu được sử dụng trong các ví dụ ghi nhật ký
Ví dụ 9 - 2 Cấu hình Syslog trên R1
Trước hết, cần lưu ý rằng ví dụ này thiết lập cùng một mức độ thông báo cho cả console và thiết bị đầu cuối với mức 7 – debug. Đồng thời, ví dụ áp dụng mức 4 – warning cho cả bộ đệm và ghi nhật ký vào máy chủ syslog.Các mức độ này có thể được đặt bằng số hoặc tên của mức độ nghiêm trọng, như minh họa trong Hình 9-3.
Lệnh show logging được sử dụng để kiểm tra các thiết lập cấu hình hiện tại và xem danh sách các thông báo nhật ký đã được lưu trong bộ đệm (logging buffered).
Ví dụ 9-3 minh họa một mẫu đầu ra, trong đó các cài đặt cấu hình tương ứng với ví dụ 9-2 được tô sáng bằng màu xanh để dễ nhận diện.
Ví dụ 9 - 3 Xem cài đặt nhật ký đã định cấu hình theo ví dụ trước đó
Việc nắm rõ tên của cả tám cấp độ thông báo nhật ký sẽ rất hữu ích khi phân tích đầu ra của các lệnh. Điều này đặc biệt quan trọng vì hầu hết các lệnh show đều hiển thị cấp độ thông báo dưới dạng tên thay vì số.Như được minh họa trong Ví dụ 9-3, các phần tô sáng bằng màu xanh hiển thị hai cấp độ thông báo là 'debug' và hai cấp độ khác là 'warning'. Tuy nhiên, trong một số lệnh cấu hình, các cấp độ này lại được tham chiếu thông qua số thay vì tên.
"Hơn nữa, mặc dù không thể xác định trực tiếp từ đầu ra, nhưng trong Ví dụ 9-3, bộ định tuyến R1 không có thông báo nhật ký nào được lưu trong bộ đệm. (Lưu ý rằng bộ đếm hiển thị giá trị 0 cho các thông báo nhật ký trong bộ đệm.)
Nếu có bất kỳ thông báo nào được lưu trong bộ đệm, chúng sẽ xuất hiện ở cuối đầu ra của lệnh. Tuy nhiên, trong trường hợp này, do bộ định tuyến vừa được khởi động, nên chưa có thông báo nào được ghi nhận. (Bạn cũng có thể xóa các thông báo cũ khỏi bộ đệm bằng lệnh clear loggingEXEC.)
Ví dụ tiếp theo minh họa sự khác biệt giữa các mức độ nghiêm trọng của các thông báo nhật ký. Trong ví dụ này, người dùng đã sử dụng lệnh shutdown để tắt giao diện G0/1 trên R1, sau đó kích hoạt lại giao diện này bằng lệnh no shutdown.
Nếu quan sát kỹ các thông báo được tô sáng, bạn sẽ thấy có một số thông báo thuộc mức độ nghiêm trọng 5 và một thông báo thuộc mức độ nghiêm trọng 3. Lệnh cấu hình toàn cục logging buffered 4 trên R1 (xem Ví dụ 9-2) quy định rằng R1 sẽ không lưu trữ các thông báo có mức độ nghiêm trọng 5, nhưng sẽ ghi lại các thông báo có mức độ nghiêm trọng 3 trong bộ đệm.
Ví dụ 9-4 kết thúc bằng việc hiển thị thông báo nhật ký mức độ nghiêm trọng 3 ở cuối đầu ra của lệnh show logging.
Ví dụ 9 - 4 Thấy các thông báo Mức độ nghiêm trọng 3 và 5 trên Console, và chỉ các thông báo Mức độ nghiêm trọng 3 trong Buffer.
Lệnh debug và thông báo nhật kýTrong tám mức độ nghiêm trọng của thông báo nhật ký, mức debug (7) có vai trò đặc biệt: nó ghi lại các thông báo được tạo ra khi người dùng đăng nhập vào bộ định tuyến hoặc bộ chuyển mạch và thực thi các lệnh debug.
Lệnh debug EXEC cho phép kỹ sư mạng yêu cầu IOS theo dõi các sự kiện nội bộ cụ thể trong thời gian thực và ghi lại chúng dưới dạng thông báo nhật ký. Sau khi lệnh debug được kích hoạt, IOS sẽ tiếp tục giám sát và tạo thông báo mỗi khi xảy ra sự kiện liên quan, ngay cả khi người dùng thực hiện các tác vụ khác hoặc đăng xuất khỏi thiết bị. Việc giám sát này chỉ dừng lại khi người dùng thực thi lệnh no debug với các tham số tương ứng để vô hiệu hóa nó.
Lưu ý: Lệnh debug cung cấp nhiều tùy chọn khác nhau, tương tự như lệnh show, giúp người dùng linh hoạt theo dõi các khía cạnh cụ thể của hoạt động hệ thống theo nhu cầu.
Để hiểu rõ cách lệnh debug hoạt động và cách nó sử dụng các thông báo nhật ký, cách tốt nhất là xem một ví dụ thực tế. Ví dụ 9-5 minh họa quá trình debug các thông báo OSPF Hello trên bộ định tuyến R1 (Hình 9-4). Bộ định tuyến này đã kích hoạt OSPF trên hai giao diện và thiết lập quan hệ láng giềng với bộ định tuyến R2 (RID 2.2.2.2).
Kết quả đầu ra của lệnh debug hiển thị các thông báo nhật ký liên quan đến việc gửi Hello trên bốn giao diện được bật OSPF, cũng như các thông báo Hello nhận được từ ba láng giềng OSPF khác.
Ví dụ 9 - 5 Sử dụng debug ip ospf hello từ bảng điều khiển của R1
Người dùng console sẽ thấy các thông báo nhật ký do lệnh debug tạo ra ngay sau khi lệnh này chạy xong. Theo cấu hình trong Ví dụ 9-2, lệnh logging console 7 trên R1 cho phép người dùng console nhận được tất cả các thông báo từ mức độ nghiêm trọng 0 đến 7, bao gồm cả thông báo debug (mức 7).Tuy nhiên, với cài đặt hiện tại, các thông báo debug này sẽ không được lưu trong bộ đệm nhật ký cục bộ (do lệnh logging buffered warning chỉ lưu từ mức 4 trở lên). Tương tự, chúng cũng không được gửi đến máy chủ syslog (do lệnh logging trap 4, chỉ gửi thông báo từ mức 4 trở lên).
Người dùng console sẽ tự động thấy các thông báo nhật ký như trong Ví dụ 9-4. Tuy nhiên, như đã đề cập trong phần mô tả Hình 9-1, người dùng kết nối từ xa qua SSH hoặc Telnet vào R1 cần nhập lệnh terminal monitor để xem các thông báo debug.
Ví dụ, nếu một người dùng đăng nhập qua SSH tại thời điểm thu thập đầu ra của Ví dụ 9-4, họ sẽ không thấy các thông báo debug, ngay cả khi lệnh logging monitor debug đã được cấu hình trên R1, trừ khi họ đã chạy lệnh terminal monitor trước đó.
"Việc bật các tùy chọn debug sẽ tiêu tốn tài nguyên CPU của bộ định tuyến và có thể ảnh hưởng đến hiệu suất hoạt động. Bạn có thể theo dõi mức sử dụng CPU bằng lệnh show process cpu, nhưng cần cẩn thận khi sử dụng lệnh debug trên các thiết bị production.
Ngoài ra, mức tiêu thụ CPU sẽ tăng lên nếu có nhiều người dùng CLI nhận được các thông báo debug. Vì vậy, để giảm tải cho CPU, một số hệ thống được cấu hình không hiển thị thông báo debug trên console và thiết bị đầu cuối mà yêu cầu người dùng kiểm tra bộ đệm nhật ký hoặc syslog