Events-api Concepts

Internal

• events-api User Manual

Event

An event consists of an ordered set of properties which describe the state of a system at the time the property values were read.

By default, an event is not associated with a specific moment in time. However, for most practical situations, the time when properties are read is important, and the instance of such an event is modeled by timed events.

The method Event.isTimed() characterizes the nature of the event. For non-timed events, the method returns false.

All properties of an event are identified by unique names: an event cannot have two properties with the same name.

For complex events, a property can contain in turn an event, recursively.

Property Order

The order in which the properties are are set on the event instance is relevant, and preserved by the event instance. The order in which getProperties() returns the properties reflects the order in which they were set. However, the event implementation must guarantee that the returned list does not contain two properties with the same name. The order of the properties is relevant when the properties are referred by index.

Timed Event

A timed event is an event that has a timestamp. The values of all event's properties are read at the moment in time marked by the timestamp. Event.isTimed() returns true for timed events.

Timestamp Value

For all timed events, the value of the timestamp (in UTC milliseconds) is guaranteed to be available as the "timestamp" (TimedEvent. TIMESTAMP_PROPERTY_NAME) property. The index of the property depends on the type of the event.

Property

A name/value pair with additional attributes, such as type, measure unit, presentation format, etc., carried by an event. The value usually represents the snapshot in time of a certain runtime value, so that is why the terms "property" and "reading" are interchangeably used. An event cannot have two properties with the same name. All properties implement the Property interface. Pre-typed properties are available for use:

• StringProperty
• IntegerProperty
• LongProperty
• TimeProperty
• etc.

As a common use case, Properties are created based on a metric definition.

Property instances can be instantiate directly using the respective constructors, or they can be created with the static factory PropertyFactory.createInstance(...).

Does the format belong here, or at a different level?

Property Reference

Properties can be referred by name or by index.

When are referred by index, the index is relative to the order in which the properties were added to the event. See "Property Order" section. The index is 0-based.

For timed properties, the timestamp can be referred by name as "timestamp" (TimedEvent.) or by index as property 0. If the timestamp was not set on a timed property, getProperty(0) will return null, otherwise it will return

Metric Source

A source of metrics. Implies an underlying mechanism that can be used to obtain a set of values given a set of metric definitions, ideally in a single operation, for performance reasons. However, the implementations are free to define what "efficient reading" means. Example of metric sources:

1. Local O/S instance can be queried for metrics such as free memory, CPU usage or disk space.
2. Remote O/S instance can be queried for metrics such as free memory, CPU usage or disk space over a SSH connections (assuming credentials are available and the system is reachable).
3. The JMX bus of a local or remote Java virtual machine.
4. The management controller (standalone or domain) of a WildFly instance.

A metric source instance must be started before metrics can be collected from it. The start operation usually implies expensive remote connection creation, initial state verification, etc. so metric source implementations should be designed to be started once and then stay in that state indefinitely. However, the underlying connection may break for various reasons during the metric source life, so it may become necessary to re-start a metric source.

Implementations are NOT expected to maintain their own internal threads. The recommended way to manage sources and collect metrics is to do it with external threads/executors.

The implementations must correctly implement equals() and hashCode(), as metric sources will be used as map keys.

OS

Remote OS

Valid addresses:

ssh://username@hostaddress:port

"ssh://" protocol implied:

username@hostaddress:port

JBoss Management Controller

jbosscli://admin@1.2.3.4:9999/

"jbosscli://" implied:

admin@1.2.3.4:9999/

The default value, if not specified, is "localhost:9999".

JMX Bus

jmx://admin:adminpasswd@1.2.3.4:2345

Classpath.

Metric Definition

A metric definition is an instance that contains all the information a metric source needs in order to extract a value (reading) for a specific metric. The reading is instantiated as a property, carried by an event.

Metric Definition ID

The metric definition has an ID which uniquely identifies the metric to a metric source. The ID must not include anything that ties that ID to a specific metric source. The same ID can be given to different metric sources, and each metric source will return a different value of the metric. For example, "PhysicalMemoryTotal" uniquely identifies the total physical memory metric in the context of a local or remote operating system instance, "java.lang:type=Threading.ThreadCount" uniquely identifies the JVM thread count metric in the context of a JVM's platform MBean server and "/subsystem=messaging/hornetq-server=default/jms-queue=DLQ:message-count" uniquely identifies the DLQ queue depth metric for a specific broker node, managed by a JBoss management controller.

Metric Source Address

A specific instance of a metric definition can be associated with a metric source via the metric source address.

Relationship between a Metric Definition and a Metric Source

A metric source receives a metric defintion and if the source recognizes the definitions, it returns a value (reading) associated with that definition, in form of a property instance:

List<Property> collectMetrics(List<MetricDefinition> metricDefinitions) throws MetricException;

The method collects all metrics whose definitions are given as argument. If a value corresponding to a specific metric definition from the list cannot be successfully collected, a Property instance with the correct id, type and base unit must is returned, but its value is null. Implementations may log as WARN more details on why the collection failed. Implementations may choose - and they are encouraged - to attempt to start the source in-line, if the source is not already started. They, however, may chose to signal the fact that the source is not started and request an external start. The metric source will throw an exception if if finds at least a metric definition that has a null or different source. This indicates a programming error, not a runtime collection failure.

A Property instance returned for a specific metric definition has its name equals with the metric definition ID.

OS Metric Defintion

Local:

PhysicalMemoryFree

Remote:

ssh://test-remote-host:22/PhysicalMemoryFree

JBoss CLI Metric Defintion

Default (implies the default local jboss instance):

/subsystem=messaging/hornetq-server=default/jms-queue=DLQ/message-count

Remote:

jbosscli://admin:adminpasswd@1.2.3.4:9999/subsystem=messaging/hornetq-server=default/jms-queue=DLQ/message-count

JMX Metric Defintion

jmx://admin:adminpasswd@1.2.3.4:2345/jboss.as:subsystem=messaging,hornetq-server=default,jms-queue=DLQ/messageCount

Type Hierarchy

Query

A query is a combination of free format, structured text and regular expressions that is interpreted by the events runtime to filter a stream of events. An individual event must be selected by the query (match) in order to be considered for further processing.

A query may contain:

• keywords
• event property filters
• regular expressions
• modifiers (command line options that modify the semantics of the query), such as --case-insensitive, etc.

Keyword Query

A keyword query is a command-line method friendly to filter a stream of events: it consists space-separated, case insensitive words that must be present in the string representation of the event property values, to select the event for further processing or display.

A keyword query is by default case insensitive unless --case-sensitive modifier is specified.

Continue Here

The keyword query is by default case insensitive, unless ... is specified.

When multiple separate keywords are present in query, the query selects the union of events that contain each keyword.

blue red

will return all events that contain "blue" and all events that contain "red". Those events that contain both "blue" and "red" will be represented once in the returned set.

Note that:

blue red

and:

"blue red"

are different.

Keywords are matched against each property.

Event Property Query

Event property values can be queried using the following syntax:

property-name:exact-match

"Property query" and "field query" terms are currently used interchangeably.