Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

Event field format for event collection

Log in to subscribe to topics and get notified when content changes.

Event field format for event collection

Event Management requires all events to use a standard form, regardless of how they arrive at the instance.

In the application navigation filter, enter em_event.list.

Table 1. Event form
Name Description


Event monitoring software that generated the event, such as SolarWinds or SCOM. This field has a maximum length of 100 digits.


Node name, fully qualified domain name (FQDN), IP address, or MAC address that is associated with the event, such as IBM-ASSET. This field has a maximum length of 100 digits.


Optional. Pre-defined event type, such as high CPU, which is used to identify an event record. This field has a maximum length of 100 digits.


Node resource that is relevant to the event. For example, Disk C, CPU-1, the name of a process, or service. This field has a maximum length of 100 digits.

[Metric Name]

Unique name to identify the metric.

[Source instance]

If the em_event.node field is not specified, it is mandatory for alerts to be created automatically. Values for the em_event.event_class field originate from either the source generating the events or by event rule. Name of the machine or software that generated the event. For example, SolarWinds on Corresponding field display name is Source Instance.

[Message key]

Unique event identifier to identify multiple events that relate to the same alert. If this value is empty, it is generated from the Source, Node, Type, Resource, and Metric Name field values. This field has a maximum length of 1024 digits.
em_event.ci_type JSON string that represents a configuration item. For example, {"name":"SAP ORA01","type":"Oracle"}. The CI identifier that generated the event appears in the Additional information field. This field has a maximum length of 1000 digits. Note: Reference pop-ups and click-throughs are hidden by default for read-only fields. For Configuration item and other read only fields, you can optionally change the read-only setting. For more information, see Configure pop-ups on read-only fields .


Event severity options are:
  • Critical: Immediate action is required. The resource is either not functional or critical problems are imminent.
  • Major: Major functionality is severely impaired or performance has degraded.
  • Minor: Partial, non-critical loss of functionality or performance degradation occurred.
  • Warning: Attention is required, even though the resource is still functional.
  • Info: An alert is created. The resource is still functional.
  • Clear: No action is required. An alert is not created from this event. Existing alerts are closed.

[Resolution state]

Optional. If the field is empty, the resolution on corresponding alerts is still pending.Event state from the event source is either New or Closing.
  • New, the resolution on corresponding alerts is open.
  • Closing event state closes corresponding alerts.

[Time of event]

Time that the event occurred in the source system. This field is a GlideDateTime field in UTC or GMT format. This field has a maximum length of 40 digits.


Current processing state of the event:
  • Ready: Event has been received and is waiting to be processed.
  • Processed: Event was successfully processed.
  • Ignored: Value is not in use.
  • Error: Failure occurred while processing the event. For example, the event collection method or event Severity is blank.


If an alert was created as a result of the event, this field contains the unique ID that Event Management generates to identify the alert.


Reason for event generation. Shows extra details about an issue. For example, a server stack trace or details from a monitoring tool. This field has a maximum length of 4000 digits.

[Additional information]

Optional. A JSON string that gives more information about the event. The JSON data is supported for String values only, other value types are not supported. You must convert numbers to String values by enclosing them in double quotes. For example, this value is not supported: {"CPU":100 } while this value is supported: {"CPU":"100"}. Another example of a valid JSON string is: {"evtComponent":"Microsoft-Windows-WindowsUpdateClient","evtMessage":"Installation Failure: Windows failed. Error 0x80070490"}. This information can be used for third-party integration or other post-alert processing. Values in the Additional information field of an Event that are not in JSON key/value format are normalized to JSON key/value format when the event is processed. For example, assume that the following plain text is in the Additional information field “Connection instance is successful”. When the event is processed, all this plain text becomes one JSON string and might not be useful within an alert. In the resultant alert, this string is in the Additional information field in JSON key/value format, containing the data: {“additional_content”: “Connection instance is successful"}.

[Processing Notes]

Display of the events processing log.