The simple way to explain it is thus -
Severity is all about how much you want to know.
Do you just want to know there's a problem, or do you want to know every
detail about the problem? That's what severity gives you, it defines how
verbose the box is.
Facility is all about what you want to know. In the unix world, it's not
very useful to log kernel error messages with authentication errors.
You want to know who's been failing logins? You filter for AUTHPRIV
facility. You want to why your web server is misbehaving? Filter on the
DAEMON facility.
Facility is an inherent part of the syslog protocol, but what you do with
facility varies with the syslog daemon. These days, most can route a
syslog entry to a particular file based on facility, which is handy,
because parsing a massive log for a facility can be painful, especially
for monitoring systems.
I have my switches use facility local2, routers local3, things like load
balancers at local4, and so on (easier to remember where what they're
logging to, since their facility more or less matches their layer number).
On 10/4/12 12:52 AM, "ccie99999" <ccie99999_at_gmail.com> wrote:
>man,
>
>this is a golden explanation.
>
>it goes directly to my notes!
>
>I've now understood!
>
>Thanks Lindsay!
>
>On Thu, Oct 4, 2012 at 4:33 AM, Lindsay Hill
><lindsay.k.hill_at_gmail.com>wrote:
>
>> "facility" is separate to severity. They mean different things. Don't
>> confuse the "local0-7" with the severity levels, which also happen to be
>> 0-7.
>>
>> Facility is kind of like having a tag on the logs, so that the syslog
>> server can process them differently - e.g. maybe store them in a
>>different
>> file.
>>
>> Severity is the criticality of the message. You can have different
>> severity logs treated differently, depending on where they are going to.
>> E.g. you might send debug logs to your local buffer, critical messages
>>to
>> the console, notifications to the terminal, and informational to your
>> syslog server. Each destination would be different, so your config would
>> look something like:
>> logging buffered debugging
>> logging console critical
>> logging monitor notification
>> logging trap informational
>>
>> For the specific scenarios you're asking about - log all events up to
>> error - then the command you enter will depend on where you're being
>>asked
>> to send the logs to. It will be "logging {buffered|console|monitor|trap}
>> error"
>>
>>
>> On 4/10/2012, at 5:16 PM, ccie99999 <ccie99999_at_gmail.com> wrote:
>>
>> > Hi guys,
>> >
>> > I have this doubt if someone can clarify..
>> >
>> > I usually don't remember the severity levels so I always do a logging
>> > monitor ? to make sure to see the correct match between numbers and
>> names:
>> >
>> > R1(config)#logging monitor ?
>> > <0-7> Logging severity level
>> > alerts Immediate action needed (severity=1)
>> > critical Critical conditions (severity=2)
>> > debugging Debugging messages (severity=7)
>> > discriminator Establish MD-Console association
>> > emergencies System is unusable (severity=0)
>> > errors Error conditions (severity=3)
>> > filtered Enable filtered logging
>> > informational Informational messages (severity=6)
>> > notifications Normal but significant conditions (severity=5)
>> > warnings Warning conditions (severity=4)
>> > xml Enable logging in XML
>> >
>> > ok, now If I am asked to log all events up to errors, am I correct If
>>I
>> do
>> > a 'logging facility local 3' ?
>> >
>> > if I'm asked to log all events up to notifications am I correct if I
>>do a
>> > 'logging facility local 5' ?
>> >
>> > checking the master index I see this:
>> >
>> > logging facility facility-type Argument
>> >
>> > local0-7
>> >
>> > Reserved for locally defined messages
>> > thanks for your help.
>> >
>> > --
>> > @ccie99999
>> >
>> >
>> > Blogs and organic groups at http://www.ccie.net
>> >
>> >
>>_______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>
>
>--
>@ccie99999
>
>
>Blogs and organic groups at http://www.ccie.net
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sat Oct 06 2012 - 05:35:58 ART
This archive was generated by hypermail 2.2.0 : Thu Nov 01 2012 - 10:53:33 ART