STDERR

Events & Alarms

All Events and Alarms generated by applications running within the n2svcd framework are written to the STDERR output of the n2svcd binary. When running in production environment as a service, this output is typically directed to /var/log/n2svcd.log but the exact output location may vary.

The output has a format as shown in these example lines:

2021-04-21 16:17:06.862314 {Logic|N2::Application::LuaApp}          [WRN|SV-LU-10005]: NO AGENTS are configured.  Missing <config><agents> in the application configuration?
2021-04-21 16:17:06.867484 {Logic|LuaApp::LuaService|LhoScp-0}      [NTC|SV-LU-10201]: Service LUA library path = '../lua/lib/?.lua;../../n2scp/lua/lib/?.lua'.

This format is intended to be human-read. It is not intended for automated parsing. For automated processing, we strongly recommend using the SNMP Traps which have a fixed interpretation and a non-ambiguous decoding structure.

Specifically, the syntax, order and/or the presence of specific fields in the STDERR output may be modified by site-specific settings, and/or adjusted in new software versions.

The default fields in the output are:

1. The Date & Time,
2. The controlling application name,
3. The source object class,
4. The affected object label (optional),
5. The severity indicator,
6. The alarm or event ID (optional),
7. The message.

Date & Time

The date and time is in local time format YYYY-MM-DD HH:MM:SS.ssssss to the microsecond.

Controlling Application Name

This is the name of the n2svcd Application which originated the message. This name is wrapped in {} curly braces together with the source object class and affected object label.

Where the originator is the n2svcd binary itself, the name n2svcd is substituted.

Source Object Class

This is the class name of the software object which originated the message. This class is wrapped in {} curly braces together with the controlling application name and affected object label.

In most cases this class name will be partially truncated for compactness by removing top-level path components.

When the originating object is not known, or where the originator is the n2svcd binary itself, the class name N2 is substituted.

The class heirarchy is separated by :: double colon characters.

The class is separated from the preceeding controlling application name by a | vertical pipe.

Affected Object Label

This is the name or other label of the software object which is affected by the message.
This class is wrapped in {} curly braces together with the controlling application name and source object class.

This label may be configured, or it may be automatically-assigned.

In most cases the affected object is also the source object. But this is not necessarily the case.

When the affected object is not known, or has no obvious label, this label is omitted.

When present, the label is separated from the preceeding source object class by a | vertical pipe.

Severity Indicator

The severity indicator is a three-character string:

• NTC or WRN for Event (notice or warning).
• ALM or CLR for Alarm (alarm or clear).

It is wrapped in [] square brackets along with the event/alarm ID, from which it is separated by a | vertical pipe.

Event / Alarm ID

The Event/Alarm ID is in format XX-YY-NNNNN where XX an YY are two-character alphanumerics which together indicate the originating module, and NNNNN is a unique five-digit number (with possible leading zeros) that uniquely identifies the nature of the event or alarm.

It is wrapped in [] square brackets along with the severity indicator, from which it is separated by a | vertical pipe.

The XX-YY-NNNNN event/alarm ID can be used in the on-line searchable Alarm Guide to find the associated event/alarm description, parameter description, and recommended action information.

Message

The message string follows. This may be multi-line, which which case the entire prefix is repeated, e.g.:

2021-04-20 16:50:57.840108 {TesterApp|AppInstance|34d30011}          [NTC|DE-MO-10001]: This is a hypothetical multi-...
2021-04-20 16:50:57.840108 {TesterApp|AppInstance|34d30011}          [NTC|DE-MO-10001]: ...-line event message.

Debugging Traces

Debugging traces to STDERR can be globally activated using the --debug, --dump, --spam, or --trace command line flags on the n2svcd binary. They can also be activated using the stderr_debug attribute on the application element in the n2svcd.xml configuration file.

When running under load on a production environment, debugging traces should NEVER be written to STDERR, because of the high latency and overhead which the filesystem I/O adds to the process execution.

However, when running a test or development environment, these flags are often used to investigate complex issues or scenarios.

The output produced by Debug, Dump, or Spam-level tracing is generally identical to the Event / Alarm output as per this example line:

2021-04-21 16:35:13.267133 {IN Tester|N2::TCP::Server|tcp:0.0.0.0:9009} [DBG]: Creating tcp Server for 0.0.0.0:9009.

Note however the following differences.

Severity Indicator

This is one of DBG, DMP, or SPM.

No Trace ID

Debug, Dump, or Spam trace output does not have an ID.

It is absent, and so is the | pipe separator.