Send events over HTTP
StackState Self-hosted v5.1.x
Overview
StackState can either pull events from a data source or can receive pushed events. Pushed events are stored by StackState, while pulled events aren't. Pushed events are stored for the duration of the configured retention period. This page describes how events can be pushed.
There are several ways to send events to StackState. A large number of integrations are provided out of the box that may help you get started. If there is no out of the box integration available, you can send events to StackState using either HTTP or the StackState stac
CLI.
StackState Receiver API
The StackState Receiver API accepts topology, metrics, events and health data in a common JSON object. The default location for the receiver API is the <STACKSTATE_RECEIVER_API_ADDRESS>
, constructed using the <STACKSTATE_BASE_URL>
and <STACKSTATE_RECEIVER_API_KEY>
.
The <STACKSTATE_RECEIVER_API_ADDRESS>
for StackState deployed on Kubernetes or OpenShift is:
The <STACKSTATE_BASE_URL>
and <STACKSTATE_RECEIVER_API_KEY>
are set during StackState installation, for details see Kubernetes install - configuration parameters.
Common JSON object
Topology, metrics, event and health data are sent to the StackState receiver API via HTTP POST. There is a common JSON object used for all messages. One message can contain multiple metrics and multiple events.
Depending on your StackState configuration, received events that are too old will be ignored.
JSON property: "events"
Events can be sent to the StackState Receiver API using the "events"
property of the common JSON object.
All events in StackState relate to a topology element or elements. Any properties of an event can be used to define a log stream in StackState.
Events have the following details:
An event name. this must not start with any of the following prefixes:
eventType
,host
,labels
,message
,name
,tags
,timeReceived
,timestamp
ortitle
. In the example above, the event name isevent.test
.context - Optional. Includes details of the source system for an event. Events that contain a context will be visible in the StackState Events Perspective for views that contain a component with a matching source identifier. Events without a context will be available in StackState as a log stream:
category - The event category. Can be
Activities
,Alerts
,Anomalies
,Changes
orOthers
.element_identifiers - The identifiers for the topology element(s) the event relates to. These are used to bind the event to a topology element or elements.
source - The name of the system from which the event originates, for example AWS, Kubernetes or JIRA.
data - Optional. A list of key/value details about the event, for example a configuration version.
source_identifier - Optional. The original identifier of the event in the source system.
source_links - Optional. A list of links related to the event, for example a dashboard or the event in the source system.
event_type - Describes the event being sent. This should generally end with the suffix
Event
, for exampleConfigurationChangedEvent
,VersionChangedEvent
.msg_text - Required. The text body of the event.
msg_title - Required. The title of the event.
source_type_name - Optional. The source event type name.
tags - Optional. A list of key/value tags to associate with the event.
timestamp - The epoch timestamp for the event.
Send events to StackState
Multiple events can be sent in one JSON message via HTTP POST. You can also send a single event to StackState using the stac
CLI event send
command. For example:
See also
Last updated