Guest

Cisco LocalDirector 400 Series

How-To Set Up LocalDirector Syslog

Cisco - How-To Set Up LocalDirector Syslog

Document ID: 3995

Updated: Jan 31, 2006

   Print

Introduction

This document describes:

  • How syslog works

  • How to set up the LocalDirector to send syslog messages to a device running syslogd

  • How to set up a UNIX-based syslogd server

Messages produced by the LocalDirector that usually go to the console can be collected by sending these messages to a device running a syslogd daemon (syslogd). Syslogd listens on UDP port 514, the syslog port. Syslogging enables you to gain information about LocalDirector traffic and performance, analyze logs for suspicious activity, and troubleshoot problems.

Syslogd can run on a number of operating system platforms. Syslogd is installed when you install UNIX, but you have to configure it. Syslogd usually is not native to Windows-based systems, but syslogd software is available for Windows NT.

Actual meanings of LocalDirector syslog messages are in the LocalDirector documentation.

Before You Begin

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Prerequisites

There are no specific prerequisites for this document.

Components Used

The information in this document is based on Cisco LocalDirector Software.

How Syslog Works

All syslog messages have a logging facility and a level. The logging facility can be thought of as where and the level can be thought of as what.

Logging Facility

The single syslog daemon (syslogd) can be thought of as having multiple pipes. It uses the pipes to decide where to send incoming information based on the pipe on which the information arrives. In this analogy, the logging facilities are the pipes by which the syslogd decides where to send information it receives.

The eight logging facilities commonly used for syslog are local0 through local7:

local0
local1
local2
local3
local4
local5
local6
local7

Levels

There are also different degrees of importance attached to incoming messages. We can think of the levels as what. The LocalDirector can be set to send messages at different levels (these are listed from highest to lowest importance):

Level Numeric Code
emergency 0
alert 1
critical 2
error 3
warning 4
notification 5
informational 6
debug 7

When a LocalDirector is set up to send syslog messages, levels of lower importance include levels of higher importance. For example, if the LocalDirector is set for warning, then error, critical, alert, and emergency messages would also be sent in addition to warning. A debug setting would obviously include messages at all eight levels.

Configuring the LocalDirector to Send Syslog

The syslog syntax is as follows:

syslog host #.#.#.# 
!-- where #.#.#.# is the syslog servers address
 
syslog output X.Y 
!-- where X is the logging facility and Y is the level
 

How does the X number translate to logging facility?

We break down the X number into binary. The last 4 bits comprise the local facility:

16 = 00010000 = local0 
17 = 00010001 = local1 
18 = 00010010 = local2 
19 = 00010011 = local3 
20 = 00010100 = local4 
21 = 00010101 = local5 
22 = 00010110 = local6 
23 = 00010111 = local7

As an example, since 22 = 00010110, and the last 4 bits=0110=decimal 6, this is local6. (A short-cut is to take the X value and subtract 16. For example, 22-16=6, or local6).

The Y number is the level

As an example, if Y=2, messages sent would include those at level 2 (critical), level 1 (alert), and level 0 (emergency). The LocalDirector levels are 0-7; these should not be confused with the logging facilities (which are local0-local7).

Example - syslog 20.7

syslog 20.7

20 equals local4 logging facility

.7 is the level. 7 means debug to the LocalDirector, that is, all messages will be logged.

Example - syslog 23.2

syslog 23.2

23 equals local7 logging facility

.2 is the level. 2 means critical to the LocalDirector, that is, critical, alert, and emergency messages will be logged.

How to Set Up a Syslogd Server

Because syslogd was originally a UNIX concept, the features available in the syslogd products on non-UNIX systems depend on the vendor implementation. Features may include: dividing incoming messages by facility or debug level, or both; resolving the names of the sending devices; reporting facilities; and so on. For information on configuring the non-UNIX syslog server, refer to the vendor's documentation.

