Reference Guide

•
Origin—a string representation of the application or component that originated this audit log
entry.
•
Controller ID—the unique identification of the controller that originated the audit log entry.
Applications may contribute to the Audit Log via the Audit Log service. When creating an audit log
entry the user, activity, origin and data must be provided. The time-stamp and controller
identification is populated by the audit log framework. To contribute an audit log entry, use the
post(String user, String origin, String activity, String description)
method provided by the AuditLogService API. This method will return the object that was created.
The strings associated with the user, origin and activity are restricted to a maximum of 255
characters, whereas the description string is restricted to a maximum of 4096 characters.
An example of an application consuming the Audit Log service is described at Auditing with Logs on
page 215.
Alert Logging
The purpose of this subsystem is to allow for management of alert data. The subsystem comprises of
an API which various components can use to generate alert data. The subsystem also provides
means to track and retrieve the recorded information via an internal API as well as via external REST
API. Once an alert entry has been created the state of the alert (active or not) is the only
modification that is allowed.
Alert data is maintained in persistent storage (default retention period is 14 days) and is presented
to the end user via both the UI and REST API layers. The alert framework provides a cleanup task
that is executed daily (by default) that ages out alert data from persistent storage based on the
policy set by the administrator.
An alert consists of the following:
•
Severity—one of Informational, Warning or Critical
•
Time-stamp—The time the alert was created. The time information is persisted in an UTC
format.
•
Description—a string description for the alert
•
Origin—a string representation of the application or component that originated the alert
•
Topic—the topic related to the alert. Users can register for notification when alerts related to
a given topic or set of topics occur
•
Controller ID—the unique identification of the controller that originated the alert
Applications may contribute alerts via the Alert service. When creating an alert the severity, topic,
origin and data must be provided. The time-stamp and controller identification is populated by the
alert framework. To contribute an alert, use the
post(Severity severity, AlertTopic topic, String origin, String data)
method provided by the AlertService API. This method returns the Alert DTO object that was created.
The string associated with the origin is restricted to a maximum of 255 characters, as well as the
data string.
An example of an application consuming the Alert service is described at Posting Alerts on page
212 .
20