Cisco IOS Logging and Syslog Config: Levels, Buffer and Traps - 夜莺博客

Cisco IOS Logging and Syslog Config: Levels, Buffer and Traps

The default Cisco logging configuration is actively unhelpful: the console is chatty, the buffer is tiny, and when the router reloads the evidence disappears with it. Getting logging right is one of the highest-return configuration changes on any device, because it decides whether you diagnose the next incident from a log or from memory. This guide sets severity levels deliberately, sizes the buffer and persistent storage, sends logs to the right destinations, and verifies timestamps so the log is actually usable in a correlator.

Severity levels, and which ones you actually want

Level Name Examples
0 emergencies Device unusable
1 alerts Immediate action needed
2 critical Interface down, power fault
3 errors Error conditions
4 warnings Warning conditions
5 notifications Link up/down, config changes
6 informational Normal events (default)
7 debugging Only with debug output

Logging a level means logging that level and numerically lower. Most production devices belong at level 6 for the remote host, 5 for the local buffer during normal operation, and 7 only temporarily while debugging - level 7 permanently is how a router ends up with a log full of noise and 80% CPU.

A sane baseline configuration

service timestamps log datetime msec localtime show-timezone
service sequence-numbers
logging enable

! local buffer: big enough to survive a busy hour
logging buffered 10000000 informational
logging buffer size 10000000

! destinations
logging host 10.10.50.10 transport udp port 514
logging host 10.10.50.11 transport tcp port 601
logging trap informational
logging source-interface Loopback0
logging facility local6

! keep the console readable when you are on it
logging console warnings
logging monitor warnings
logging synchronous

! rate limiting, so a loop cannot flood the device
logging rate-limit 50 except 5
no logging message-counter syslog

logging source-interface is the line that makes syslog usable at scale: without it, logs arrive with whatever interface the device picked, and correlators produce duplicate or missing entries. Use a loopback that never flaps. service timestamps ... msec localtime show-timezone prevents the classic "log says 08:00 but the incident was at 16:00" mistake - and correct time requires working NTP, which is a prerequisite for meaningful logs.

Surviving a reload: persistent logging

logging persistent url flash0:/MYLOGS size 104857600 filesize 5242880
logging persistent url bootflash:/logs threshold 80 alert
show logging
dir flash0:/MYLOGS
show logging persistent

Persistent logging writes the buffer to flash in rotating files, which is what turns a reboot investigation from guesswork into a timeline. Watch the directory: when the allocation threshold is reached the oldest file is deleted, so size it for the retention you need (100 MB with 5 MB files is a reasonable starting point). Manage flash writes on devices with frequent log storms - or point persistent logging at USB/bootflash with more room.

Per-feature control and filtering

logging discriminator CRYPTO msg-body drops \^%CRYPTO
logging buffered discriminator CRYPTO
logging host 10.10.50.10 discriminator CRYPTO
show logging | include discriminator
show logging | include %LINK-3-UPDOWN
show logging count
show logging history

Discriminators keep known-noisy subsystems out of the buffer without losing them everywhere. Use them sparingly - filters that hide real faults are worse than noisy logs.

Verify, then alert on it

show logging | include Syslog logging
show logging | include Trap logging
show logging | include Buffer logging
show logging | include rate-limited
logging host 10.10.50.10 vrf MGMT
show ip socket | include 514
ping 10.10.50.10 source Loopback0

Confirm three things before you move on: the destination is reachable from the source interface, the trap level is what you intended, and messages are actually arriving at the collector. Then create alerts for what the log is telling you - config changes, interface flapping, authentication failures - rather than leaving someone to read it after the fact. Related reading: building a central rsyslog server, NTP for correct timestamps, Zabbix SNMP monitoring and SNMP troubleshooting.

原文链接:https://www.cisco.com/c/en/us/support/docs/voice/telephony-signaling/212102-Configure-Persistent-Logging-on-Cisco-IO.html