The two primary types of logging supported in the OS are event logging and accounting logs.
Event logging controls the generation, dissemination and recording of system events for monitoring status and troubleshooting faults within the system. The OS groups events into four major categories or event sources.
Events within the OS and have the following characteristics:
a time stamp in UTC or local time
the generating application
a unique event ID within the application
a router name (also called a vrtr-name) identifying the associated routing context (for example, Base or vprn1000)
a subject identifying the affected object for the event (for example, interface name or port identifier)
a short text description
Event control assigns the severity for each application event and whether the event should be generated or suppressed. The severity numbers and severity names supported in the OS conform to ITU standards M.3100 X.733 & X.21 and are listed in Table: Event severity levels.
| Severity number | Severity name |
|---|---|
1 |
cleared |
2 |
indeterminate (info) |
3 |
critical |
4 |
major |
5 |
minor |
6 |
warning |
Events that are suppressed by event control do not generate any event log entries. Event control maintains a count of the number of events generated (logged) and dropped (suppressed) for each application event. The severity of an application event can be configured in event control.
An event log within the OS associates the event sources with logging destinations. Examples of logging destinations include the console session, a specific Telnet or SSH session, memory logs, file destinations, SNMP trap groups and syslog destinations. A log filter policy can be associated with the event log to control which events are logged in the event log based on combinations of application, severity, event ID range, router name (vrtr-name), and the subject of the event.
The OS accounting logs collect comprehensive accounting statistics to support a variety of billing models. The routers collect accounting data on services and network ports on a per-service class basis. In addition to gathering information critical for service billing, accounting records can be analyzed to provide insight about customer service trends for potential service revenue opportunities. Accounting statistics on network ports can be used to track link utilization and network traffic pattern trends. This information is valuable for traffic engineering and capacity planning within the network core.
Accounting statistics are collected according to the parameters defined within the context of an accounting policy. Accounting policies are applied to customer Service Access Points (SAPs) and network ports. Accounting statistics are collected by counters for individual service queues defined on the customer’s SAP or by the counters within forwarding class (FC) queues defined on the network ports.
The type of record defined within the accounting policy determines where a policy is applied, what statistics are collected and time interval at which to collect statistics.
The supported destination for an accounting log is a compact flash system device. Accounting data is stored within a standard directory structure on the device in compressed XML format. On platforms that support multiple storage devices, Nokia recommends that accounting logs be configured on the cf1: or cf2: devices only. Accounting log files are not recommended on the cf3: device if other devices are available (Nokia recommends that cf3: be used primarily for software images and configuration related files).