This short guide can help you plan for your device’s logging parameters from point of installation.
So, you probably want to keep more than what’s in the buffer.
Or, if you don’t, you probably want to make the buffer larger so when you do need it, there’s a chance of some context to the fault that drove you there in the first place.
Interacting with the device
Stop the logging messages from interrupting your command statements.
line con 0 logging synchronous line vty 0 4 logging synchronous
Now you can read the messages without having your commands wrapping in and around them, what level of messages do you want?
If you’re on the console/ssh session of the device, it’s likely you’re there, and you want to see what’s going on.
The default on these two connection types is (7) debugging and you can leave it there.
If you do choose to change them, the commands are simply
logging console <level> logging monitor <level>
Now, choose to keep your logs local or on a central syslog server. It’s not hard to understand why as soon as you’ve more than one or two devices, syslog servers are your friend.
So, for those of you who keep it small and only want the device dealing with the logs, here are your choices.
Setting the level of messages that are kept in the buffer, and the size of the buffer which by default it 4096 bytes (4Kb).
logging buffered <level> logging buffered <4096-2147483647>
For when you’re keeping log messages centrally in a syslog server, here’s your commands.
logging host 18.104.22.168 logging on
To verify your configuration use
You are now setup for a situation where you can enjoy being on the console without the logging messages interfering with your commands and you’ve planned how and where you want your log messages kept.