Each data processing stage communicates with other stages via events, which allows us to decouple consumers and producers and seamlessly rearrange the stages should the need arise.
\nEach event has an associated category, which determines whether a specific stage can subscribe to or publish that event. There are two public categories for data-related events:<\/p>\n

data:observation<\/strong> \u2013 a category of events with publish-only permissions which can be thought of as side-effects of processing the original event, for example, an entity derived from resource attributes in OpenTelemetry metric packet. Observations are indicated with upward \u2018publish\u2019 arrows in the above diagram. Taps, workflows and plugins can all produce observations. Observations can only be subscribed to by specific taps.
\ndata:trigger<\/strong> \u2013 subscribe-only events that are emitted after all the mutations have completed. Triggers are indicated with a lightning \u2018trigger\u2019 icon in the above diagram. Only workflows (post-processing logic) can subscribe to triggers, and only specific taps can publish them.<\/p>\n

There are five observation event types in the platform:<\/p>\n

entity.observed<\/strong> \u2013 FMM entity was discovered while processing some data. It can be a new entity or an update to an existing entity. Each update from the same source fully replaces the previous one.
\nassociation.observed<\/strong> \u2013 FMM association was discovered while processing some data. Depending on the cardinality of the association the update logic differs
\nextension.observed<\/strong> \u2013 FMM extension attributes were discovered while processing some data. A target entity must already exist.
\nmeasurement.received<\/strong> \u2013 a measurement event which contributes to a specific FMM metric. These measurements will be aggregated into a metric in Metric aggregation tap. Aggregation logic depends on the metric\u2019s content type.
\nevent.received<\/strong> \u2013 raises a new FMM event. This event will also be processed by the Event processing tap, just like externally ingested events.<\/p>\n

There are 3 trigger event types in the platform, one for each data kind: metric.enriched<\/strong>, event.enriched<\/strong>, trace.encriched<\/strong>. All three events are emitted from the final \u2018Tag enrichment\u2019 tap.<\/p>\n

Each event is registered in a platform\u2019s knowledge store, so that they are easily discoverable. To list all available events, simply use fsoc to query them, i.e., to get all triggers:<\/p>\n

fsoc knowledge get –type=contracts:cloudevent –filter=”data.category eq ‘data:trigger'” –layer-type=TENANT<\/p>\n

Note that all event types are versioned to allow for evolution and are qualified with platform solution identifier for isolation. For example, a fully qualified id of measurement.received<\/strong> event is platform:measurement.received.v1<\/strong><\/p>\n