Telemetry Data Collection
TIBCO BusinessEvents integration with OpenTelemetry allows you to monitor the health and performance of your application across all the services. OpenTelemetry provides support for tracking the progression of a request across multiple services in the application. This tracking is termed tracing. Tracing helps you to identify any bottlenecks in your applications and monitor each request across the services.
The telemetry data collected from your TIBCO BusinessEvents application can be displayed on data visualization software. Due to the vendor-agnostic design of the OpenTelemetry specification, you can use one or more open-source or commercial visualization software for the telemetry data.
For complete details about OpenTelemetry, see the OpenTelemetry documentation.
For more details about tracing in TIBCO BusinessEvents, see TIBCO BusinessEvents Application Tracing.
Key Terms
The following terms are the key terms of OpenTelemetry implementation. A brief introduction to these terms is given here. For complete details about OpenTelemetry terminology, see the OpenTelemetry documentation.
- Observability
- Ability to understand and measure the state of a system by collecting data such as traces, metrics, and logs.
- Telemetry
- Exporting monitoring data from an application to external analysis software.
- Trace
- Traces track the progression of a single request, as it is handled by services that make up an application.
- Span
- Span is a unit of work in a trace. A span has a start time, end time, attributes (key-value pairs), and events.
- Context
- A span has a span context, which is a set of globally unique identifiers that identifies a request. A context must be carried across threads and services to be able to trace a transaction or request uniquely across process boundaries.
- Propagator
- In order to extend trace beyond a single process, a context propagation mechanism is required and a propagator must be registered with the OpenTelemetry API. A context when shared with a remote application, it is serialized or deserialized to the vendor-specific protocol using propagators. An application should use one or more propagators that are used by other applications in the ecosystem to be able to parse context.