Logging is very important as we might imagine to troubleshooting issues as well
.
And so for example, when we want to see the log, we can use the show log
command or show logging.
And it's going to give us a list of all of the system messages as well as any
debug that we have been running.
But it also depends a little bit again on that level that we talked about
earlier, as far as what severity level are we tracking.
In order to understand that we do need to start by having a conversation about
the severity levels of the different log messages that can show up from a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the severity levels of the different log messages that can show up from a
system.
Because some messages that enter into the log are absolutely urgent, emergency
level, and others are not.
And so we have eight different levels starting with seven and working their way
down.
Seven, six, five, four, three, two, one, and zero. That's a two and a zero.
There we go.
So at the top here is debugging. So if I'm going to create a debug message or
just enter a command into enable a particular type of debugging, all of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
just enter a command into enable a particular type of debugging, all of the
messages that show up tied to that will be marked with a severity level of
seven.
Six is informational, which is, as the name implies, just sort of something
that doesn't really indicate a problem. It's just there so we know what
happened.
From here, we get into fairly arbitrary listings of criticality levels, such as
notifications and four is warnings.
But we can tell that the level of criticality or how critical something is is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But we can tell that the level of criticality or how critical something is is
getting a little bit worse.
So up to us, whether we think maybe error should have been four or warnings,
three doesn't really matter, our job is simply to memorize the difference of a
very levels.
And I would highly recommend memorizing all of these. Two is going to be
critical. One is going to be an alert, which to me feels like not nearly as
critical as critical, but, you know, is what it is zero.
However, this is an emergency level message. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, this is an emergency level message.
So we mentioned SNMP earlier, we might want to trigger traps on certain levels.
But the way that this works from a Cisco perspective is we get to set the level
for our logging.
And that's going to apply to everything that is included, the level that we set
, plus everything more critical, meaning lower values.
So if I set the level of logging here at warnings, it's also going to include WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I set the level of logging here at warnings, it's also going to include
all of these. If I set it at as high as debugging, well, then it's going to
show me all of them.
And so on and so forth. If I set it to critical, then it's going to only give
me two ones and zeros.
So that is how super parity levels work and why we have a numerical order to
them is because when I set a particular logging level, it's going to grab that
level and everything that's considered to be more critical than the level that
I specified. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I specified.
Now, how exactly does logging happen? Well, we've got different logging
locations that we need to be concerned with.
So let's say something happens, we get an informational message, we need to
decide where it is that that's going to go.
And so there's several different places. First of all, we have the console.
If somebody has plugged into the console, then they want to possibly get that
message right away.
Very likely that's going to be the case. We also have the terminal or otherwise WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Very likely that's going to be the case. We also have the terminal or otherwise
known as the monitor.
So remember that terminal monitor command, if I have terminal monitor on, then
I will see the message there, assuming that the message lands there.
And lastly, we have the buffer. So the buffer is what I see when I do my show
log.
The buffer has so much space and eventually the buffer will expire. So this is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The buffer has so much space and eventually the buffer will expire. So this is
space dependent.
And if I do start to run out of space, old messages will be exhausted.
And maybe that's a problem. Maybe it's not, but we should be aware of the fact
that I might go to a device that had a problem three days ago.
And because of the space in the buffer and the sheer number of log messages it
's getting, we've already lost the log messages that occurred three days ago.
Now each one of these locations in the CLI, we get to set the level of logging. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now each one of these locations in the CLI, we get to set the level of logging.
So console, for example, is going to be set to debugging because we want to see
every message at the console.
But then I can also set a level at the terminal. I can set a level for the
buffer.
And I control this. So for example, if I wanted it at the monitor to be
informational and I don't want to necessarily see the debuggs, well at that
point I will only get everything again, informational and below.
But keep in mind, if I then activate a debug, well the debugging levels aren't WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But keep in mind, if I then activate a debug, well the debugging levels aren't
part of the level that I specified.
I specified informational, which is six and below. And debugging comes in at
seven, which doesn't fit that criteria.
So that is where we have to be careful about it. We might be frustrated. Like,
why am I not getting these debug messages?
Why are they not showing up in the buffer? Maybe the buffer is set to a warning
level to save on space.
So we don't want all of the lower, well I should say higher numbered, but the
lower criticality alerting, I just want to see everything that's warning or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lower criticality alerting, I just want to see everything that's warning or
worse.
And so depending on how I configure this, we can see that we will filter out
some messages, but we will record a lot of, or pretty much all of the rest.
And as is the case in a lot of other networks or corporate networks, we can
also log not just to these three, but also a syslog server.
Is this log server would be a device that exists out on the network somewhere, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Is this log server would be a device that exists out on the network somewhere,
potentially in the cloud?
It just is a device that is offloading the logging from the local device.
So remember, our buffer is limited. We have space concerns on a device. It will
run out. It will cycle out old messages.
Well, syslog server, well, everything has a, you know, a limit. Eventually,
there is less of a limit on the amount of logs that are kept depending on our
settings and depending on the storage space and so on and so forth. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
settings and depending on the storage space and so on and so forth.
So I'll say no limit with air quotes, because we know eventually you will run
out of space. But the idea here is that now the device, which was pushing to
these three different locations, all of these messages, it's also going to push
to a syslog server if we have that configured.
So the way we configure this is with some basic commands, specifically logging,
and then I include the IP address. And that will start to send messages to the
IP address of the syslog server. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
IP address of the syslog server.
I can also specify a source interface. So just like with our pings and our
trace routes, I could specify a source that way we know that a particular log
message came from a particular device.
So maybe I use a loopback address or something like that. So it's always
consistent. And then I can also set the level. And I use that using this trap
word again. So the trap showed up with SNMP here has a slightly different
meaning.
It's simply allowing me to specify the level. So I could again specify WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's simply allowing me to specify the level. So I could again specify
debugging or if I don't want to send debug to the syslog server, maybe I'd send
informational messages, which would send everything other than debugging.
So let's flip over to a iOS XC device here, router three in the lab, and do a
show logging just to kind of see some of this in action.
So at the top of show logging, we actually see the level of logging for console
. So this console set to warnings actually kind of flipped. Usually the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
. So this console set to warnings actually kind of flipped. Usually the
debugging is set to console.
This is what we get for going into a lab device, because who knows what I've
done on this before. But we do see the console set to warnings while monitor is
set to debugging and the buffer is set to debugging, meaning that debug will
actually show up in the buffer, but they won't show up on the console kind of
funny.
So as I space down, we're going to see all of the different log messages. Now
there's a format to these. First of all, we might see sequences, sequence
numbers and timestamps. I don't have those enabled. I'll demonstrate those in a
moment.
From there, we see this percentage sign, which indicates what we call the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
From there, we see this percentage sign, which indicates what we call the
facility, the facility or SYS in this case is supposed to tell us a little bit
about what's happening. Log messages that are tied to each other will commonly
have the same facility.
Next up, we see the level of severity. So a five represents notification. A six
represents informational, but that's right there in the middle surrounded by
the dashes.
And then on the other side of this, we get a message called a mnemonic. The mn
emonic is supposed to give us a little bit more human readable, like information WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
emonic is supposed to give us a little bit more human readable, like information
. For example, we saw with this facility, SYS, we have one type of log message
here, which, oh, funny enough, this looks like when I was messing with the logs
.
So we did a log configuration change, change the buffer logging to debugging,
for example. And then with SYS, we here, we also see a different type of mn
emonic config.
I, there, which tells us, hey, the console configured things. And so from there
, we can see lots of different log messages. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
, we can see lots of different log messages.
Link state up and down would be a severity level of three. You know, we can
tend to take a look and see what qualifies with what a neighbor adjacency and O
SPF is a five and so on and so forth.
So from here, I could enable timestamps. So I can do service timestamps.
Question mark. And then I can decide if I want to let's apply this to log
messages rather.
And then I can decide whether it's uptime that I want to specify or date time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then I can decide whether it's uptime that I want to specify or date time.
So if I say date time, and then I exit the next log message we see, which is
going to show up.
I don't think because of the level, because this is a console connection. So if
I do a, let's just, let's change the logging level actually.
So if I say logging question mark, we see our different options here.
So I'm going to change the console logging level. And then I can specify again,
these names we talked about debugging or critical or just the number itself.
So I'm just going to go back to debugging console, logging console seven. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm just going to go back to debugging console, logging console seven.
Exit. And now we should start to see debug messages again. If I do that show
log, now we see that the console logging is set to debugging.
So that's how we change the different log levels. So now, well, actually, let's
take a look here at this message.
We do see that there's a date and time now associated with this log message. So
before it just started with the facility. Now we see that there's a date and
time.
Or if I wanted to as well, I could do service sequence numbers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or if I wanted to as well, I could do service sequence numbers.
And now we're going to get a sequence number that increments with every log
message. So I do another config T and an exit. Next one should be 151. There we
go.
So we've got a sequence number now. We've got a date time. I could do uptime.
It might say, hey, at one year and one year and two days or something like that
.
But again, we just specified date time here. But these are some of the options
that we have the ability to change the logging level. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we have the ability to change the logging level.
And don't forget the ability to configure a syslog server to offload our logs
so that we don't lose them for any particular reason just by storing them on
the devices.