[Man] - The Syslog protocol is another method
for transporting event messages
between our managed devices and systems.
This has been around for a long time
and it was standardized in 2009 by RFC 5424.
Syslog is widely supported on most major operating systems,
including almost all versions of Linux, Unix, Mac OS
and Windows based systems.
In fact, when we look at the debug command
in an earlier lesson, what we're actually seeing
are the messages being sent out to our console
through Syslog.
We've covered NTP, the Network Time Protocol,
in an earlier module as well.
And we discussed the importance of proper configuration
so that all of our devices have their clocks synchronized.
If we're using Syslog, it's really, really important
that we have our date and time settings consistent
throughout the network.
If we don't, then those timestamp Syslog messages
that we use for troubleshooting.
They all have inaccurate reporting
and that's just going to make our job harder
when we're trying to correlate our logs
and when we're trying to examine any information
about events that have happened on our network.
One of the best practices for implementing Syslog
is to store our collected log messages
on a centralized server.
Some of those popular options include Kiwi by Solarwinds,
PRTG and Splunk just to name a few.
The advantage of these centralized tools
is that they can gather Syslog records
from multiple devices throughout the entire network
and provide event correlation.
Not only is this correlation process a best practice,
but depending on your business,
correlation is often mandated.
This correlation is one of the foundations
for effective log analysis.
Different tools will perform this correlation
in various ways, but the overall function
is that they help to pair down the information
that's being presented to us.
If we have a really large event in our network,
we can have a ton of Syslog messages being generated
and sent out to our server.
And so event correlation,
that's going to help recognize redundant information
and it's going to allow us to sort and view what's happening
much, much more efficiently.
Now one thing that you want to be familiar with
regarding Syslog are the message severity levels.
By default there are eight of those severity levels
numbered zero through seven.
You can see those reflected in this table
along with the corresponding definition for each level.
Level zero's log events will be
the most critical emergency alerts
indicating an unstable system while at the other end,
we see level seven's log events
which are informational debug messages
used for troubleshooting.
We also have a way to represent
which system process created the Syslog event
called Syslog facilities.
You can see a list of those available facilities here
and these are all outlined per the RFC 5424
that we mentioned.
So all of these facility codes,
they can tell us if the message was created,
for example, by the mail system.
So if we saw facility number two in our Syslog,
we would know that, that was created by the mail system.
The RFC standard outlines the three different layers
found within the Syslog standard
which is the Syslog content, the Syslog application
and the Syslog transport.
This standard is necessary so that various devices
can create information that can be understood
and interpreted widely within our network.
The content layer of course refers to the information
within the Syslog message itself.
The Syslog application is what generates
and stores the Syslog message
and the Syslog transport layer is used
to send the messages over the network,
most likely to a centralized Syslog server.
If we look at the format of a Syslog message,
there are three main parts to those messages.
We can see the PRI, the header and the message itself.
The PRI or the priority,
that's going to contain the facility and severity codes.
The facility code will be listed first
followed by the severity code.
So in this example, we see the PRI listed at 100
so that would be a facility code of ten
identifying this as a security message
followed by a critical level zero emergency indicator.
Next we see the header
and that's composed of two main fields.
We see the timestamp at which the event was recorded
and we see the host name.
With this host name being that of the machine
which generated the Syslog message.
And the third part are the message contents themselves.
This contains the actual information about the event
that has occurred.
And this can be broken down into two main parts.
First is the tag, followed by the content.
The tag will contain codes
about which particular application
and process ID would be related to the event.
And the content would of course
be the actual message output.
The output we see here is the apache server
has encountered an error.
Syslog services are going to use UDP port 514
for communication by default.
So that's an overview of the format of Syslog
and why that's useful to us for network management.
In our next video, we're going to take a look
at how we can configure our Sysco devices
for Syslog messages generation
using both the internal buffer to store those
and by pointing those to a central repository
for collection.