Discovering Kubernetes
Discovering Kyma
Working with Kubernetes Workloads
Using Services to Create Internal and External Communication with Kubernetes
Using Service Meshes with Istio
Using Kyma Eventing
Using Kubernetes Storage and StatefulSets
Using SAP BTP Service Management
Performing Observability and Monitoring
Using ConfigMaps and Secrets

Describing Observability in Kyma

Objectives

After completing this lesson, you will be able to:
  • Explain observability core concepts
  • Illustrate the basic concepts of telemetry in Kyma
  • Explain how to integrate Kyma with SAP Cloud Logging

Introduction to Observability

You are now operating some workloads using SAP BTP, Kyma runtime and want to gain more insights into your running applications. For this purpose, you want to start collecting and analyzing telemetry signals of your application, such as logs, traces, and metrics. In this lesson, you will learn about the telemetry features of Kyma for collecting the relevant data and analyzing this data with SAP Cloud Logging.

What is Observability?

Observability means the ability of a system to provide information about its internal state. This information can be used to monitor the system's behavior and diagnose problems. Observability is a key concept in microservice-based applications, where the number of components is large and the interactions between them are complex. Applications can expose insights about their internal state using logs, metrics, and traces. Collectively, these insights are called "telemetry".

The Kyma Telemetry Module

Overview

SAP BTP, Kyma runtime comes with the Telemetry module, which provides a Kubernetes API to collect and ship typical telemetry data of your instrumented workload to observability backends, like SAP Cloud Logging.

Application Log Collection

Application logs are essential for operating and troubleshooting applications. Ideally, logs are stored in an external system for several days and can be easily filtered.

The Telemetry module comes with a solution for collecting logs based on the OpenTelemetry Collector. Using an API called LogPipeline, you can collect application logs seamlessly. When you specify an SAP Cloud Logging endpoint as a destination, you get instant access to the log data over a configurable amount of time. Additionally, if the logs of the application are in JSON format, the log will be parsed and pushed to the target in a way that you can search and filter across all log attributes.

The Telemetry module uses Fluent Bit for the collection and processing of the logs. It supports a protocol based on HTTP that is specific to Fluent Bit, and thus enables integration to all backends that support this protocol.

Trace Collection

Distributed traces help you understand the application behavior and relations between the frontend actions and backend implementation. They can record the request chain across several workloads and execution chains inside an application. Traces consist of spans that are emitted by the individual components taking part in a trace. If you collect all the spans and send them to an observability backend, you can analyze the distributed traces going on in your SAP BTP, Kyma runtime.

The Telemetry module comes with a solution for collecting distributed traces based on the OpenTelemetry Collector. Using an API called TracePipeline, you can establish a cluster-central gateway, to which instrumented applications can push span data. Istio and many other Kyma modules are preconfigured to push spans to this gateway. If you specify an SAP Cloud Logging endpoint as a destination, you get instant access to the trace data with some visualizations. To see the correlation between logs and traces, enrich your application logs with a trace ID attribute.

To instrument the span data inside your application, use the available OpenTelemetry SDKs. Additionally, a lot of auto-instrumentations are available for most of the languages and tools. Ensure your application sends its span data using the OpenTelemetry protocol (OTLP), as this is the format the gateway uses.

Metric Collection

Metrics are aggregated statistics that reflect the internal state of a component over time, unlike logs and traces, which are request-oriented. They reflect the internal state of a component. Typical statistics like the number of processed requests or the number of registered users can be very useful to monitor the current state and the health of a component. Also, you can define proactive and reactive alerts if metrics are about to reach thresholds, or if they have already passed thresholds.

The Telemetry module provides an API MetricPipeline, which will establish a cluster-central gateway based on the OpenTelemetry Collector, to which instrumented workloads can send metric data. If you specify an SAP Cloud Logging endpoint as a destination, you get instant access to the metric data with a basic metric explorer.

Additionally, the MetricPipeline supports different kinds of input scenarios to easily collect metrics:

  • From the Kubernetes runtime about your application
  • From Istio sidecars
  • From any application exposing metrics in a Prometheus format

To instrument the metric data inside your application, use the available OpenTelemetry SDKs. Additionally, a lot of auto-instrumentations are available for most of the languages and tools. Ensure your application sends its span data using the OpenTelemetry protocol (OTLP), as this is the format the gateway uses.

Integration with SAP Cloud Logging

The integration of SAP Cloud Logging happens in the following steps:

  1. Create an instance of SAP Cloud Logging with an account and have a Kubernetes Secret available with the account credentials. SAP Cloud Logging is a SAP BTP service and the instance is created via the regular service management features.
    • With the SAP BTP Operator module, you can define a ServiceInstance resource, referencing the service plan to use and providing additional parameters for the service configuration.
    • You must also create a ServiceBinding resource, which requests an account in the service. Here, you can configure the regular rotation of the credentials.
    • The ServiceBinding triggers the generation of a Kubernetes Secret that holds the credentials.
  2. Define a LogPipeline with the Telemetry API referencing the Secret that holds the credentials.
    • With the Telemetry module, you can define a LogPipeline, which creates the relevant agent or gateways in the cluster for collecting the telemetry data.
    • The LogPipeline references the Secret with the service credentials, which is used by the log agent to ship the data.
    • When the automatic credential rotation of the ServiceBinding updates the Secret, the log agent is reconfigured with the new credentials.

The following diagram illustrates the integration with the LogPipeline as an example. The same is supported for the TracePipeline and MetricPipeline features.

Summary

In this lesson, you have learned about the different aspects of the Telemetry module in Kyma and how to integrate them with SAP Cloud Logging, in order to get instant access to the telemetry data for analysis and alerting.

In the next exercise, you will practice the integration with SAP Cloud Logging using the Kyma Telemetry API, and start discovering the available data.