To configure syslog on UNIX, perform the following steps:

  1. As root, on SunOS, AIX, HPUX, or Solaris, make a backup of the /etc/syslog.conf file prior to modification.

  2. Modify /etc/syslog.conf to tell the UNIX system how to sort out the syslog messages coming in from the sending devices, that is, which logging_facility.level goes in which file. Make sure there is a tab between the logging_facility.level and file_name.

  3. Make sure the destination file exists and is writable.

  4. The #Comment section at the beginning of syslog.conf usually explains syntax for the UNIX system.

  5. Do not put file information in the ifdef section.

  6. As root, restart syslogd to pick up changes.

Note: Before issuing debug commands, please see Important Information on Debug Commands.

Example - local7.warn

If /etc/syslog.conf is set for:

local7.warn     /var/log/local7.warn

the warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged in the local7.warn file. The notification, informational, and debug messages coming in on the local7 facility will not be logged anywhere.

Example - local7.debug

If /etc/syslog.conf is set for:

local7.debug    /var/log/local7.debug

the debug, informational, notification, warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.debug file.

Example - local7.warn / debug

If /etc/syslog.conf is set for:

local7.warn     /var/log/local7.warn
local7.debug    /var/log/local7.debug

the warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.warn file. The debug, informational, notification, warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.debug file. (In other words, some messages will go to both files!).

Example - *.debug

If /etc/syslog.conf is set for:

*.debug        
/var/log/all.debug

all message levels from all logging facilities will go to this file.

Debugging Syslog

To start syslog in debug (SunOS, AIX, HPUX, or Solaris), you must be root:

ps -ef | grep syslogd 
kill -9 <pid> 
syslogd -d

You should see messages at the beginning as syslogd is reading syslog.conf, such as:

cfline(local7.info        &nbs
p;            &
nbsp;        /var/log/local7.info)
cfline(local7.debug         &n
bsp;            
;       /var/log/local7.debug)
X X X X X X X X X X X X X X X X X X X X X X X 6 X FILE:
/var/log/local7.info
X X X X X X X X X X X X X X X X X X X X X X X 7 X FILE:
/var/log/local7.debug

If these scroll by too quickly to see, try this command:

syslogd -d | more

If there are messages such as:

cfline(local7.info        &nbs
p;            &
nbsp;        /var/log/local7.junk)
syslogd: /var/log/local7.junk: No such file or directory
logmsg: pri 53, flags 8, from pinecone, msg syslogd: /var/log/local7.junk:
No such file or directory

there is a problem in the setup. In the above example, the file did not exist.

Running in debug will also show incoming syslog messages and to which file they are going:

logmsg: pri 275, flags 0, from 10.8.1.76, MSG 14: %SYS-5-CONFIG_I:
Configured 
from console by vty0 (171.68.118.108)
Logging to UNUSED
Logging to FILE /var/log/local7.debug

In this case, we received a message which should have gone to local7.junk and local7.debug, but because local7.junk did not exist, we also got the message:

Logging to UNUSED.

If syslogd -d shows nothing coming in, check to be sure the LocalDirector is sending with the LocalDirector show syslog command. If syslogd information is arriving on the UNIX system, but not going into the proper file, work with the UNIX system administrator or operating system vendor support to correct problems. If the cause of the problem still cannot be determined, syslog may be run in debug and the output redirected to a file as follows:

sh or ksh: 
syslogd -d >  <target_file> 2>&1 

or

csh 
syslogd -d >& <target_file>

Note: Red Hat Linux syslogd must be started with the -r option to capture network output.

Typical UNIX syslog extensions defining levels:

UNIX Extension Meaning
.emerg System unusable, emergencies
.alert Take immediate action, alerts
.crit Critical condition, critical
.err Error message, errors
.warn Warning message, warnings
.notice Normal but significant condition, notifications
.info Informational messages, informational
.debug Debug message, debugging

Related Information

Updated: Jan 31, 2006
Document ID: 3995