Kyma

Appearance

Telemetry Module ​

Use the Telemetry module to collect telemetry signals (logs, traces, and metrics) from your applications and send them to your preferred observability backend.

What Is Telemetry? ​

With telemetry signals, you can understand the behavior and health of your applications and infrastructure. The Telemetry module provides a standardized way to collect these signals and send them to your observability backend, where you can analyze them and troubleshoot issues.

The Telemetry module processes three types of signals:

  • Logs: Time-stamped records of events that happen over time.
  • Traces: The path of a request as it travels through your application's components.
  • Metrics: Aggregated numerical data about the performance or state of a component over time.

Stages of Observability

Telemetry signals flow through the following stages:

  1. You instrument your application so that its components expose telemetry signals.
  2. The signals are collected and enriched with infrastructural metadata.
  3. You send the enriched signals to your preferred observability backend.
  4. The backend stores your data, where you can analyze and visualize it.

The Telemetry module focuses on the collection, processing, and shipment stages of the observability workflow. It offers a vendor-neutral approach based on OpenTelemetry and doesn't force you into a specific backend. This means you can integrate with your existing observability platforms or choose from a wide range of available backends that best suit your operational needs.

TIP

Build your first telemetry pipeline with the hands-on lesson Collecting Application Logs and Shipping them to SAP Cloud Logging.

Features ​

To support telemetry for your applications, the Telemetry module provides the following features:

  • Consistent Telemetry Pipeline API: Use a streamlined set of APIs based on the OTel Collector to collect, filter, and ship your logs, metrics, and traces (see Telemetry Pipeline API). You define a pipeline for each signal type to control how the data is processed and where it's sent. For details, see Collecting Logs, Collecting Traces, and Collecting Metrics.

  • Flexible Backend Integration: The Telemetry module is optimized for integration with SAP BTP observability services, such as SAP Cloud Logging. You can also send data to any backend that supports the OpenTelemetry protocol (OTLP), giving you the freedom to choose your preferred solution (see Integrate With Your OTLP Backend).

    TIP

    For production deployments, we recommend using a central telemetry solution located outside your cluster. For an example with SAP Cloud Logging, see Integrate With SAP Cloud Logging.

    For testing or development, in-cluster solutions may be suitable. For examples such as Dynatrace (or to learn how to collect data from applications based on the OpenTelemetry Demo App), see Integration Guides.

  • Seamless Istio Integration: The Telemetry module seamlessly integrates with the Istio module when both are present in your cluster. For details, see Istio Integration.

  • Automatic Data Enrichment: The Telemetry module adds resource attributes as metadata, following OTel semantic conventions. This makes your data more consistent, meaningful, and ready for analysis in your observability backend. For details, see Automatic Data Enrichment.

  • Instrumentation Guidance: To generate telemetry data, you must instrument your code. Based on Open Telemetry (OTel), you get community samples on how to instrument your code using the Open Telemetry SDKs in most programming languages.

  • Custom Tooling Support: For advanced scenarios, you can opt out of the module's default collection and shipment mechanisms for individual data types. This enables you to use custom tooling to collect and ship the telemetry data.

Scope ​

The Telemetry module focuses only on the signals of application logs, distributed traces, and metrics. Other kinds of signals are not considered. Also, audit logs are not in scope.

Supported integration scenarios are neutral to the vendor of the target system.

Architecture ​

The Telemetry module is built around a central controller, Telemetry Manager, which dynamically configures and deploys data collection components based on your pipeline resources.

To understand how the core components interact, see Architecture.

To learn how this model applies to each signal type, see:

API/Custom Resource Definitions ​

You configure the Telemetry module and its pipelines by creating and applying Kubernetes CustomResourceDefinitions (CRDs), which extend the Kubernetes API with custom additions.

To understand and configure the module's global settings, refer to the Telemetry CRD.

To define how to collect, process, and ship a specific signal, use the pipeline CRDs:

Resource Consumption ​

To learn more about the resources used by the Telemetry module, see Kyma Modules' Sizing.