Syslog Introduction

Syslog is a standard logging facility, standardized within the Syslog working group of the IETF. Software processes use an API to generate messages that the syslog facility writes to organized log files. If configured, syslog can also send messages to remote syslog servers.

NOTE   Luna appliances use rsyslog. This facility provides the same features as syslog with the addition of reliable transport using TCP. Unless relevant to the accuracy of a point being made, this document uses the term syslog rather than rsyslog.

This chapter contains the following sections:

>Structure of a syslog Message

>lunalogs

>Audit Logs

>Interpreting Logs

>Configuring syslog

Structure of a syslog Message

The following image shows an example of a syslog message.

syslog-msg.PNG

1.This field is the date and time.

2.This field is the system host name.

3.This field is the facility keyword, explained below.

4.This field is the log severity level, explained below.

5.This field is the software process that generated the log message.

6.This field is a process-specific log message.

Table 1: syslog Facility Keywords summarizes the facility keywords applicable for the Luna appliance.

Table 1: syslog Facility Keywords

Facility Keyword

Facility Description

kern

kernel messages

user

user-level messages

daemon

system daemons

auth

security/authorization messages

syslog

messages generated internally by syslogd

authpriv

security/authorization messages

cron

clock daemon

local#

local use #, where # is 0 to 7

Table 2: syslog Severity Levels summarizes the log severity levels.

Table 2: syslog Severity Levels

Severity Keyword

Severity Description

emerg/panic

System is unusable

alert

Action must be taken immediately

critical

Critical condition

err/error

Error condition

warn/warn

Warning condition

notice

Normal but significant condition

info

Informational message

debug

Debug-level message

The primary log file is messages, but the SafeNet Luna Network HSM appliance also creates lunalogs.

lunalogs

lunalogs log messages follow a similar format as standard syslog messages with some slight differences. The following image shows an example segment of a lunalogs message. The format up to the second field is identical to that for a syslog message.

lunalogs-msg.bmp

1.The facility keyword for lunalogs varies. A table in relevant sections identifies the facility keyword for the component that writes log messages to lunalogs.

2.This field is the application string, itemized below.

3.This field is the process identifier, if available.

4.lunalogs has a subsidiary severity level, itemized below.

5.This field is the Luna-specific error code associated with the lunalog entry.

6.This field is the description, the format and contents determined by the application identifier of the lunalogs message. In most cases, the description is a concise statement of the issue that led to the log entry (e.g., oamp – “Cobra SQL service online.”). In other cases, the description comprises multiple fields of information, described below in Table 5: Application-Specific Description.

Table 3: lunalogs Application Identifiers summarizes the application identifiers available in a lunalogs message.

Table 3: lunalogs Application Identifiers

Application Identifier

oamp

Recover

NTLS

lunash

cluster

Luna PED Client

hsm_login

certmonitord

pam_swift

sysstatd

AdminAPI

Table 4: lunalogs Severity Levels summarizes the subsidiary log severity levels of lunalogs.

Table 4: lunalogs Severity Levels

Severity Keyword

critical

error

warning

audit

info

debug

Table 5: Application-Specific Description shows the application-specific description for the more comprehensive lunalogs messages.

Table 5: Application-Specific Description

Application

Description Field

NTLS

<message> : <IP address of client> / <application identifier of client>

Example #1:

Client opened session 18478 : HSM1:Part171 : 192.168.0.100/40847

Example #2:

Received a command LUNA_DESTROY_OBJECT and object handle 20262 : 192.168.0.100/40847

lunash

<command> : <account> : <IP address> / <application identifier>

Example #1:

Lush user login : monitor : 192.168.0.100/40847

Example #2:

Command: log show  : monitor : 192.168.0.100/40847

Audit Logs

See Audit Logging for a description of audit logs.

Interpreting Logs

No hard and fast rules exist for how to parse and interpret logs for significant events. For example, a “notice” severity from the IPMI daemon could be significant (e.g., PSU failed) or simply status information (e.g., reading sensors). The following bullets provide some guidance on how to parse log messages.

>Scan for “critical” severity log entries. These logs represent significant events.

>Scan for “error” severity log entries. In most cases, these logs represent significant events.

>Scan for “notify” severity log entries from the ipmievd process and look for “Failure detected asserted”, “Lower Critical going low”, “Upper Critical going high”, “Lower Non-Recoverable going low” and “Upper Non-Recoverable going high.”

>Scan for “crit” severity logs entries for smartd. Look for "Temperature changed" to track internal appliance temperature measured at the hard drive. Look for excessive conditions with the string "reached critical limit" (e.g., temperature).

>Scan for “CRASH AND BURN” in the logs. An instance of this string indicates a programming or logic error.

Configuring syslog

See System Logging for details on how to configure syslog messages in the SafeNet Luna Network HSM appliance.