orkungedik/SAP-basis-dataset huggingface dataset:
## 4.3.1.4.3 Redis
Use the Cloud Manager module to provision Redis instances.
The Cloud Manager module allows you to provision a cloud provider-managed Redis instance within your cluster network.
##  Remember
Using the Cloud Manager module and enabling Redis, introduces additional costs. For more information, see Calculation with the Cloud Manager Module [page 96].
## Cloud Providers
When you create a Redis instance in SAP BTP, Kyma runtime, you depend on the cloud provider of your Kyma cluster. The cloud provider in use determines the exact implementation.
The Cloud Manager module supports the Redis feature of the following cloud providers:
- Amazon Web Services Amazon ElastiCashe for Redis OSS
- Google Cloud Memorystore
- Microsoft Azure Azure Cache for Redis
You can configure Cloud Manager's Redis instances using a dedicated Redis instance custom resource (CR) corresponding with the cloud provider for your Kyma cluster, namely AwsRedisInstance CR, GcpRedisInstance CR, or AzureRedisInstance CR. For more information, see Redis Resources [page 1926].
## Tiers
When you provision a Redis instance, you can choose between Standard and Premium Tier.
- Standard Tier offers one instance.
- Premium Tier offers high availability with automatic failover by provisioning an additional read replica of your instance.
## Prerequisites
To instantiate Redis, an IpRange CR must exist in the Kyma cluster. IpRange defines network address space reserved for your cloud provider's Redis resources. If you don't create the IpRange CR manually, Cloud Manager creates a default IpRange CR with the default address space and Classless Inter-Domain Routing (CIDR) selected. For more information, see IP Range [page 1925].
## Lifecycle
AwsRedisInstance, GcpRedisInstance, and AzureRedisInstance are namespace-level CRs. Once you create any of the Redis resources, the following resources are also created automatically:
- IpRange CR
- IpRange is a cluster-level CR.
- Only one IpRange CR can exist per cluster.
- If you don't want the default IpRange to be used, create one manually.
- Secret CR
- The Secret is a namespace-level CR.
- The Secret's name is the same as the name of the respective Redis instance CR.
- The Secret holds values and information used to access the Redis instance.
## Related Information
kyma-project.io: Using AwsRedisInstance Custom Resources kyma-project.io: Using GcpRedisInstance Custom Resources
Redis Resources [page 1926]
Calculation with the Cloud Manager Module [page 96]
## 4.3.1.4.4 Cloud Manager Resources
Learn about Cloud Manager's custom resources.
The API of the Cloud Manager module is based on Kubernetes Custom Resource Definitions (CRDs), which extend the Kubernetes API with custom additions. To inspect the specification of the Cloud Manager module API, see the following custom resources (CRs):
## IP Range
## IpRange CR
The iprange.cloud-resources.kyma-project.io CRD describes the Virtual Private Cloud (VPC) network IP range used for IP address allocation for cloud resources that require an IP address. For more information, see IpRange Custom Resource .
## NFS Resources
## AwsNfsVolume CR
The awsnfsvolume.cloud-resources.kyma-project.io CRD describes the Amazon Web Services Elastic File System (Amazon EFS) instance that can be used as a ReadWriteMany (RWX) volume in the cluster.
For more information, see AwsNfsVolume Custom Resource .
## GcpNfsVolume CR
The gcpnfsvolume.cloud-resources.kyma-project.io CRD describes the Google Cloud Filestore instance that can be used as an RWX volume in the cluster. For more information, see GcpNfsVolume Custom Resource .
## VPC Peering Resources
## AwsVpcPeering CR
The awsvpcpeering.cloud-resources.kyma-project.io CRD describes the AWS peering connection between Kyma and the remote AWS Virtual Network. For more information, see AwsVpcPeering Custom Resource .
## GcpVpcPeering CR
The gcpvpcpeering.cloud-resources.kyma-project.io CRD describes the VPC peering that you can use to peer your Kyma cluster with your Google Cloud project VPC. For more information, see GcpVpcPeering Custom Resource .
## Redis Resources
## AwsRedisInstance CR
The awsredisinstance.cloud-resources.kyma-project.io CRD describes the Amazon ElastiCache Redis instance. For more information, see AwsRedisInstance Custom Resource .
## GcpRedisInstance CR
The gcpredisinstance.cloud-resources.kyma-project.io CRD describes the Google Cloud Memorystore for Redis instance. For more information, see GcpRedisInstance Custom Resource .
## AzureRedisInstance CR
The azureredisinstance.cloud-resources.kyma-project.io CRD describes the Microsoft Azure Cache for Redis instance. For more information, see AzureRedisInstance Custom Resource .
## 4.3.1.6 Keda Module
Learn more about the Keda module. Use it to install and manage the KEDA autoscaler in your Kubernetes cluster.
## What Is KEDA?
Kubernetes-based Event Driven Autoscaler (KEDA) is an autoscaler that allows you to easily scale your Kubernetes-based resources. You can scale your applications based on the data of your choice.
KEDA supports a great number of scalers that help you manage your deployments. For the complete list, see the KEDA Scalers documentation .
For more information about KEDA features, see the KEDA documentation .
## Features
With the Keda module, you can have a custom event-driven autoscaling for Kubernetes workloads.
## Architecture
<!-- image -->
1. User configures the Keda custom resource (CR). With the CR you can determine the way the Keda module runs.
2. Keda Manager watches the Keda CR.
3. Keda Manager manages the KEDA workloads.
To learn more about the KEDA architecture, see the KEDA architecture diagram .
## Keda Manager
Keda Manager helps you to install and manage KEDA in your cluster. It manages the lifecycle of KEDA based on the dedicated Keda CR.
## API/Custom Resource Definitions
For the Keda CR conditions, check Keda Custom Resource Conditions [page 1932].
To learn more about the KEDA CR, see KEDA Custom Resources .
## Resource Consumption
To learn more about the resources used by the Keda module, see Keda Module's Sizing [page 3165].
## Keda Module Demo Applications
To learn how to scale the Kubernetes workloads using the KEDA API based on a simple CPU consumption case, and how the Keda module can complement other Kyma components, see Demo Applications .
## 4.3.1.6.1 Configuring Keda Module
By default, the Keda module comes with the default configuration. You can change the configuration using the Keda CustomResourceDefinition (CRD). See how to configure the logging.level attribute, enable the Istio sidecar injection, change resource consumption, define custom annotations, or override the minimum TLS version.
## Prerequisites
- You have added the Keda module. To learn how to do it, see Adding and Deleting a Kyma Module [page 3157].
## Procedure
1. Go to Kyma dashboard. The URL is in the Overview section of your subaccount.
2. Choose Modify Modules , and in the View tab, choose keda .
3. Go to Edit , and provide your configuration changes. You can use the Form or YAML tab.
- To define the level of detail of your logs, set the logging.level attribute to one of the following values:
- debug - is the most detailed option. Useful for a developer during debugging.
- info - provides standard log level indicating operations within the Keda module. For example, it can show whether the workload scaling operation was successful or not.
- error - shows error logs only. This means only log messages corresponding to errors and misconfigurations are visible in logs.
- To enable the Istio sidecar injection [page 1780] for operator and metricServer , set the value of enabledSidecarInjection to true . For example:
- To change the resource consumption, enter your preferred values for operator , metricServer , and admissionWebhook . For example:
- To define custom annotations for KEDA workloads, enter your preferred values for operator , metricServer and admissionWebhook . For example:
```
spec: logging: operator: level: "debug"
```
```
spec: istio: metricServer: enabledSidecarInjection: true operator: enabledSidecarInjection: true
```
```
spec: resources: operator: limits: cpu: "1" memory: "200Mi" requests: cpu: "150m" memory: "150Mi" metricServer: limits: cpu: "1" memory: "1000Mi" requests: cpu: "150m" memory: "500Mi" admissionWebhook: limits: cpu: "1" memory: "1000Mi" requests: cpu: "50m" memory: "800Mi"
```
```
spec:
```
```
podAnnotations: operator: metrics.dynatrace.com/scrape: 'true' metrics.dynatrace.com/path: '/metrics' metricServer: metrics.dynatrace.com/scrape: 'true' metrics.dynatrace.com/path: '/metrics' admissionWebhook: metrics.dynatrace.com/scrape: 'true' metrics.dynatrace.com/path: '/metrics'
```
- To override the minimum TLS version used by KEDA (default is TLS12 ), set the KEDA\_HTTP\_MIN\_TLS\_VERSION environment variable. For example:
```
spec: env: - name: KEDA_HTTP_MIN_TLS_VERSION value: TLS13
```
## Next Steps
For more information about the KEDA resources, see KEDA concepts .
## 4.3.1.6.2 Keda Custom Resource Conditions
This document describes the possible conditions of the Keda CR. The conditions make it easier to observe the current state of the Keda module.
The following condition types are used:
- Installed
- Deleted
|   No | CR State   | Condition Type   | Condition Status   | Condition Reason      | Remarks                         |
|------|------------|------------------|--------------------|-----------------------|---------------------------------|
|    1 | Ready      | Installed        | true               | Verified              | Server ready                    |
|    2 | Processing | Installed        | unknown            | Initialized           | Initialized                     |
|    3 | Processing | Installed        | unknown            | Verification          | Verification in progress        |
|    4 | Error      | Installed        | false              | ApplyObjError         | Apply object error              |
|    5 | Error      | Installed        | false              | DeploymentUpda- teErr | Deployment update error         |
|    6 | Error      | Installed        | false              | VerificationErr       | Verification error              |
|    7 | Error      | Installed        | false              | KedaDuplicated        | One instance of Keda is allowed |
|    8 | Deleting   | Deleted          | unknown            | Deletion              | Deletion in progress            |
|    9 | Deleting   | Deleted          | true               | Deleted               | Keda module deleted             |
|   10 | Error      | Deleted          | false              | DeletionErr           | Deletion failed                 |
## 4.3.1.7 Serverless Module
Learn more about the Serverless module. Use it to run lightweight Functions in a cost-efficient and scalable way using JavaScript and Node.js.
## What Is Serverless?
The Kyma Serverless module is a "code-as-a-service" tool designed to accelerate the process of prototyping applications by removing the technical overhead necessary to obtain the first testable versions. It allows developers to focus on the coding and easily run it in the context of the SAP BTP without dealing with Kubernetes orchestration or containerization complexities. The fact that no Kubernetes knowledge is required to use it makes Serverless a useful tool for beginners who want to experiment with loosely coupled microservice architecture on Kubernetes or for business consultants who need to provide extension logic for an existing Kubernetes-based system with minimal overhead.
With the Serverless module, you can build, run, and manage serverless applications in Kubernetes. These applications are called Functions, and they are based on the Function custom resource (CR) objects. They contain simple code snippets that implement a specific business logic. For example, you can define that you want to use a Function as a proxy that saves all incoming event details to an external database.
A Function can be triggered by other workloads in the cluster (in-cluster events) or business events coming from external sources. You can subscribe to them using a Subscription CR . Y ou can expose your Function to an external endpoint (HTTPS). With an APIRule CR , you can define who can reach the endpoint and what operations they can perform on it.
## Features
The Serverless module provides the following features:
- Quick deployments following a Function approach
- Loosely coupled microservice approach
- Event-driven programming model
- Reduced implementation and operation effort
- Function management with Kubernetes resources like Deployments , Services , and HorizontalPodAutoscalers
- Docker image creation with Kubernetes Jobs
## Architecture
<!-- image -->
1. User applies the Serverless CR.
2. Serverless Operator watches the Serverless CR.
3. Serverless Operator reconciles the Serverless workloads.
## Serverless Operator
When you add the Serverless module, Serverless Operator takes care of installation and configuration of Serverless in your cluster. It manages the Serverless lifecycle based on the dedicated Serverless CR.
## API/Custom Resource Definitions
The API of the Serverless module is based on Kubernetes CustomResourceDefinitions (CRDs), which extend the Kubernetes API with custom additions. To inspect the specification of the Serverless module API, see:
- Function CRD
- Serverless CRD
## Security Considerations
To learn how to avoid any potential threats while using Functions, see Function Security [page 3295].
## Resource Consumption
To learn more about the resources used by the Serverless module, see Serverless [page 3165].
## Related Information
Function Security [page 3295]
kyma-project.io: Serverless module tutorials kyma-project.io: Serverless module technical reference
kyma-project.io: Serverless module troubleshooting guides
## 4.3.1.7.1 From Code to Function
Pick the programming language for your Function and decide where you want to keep the source code. The Serverless module uses it to create the workload.
## Serverless Runtimes
Functions support programming languages by using the underlying execution environments known as runtimes. You can create both Node.js and Python Functions in Kyma.
 Tip
See sample Functions for each available runtime.
## Source Code
You can also choose where you want to keep your Function's source code and dependencies. You can either place them directly in the Function CR under the spec.source and spec.deps fields as an inline Function, or store the code and dependencies in a public or private Git repository (Git Functions). Choosing the second option ensures your Function is versioned and gives you more development freedom in the choice of a project structure or an IDE.
 Tip
Read more about Git Functions .
## 4.3.1.7.3 Configuring Serverless
By default, the Serverless module comes with the default configuration. You can change the configuration using the Serverless CustomResourceDefinition (CRD), which manages Serverless custom resource (CR).
## Prerequisites
- You have the Serverless module added. See Adding and Deleting a Kyma Module [page 3157].
- You have access to Kyma dashboard. Alternatively, to use CLI instructions, you must install kubectl .
## Context
The Serverless CR is an API to configure the Serverless module. You can use it to perform the following actions:
- Enable or disable the internal Docker registry.
- Configure the external Docker registry.
- Override endpoint for traces collected by the Serverless Functions.
- Override endpoint for Eventing.
- Override the target CPU utilization percentage.
- Override the Function requeue duration.
- Override the Function build executor arguments.
- Override the Function build max simultaneous jobs.
- Override the healthz liveness timeout.
- Override the Function request body limit.
- Override the Function timeout.
- Override the default build Job preset.
- Override the default runtime Pod preset.
- Override the default log level.
- Override the default log format.
- Enable network policies.
- Enable buildless mode of Serverless.
The default configuration of the Serverless module is the following:
```
apiVersion: operator.kyma-project.io/v1alpha1 kind: Serverless metadata: name: serverless-sample spec: dockerRegistry: enableInternal: true
```
##  Caution
The spec.dockerRegistry field is deprecated and will be removed in a future version of Serverless where Functions won't require building images.
## Procedure
1. Go to Kyma dashboard. The URL is in the Overview section of your subaccount.
2. Choose Modify Modules , and in the View tab, choose serverless .
3. Go to Edit , and provide your configuration changes. You can use the Form or YAML tab.
## Configuring Docker Registry
By default, Serverless uses PersistentVolume (PV) as the internal registry to store Docker images for Functions. The default storage size of a single volume is 20 GB. This internal registry is suitable for local development. Follow these steps to use the external Docker registry in Serverless:
## Procedure
## 4.3.1.8.1 Telemetry Manager
As the core element of the Telemetry module, Telemetry Manager manages the lifecycle of other Telemetry module components by watching user-created resources.
## Module Lifecycle
The Telemetry module includes Telemetry Manager, a Kubernetes operator that's described by a custom resource of type Telemetry . T elemetry Manager has the following tasks:
1. Watch the module configuration for changes and sync the module status to it.
2. Watch for the user-created Kubernetes resources LogPipeline , TracePipeline , and MetricPipeline . In these resources, you specify what data of a signal type to collect and where to ship it.
3. Manage the lifecycle of the self monitor and the user-configured agents and gateways. For example, only if you defined a LogPipeline resource, the Fluent Bit DaemonSet is deployed as log agent.
<!-- image -->
## Self Monitor
The Telemetry module contains a self monitor, based on Prometheus , to collect and evaluate metrics from the managed gateways and agents. Telemetry Manager retrieves the current pipeline health from the self monitor and adjusts the status of the pipeline resources and the module status.
Additionally, you can monitor the health of your pipelines in an integrated backend like SAP Cloud Logging: To set up alerts and reports in the backend, use the pipeline health metrics emitted by your MetricPipeline . For details, see Setting up a MetricPipeline [page 1996], step Monitor Pipeline Health , as well as Integrate with SAP Cloud Logging [page 2011].
<!-- image -->
## Module Configuration and Status
For configuration options and the overall status of the module, see the specification of the related Telemetry resource .
## 1. Create a LogPipeline
To ship logs to a new OTLP output, create a resource of the kind Logipeline and save the file (named, for example, logpipeline.yaml ).
This configures the underlying OTel Collector with a pipeline for logs and opens a push endpoint that is accessible with the telemetry-otlp-logs service. For details, see Push Endpoints [page 1953]. The following push URLs are set up:
- GRPC: http://telemetry-otlp-logs.kyma-system:4317
- HTTP: http://telemetry-otlp-logs.kyma-system:4318
The default protocol for shipping the data to a backend is GRPC, but you can choose HTTP instead. Depending on the configured protocol, an otlp or an otlphttp exporter is used. Ensure that the correct port is configured as part of the endpoint.
- For GRPC, use:
- For HTTP, use the protocol attribute:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com:4317
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: output: otlp: protocol: http endpoint: value: https://backend.example.com:4318
```
## 2a. Add Authentication Details From Plain Text
To integrate with external systems, you must configure authentication details. You can use mutual TLS (mTLS), Basic Authentication, or custom headers:
- mTLS:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: output: otlp: endpoint:
```
```
value: https://backend.example.com/otlp:4317 tls: cert: value: | -----BEGIN CERTIFICATE-----... key: value: | -----BEGIN RSA PRIVATE KEY-----...
```
- Basic Authentication:
- Token-based authentication with custom headers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 authentication: basic: user: value: myUser password: value: myPwd
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 headers: - name: Authorization prefix: Bearer value: "myToken"
```
## 2b. Add Authentication Details From Secrets
Integrations into external systems usually need authentication details dealing with sensitive data. To handle that data properly in Secrets, LogPipeline supports the reference of Secrets.
Using the valueFrom attribute, you can map Secret keys for mutual TLS (mTLS), Basic Authentication, or with custom headers.
You can store the value of the token in the referenced Secret without any prefix or scheme, and you can configure it in the headers section of the LogPipeline . In the following example, the token has the prefix 'Bearer'.
- mTLS:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: output:
```
```
otlp: endpoint: value: https://backend.example.com/otlp:4317 tls: cert: valueFrom: secretKeyRef: name: backend namespace: default key: cert key: valueFrom: secretKeyRef: name: backend namespace: default key: key
```
- Basic Authentication:
- Token-based authentication with custom headers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1
```
```
kind: LogPipeline metadata: name: backend spec: output: otlp: endpoint: valueFrom: secretKeyRef: name: backend namespace: default key: endpoint authentication: basic: user: valueFrom: secretKeyRef: name: backend namespace: default key: user password: valueFrom: secretKeyRef: name: backend namespace: default key: password
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 value: https://backend.example.com:4317
```
```
kind: LogPipeline metadata: name: backend spec: output: otlp: endpoint: headers: - name: Authorization prefix: Bearer valueFrom: secretKeyRef: name: backend namespace: default key: token
```
The related Secret must have the referenced name, be located in the referenced namespace, and contain the mapped key. See the following example:
```
kind: Secret apiVersion: v1 metadata: name: backend namespace: default stringData: endpoint: https://backend.example.com:4317 user: myUser password: XXX token: YYY
```
## 3. Rotate the Secret
Telemetry Manager continuously watches the Secret referenced with the secretKeyRef construct. You can update the Secret's values, and Telemetry Manager detects the changes and applies the new Secret to the setup.
##  Tip
If you use a Secret owned by the SAP BTP Service Operator , you can configure an automated rotation using a credentialsRotationPolicy with a specific rotationFrequency and don't have to intervene manually.
## 4. Activate Application Input
To enable collection of logs printed by containers to the stdout/stderr channel, define a LogPipeline that has the application section enabled as input:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: input: application: enabled: true output: otlp: ...
```
By default, input is collected from all namespaces, except the system namespaces kube-system , istiosystem , kyma-system , which are excluded by default.
To filter your application logs by namespace or container, use an input spec to restrict or specify which resources you want to include. For example, you can define the namespaces to include in the input collection, exclude namespaces from the input collection, or choose that only system namespaces are included. Learn more about the available parameters and attributes .
The following pipeline collects input from all namespaces excluding kyma-system and only from the istioproxy containers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: input: application:
```
```
enabled: true namespaces: exclude: - myNamespace containers: exclude: - myContainer otlp: ...
```
After tailing the log files from the container runtime, the payload of the log lines is transformed into an OTLP entry.
The following example of the log flow assumes that there's a container myContainer of Pod myPod , running in namespace myNamespace , logging to stdout with the following log message in the JSON format:
```
 Output Code { "level": "warn", "message": "This is the actual message", "tenant": "myTenant", "traceID": "123" }
```
The log entry goes through the following stages:
## 1. Log Tailing
The agent reads the log message from a log file managed by the container runtime. The file name contains namespace, Pod and Container information that will be available later as log attributes. The raw log record looks similar to the following example:
```
{ "time": "2022-05-23T15:04:52.193317532Z", "stream": "stdout", "_p": "F", "log": "{\"level\": \"warn\",\"message\": \"This is the actual message\",\"tenant\": \"myTenant\",\"trace_id\": \"123\"}" }
```
After the tailing, the created OTLP record looks like the following example:
```
{ "time": "2022-05-23T15:04:52.100000000Z", "observedTime": "2022-05-23T15:04:52.200000000", "attributes": { "log.file.path": "/var/log/pods/myNamespace_myPod-<containerID>/ myContainer/<containerRestarts>.log", "log.iostream": "stdout" }, "resourceAttributes": { "k8s.container.name": "myContainer", "k8s.container.restart_count": "<containerRestarts>", "k8s.pod.name": "myPod", "k8s.namespace.name": "myNamespace" }, "body": "{\"level\": \"warn\",\"message\": \"This is the actual message\",\"tenant\": \"myTenant\",\"trace_id\": \"123\"}" }
```
All information identifying the source of the log (like the Container, Pod and namespace name) are enriched as resource attributes following the Kubernetes conventions . Further metadata - like the
original file name and channel - are enriched as log attributes following the log attribute conventions . The time value provided in the container runtime log entry is used as time attribute in the new OTel record, as it is very close to the actual time when the log happened. Additionally, the observedTime is set with the time when the agent actual read the log record as recommended by the OTel log specification. The log payload is moved to the OTLP body field.
## 2. JSON Parsing
If the value of the body is a JSON document, the value is parsed and all JSON root attributes are enriched as additional log attributes. The original body is moved into the log.original attribute (managed with the LogPipeline attribute input.application.keepOriginalBody: true ).
The resulting OTLP record looks like the following example:
```
{ "time": "2022-05-23T15:04:52.100000000Z", "observedTime": "2022-05-23T15:04:52.200000000", "attributes": { "log.file.path": "/var/log/pods/myNamespace_myPod-<containerID>/ myContainer/<containerRestarts>.log", "log.iostream": "stdout", "log.original": "{\"level\": \"warn\",\"message\": \"This is the actual message\",\"tenant\": \"myTenant\",\"trace_id\": \"123\"}", "level": "warn", "tenant": "myTenant", "trace_id": "123", "message": "This is the actual message" }, "resourceAttributes": { "k8s.container.name": "myContainer", "k8s.container.restart_count": "<containerRestarts>", "k8s.pod.name": "myPod", "k8s.namespace.name": "myNamespace" }, "body": "" }
```
## 3. Severity Parsing
Typically, a log message has a log level written to a field level . Based on that, the agent tries to parse the log attribute level with a severity parser. If that is successful, the log attribute is transformed into the OTel attributes severityText and severityNumber .
## 4. Trace Parsing
OTLP natively supports attaching trace context to log records. If possible, the log agent parses the following log attributes according to the W3C-Tracecontext specification :
- trace\_id
- span\_id
- trace\_flags
- traceparent
## 5. Log Body Determination
Because the actual log message is typically located in the body attribute, the agent moves a log attribute called message (or msg ) into the body.
At this point, before further enrichment, the resulting overall log record looks like the following example:
```
{ "time": "2022-05-23T15:04:52.100000000Z", "observedTime": "2022-05-23T15:04:52.200000000", "attributes": { "log.file.path": "/var/log/pods/myNamespace_myPod-<containerID>/ myContainer/<containerRestarts>.log", "log.iostream": "stdout",
```
```
"log.original": "{\"level\": \"warn\",\"message\": \"This is the actual message\",\"tenant\": \"myTenant\",\"trace_id\": \"123\"}", "tenant": "myTenant", }, "resourceAttributes": { "k8s.container.name": "myContainer", "k8s.container.restart_count": "<containerRestarts>", "k8s.pod.name": "myPod", "k8s.namespace.name": "myNamespace" }, "body": "This is the actual message", "severityNumber": 13, "severityTex": "warn", "trace_id": 123 }
```
## 5. Deactivate OTLP Logs
If you have more than one backend, you can specify from which input logs are pushed to each backend. For example, if OTLP logs should go to one backend and only logs from the tail input to the other backend, then disable the OTLP input for the second backend.
By default, otlp input is enabled.
To drop the push-based OTLP logs that are received by the log gateway, define a LogPipeline that has the otlp section disabled as an input:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: backend spec: input: application: enabled: true otlp: disabled: true output: otlp: endpoint: value: https://backend.example.com:4317
```
With this, the agent starts collecting all container logs, while the push-based OTLP logs are dropped by the gateway.
## 1. Create a LogPipeline and Output
To ship application logs to a new output, create a resource of the kind LogPipeline and save the file (named, for example, logpipeline.yaml ).
kind: LogPipeline
```
apiVersion: telemetry.kyma-project.io/v1alpha1 metadata: name: http-backend spec: output: http: dedot: false port: "80" uri: "/" host: value: https://myhost/logs user: value: "user" password: value: "not-required"
```
An output is a data destination configured by a Fluent Bit output of the relevant type. The LogPipeline supports the http output type: It sends the data to the specified HTTP destination. The output is designed to integrate with a Fluentd HTTP Input , which opens up a huge ecosystem of integration possibilities.
## 2. Filter Your Input
By default, input is collected from all namespaces, except the system namespaces ( kube-system , istiosystem , kyma-system ), which are excluded by default.
To filter your application logs by namespace or container, use an input spec to restrict or specify which resources you want to include. For example, you can define the namespaces to include in the input collection, exclude namespaces from the input collection, or choose that only system namespaces are included. Learn more about the availableparameters and attributes .
The following example collects input from all namespaces excluding kyma-system and only from the istioproxy containers:
```
kind: LogPipeline apiVersion: telemetry.kyma-project.io/v1alpha1 metadata: name: http-backend spec: input: application: namespaces: exclude: - kyma-system containers: include: - istio-proxy output: ...
```
It might happen that Fluent Bit prints an error per processed log line, which is then collected and re-processed. To avoid problems with such recursive logs, it is recommended that you exclude the logs of the Fluent Bit container. The following example collects input from all namespaces including system namespaces, but excludes the Fluent Bit container:
```
spec: input: application: namespaces: system: true containers: exclude: - fluent-bit
```
## 3. Add Authentication Details From Secrets
Integrations into external systems usually need authentication details dealing with sensitive data. To handle that data properly in Secrets, LogPipeline supports the reference of Secrets.
Using the http output definition and the valueFrom attribute, you can map Secret keys for mutual TLS (mTLS) or Basic Authentication:
- mTLS:
```
apiVersion: telemetry.kyma-project.io/v1alpha1
```
```
kind: LogPipeline metadata: name: http-backend spec: output: http: dedot: false port: "80" uri: "/" host: valueFrom: secretKeyRef: name: http-backend-credentials namespace: default key: HTTP_ENDPOINT tls: cert: valueFrom: secretKeyRef: name: http-backend-credentials namespace: default key: TLS_CERT key: valueFrom: secretKeyRef: name: http-backend-credentials namespace: default key: TLS_KEY input: ... filters: ...
```
## · Basic Authentication:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: LogPipeline metadata: name: http-backend spec: output: http: dedot: false port: "80" uri: "/" host: valueFrom: secretKeyRef: name: http-backend-credentials namespace: default key: HTTP_ENDPOINT user: valueFrom: secretKeyRef: name: http-backend-credentials namespace: default
```
```
key: HTTP_USER password: valueFrom: secretKeyRef: name: http-backend-credentials namespace: default key: HTTP_PASSWORD input: ... filters: ...
```
The related Secret must have the referenced name, be located in the referenced namespace, and contain the mapped key. See the following example:
```
kind: Secret apiVersion: v1 metadata: name: http-backend-credentials stringData: HTTP_ENDPOINT: https://myhost/logs HTTP_USER: myUser HTTP_PASSWORD: XXX TLS_CERT: ... TLS_KEY: ...
```
## 4. Rotate the Secret
Telemetry Manager continuously watches the Secret referenced with the secretKeyRef construct. You can update the Secret's values, and Telemetry Manager detects the changes and applies the new Secret to the setup.
##  Tip
If you use a Secret owned by the SAP BTP Service Operator , you can configure an automated rotation using a credentialsRotationPolicy with a specific rotationFrequency and don't have to intervene manually.
## 1. Create a TracePipeline
To ship traces to a new OTLP output, create a resource of the kind TracePipeline and save the file (named, for example, tracepipeline.yaml ).
This configures the underlying OTel Collector with a pipeline for traces and opens a push endpoint that is accessible with the telemetry-otlp-traces service. For details, see Push Endpoints [page 1953].
The following push URLs are set up:
- GRPC: http://telemetry-otlp-traces.kyma-system:4317
- HTTP: http://telemetry-otlp-traces.kyma-system:4318
The default protocol for shipping the data to a backend is GRPC, but you can choose HTTP instead. Depending on the configured protocol, an otlp or an otlphttp exporter is used. Ensure that the correct port is configured as part of the endpoint.
- For GRPC, use:
- For HTTP, use the protocol attribute:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com:4317
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline metadata: name: backend spec: output: otlp: protocol: http endpoint: value: https://backend.example.com:4318
```
## 2. Enable Istio Tracing
By default, the tracing feature of the Istio module is disabled to avoid increased network utilization if there is no TracePipeline .
To activate the Istio tracing feature with a sampling rate of 5% (for recommendations, see Istio), use a resource similar to the following example:
```
apiVersion: telemetry.istio.io/v1 kind: Telemetry metadata: name: tracing-default namespace: istio-system spec: tracing: - providers: - name: "kyma-traces" randomSamplingPercentage: 5.00
```
## 3a. Add Authentication Details From Plain Text
To integrate with external systems, you must configure authentication details. You can use mutual TLS (mTLS), Basic Authentication, or custom headers:
- mTLS:
- Basic Authentication:
- Token-based authentication with custom headers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 tls: cert: value: | -----BEGIN CERTIFICATE-----... key: value: | -----BEGIN RSA PRIVATE KEY-----...
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 authentication: basic: user: value: myUser password: value: myPwd
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 headers: - name: Authorization prefix: Bearer value: "myToken"
```
## 3b. Add Authentication Details From Secrets
Integrations into external systems usually need authentication details dealing with sensitive data. To handle that data properly in Secrets, TracePipeline supports the reference of Secrets.
Using the valueFrom attribute, you can map Secret keys for mutual TLS (mTLS), Basic Authentication, or with custom headers.
You can store the value of the token in the referenced Secret without any prefix or scheme, and you can configure it in the headers section of the TracePipeline . In the following example, the token has the prefix 'Bearer'.
## · mTLS:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 tls: cert: valueFrom: secretKeyRef: name: backend namespace: default key: cert key: valueFrom: secretKeyRef: name: backend namespace: default key: key
```
## · Basic Authentication:
```
apiVersion: telemetry.kyma-project.io/v1alpha1
```
```
kind: TracePipeline metadata: name: backend spec: output: otlp: endpoint: valueFrom: secretKeyRef: name: backend namespace: default key: endpoint authentication: basic: user: valueFrom: secretKeyRef: name: backend namespace: default key: user password: valueFrom: secretKeyRef: name: backend namespace: default key: password
```
- Token-based authentication with custom headers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: TracePipeline
```
```
metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com:4317 headers: - name: Authorization prefix: Bearer valueFrom: secretKeyRef: name: backend namespace: default key: token
```
The related Secret must have the referenced name, be located in the referenced namespace, and contain the mapped key. See the following example:
```
kind: Secret apiVersion: v1 metadata: name: backend namespace: default stringData: endpoint: https://backend.example.com:4317 user: myUser password: XXX token: YYY
```
## 1. Create a MetricPipeline
To ship metrics to a new OTLP output, create a resource of the kind MetricPipeline and save the file (named, for example, metricpipeline.yaml ).
This configures the underlying OTel Collector with a pipeline for metrics and opens a push endpoint that is accessible with the telemetry-otlp-metrics service. For details, see Push Endpoints [page 1953].
The following push URLs are set up:
- gRPC: http://telemetry-otlp-metrics.kyma-system:4317
- HTTP: http://telemetry-otlp-metrics.kyma-system:4318
The default protocol for shipping the data to a backend is gRPC, but you can choose HTTP instead. Depending on the configured protocol, an otlp or an otlphttp exporter is used. Ensure that the correct port is configured as part of the endpoint.
- For gRPC, use:
- For HTTP, use the protocol attribute:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com:4317
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: output: otlp: protocol: http endpoint: value: https://backend.example.com:4318
```
## 2a. Add Authentication Details From Plain Text
To integrate with external systems, you must configure authentication details. You can use mutual TLS (mTLS), Basic Authentication, or custom headers:
- mTLS:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: output: otlp:
```
```
endpoint: value: https://backend.example.com/otlp:4317 tls: cert: value: | -----BEGIN CERTIFICATE-----... key: value: | -----BEGIN RSA PRIVATE KEY-----...
```
- Basic Authentication:
- Token-based authentication with custom headers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 authentication: basic: user: value: myUser password: value: myPwd
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: output: otlp: endpoint: value: https://backend.example.com/otlp:4317 headers: - name: Authorization prefix: Bearer value: "myToken"
```
## 2b. Add Authentication Details From Secrets
Integrations into external systems usually need authentication details dealing with sensitive data. To handle that data properly in Secrets, MetricsPipeline supports the reference of Secrets.
Using the valueFrom attribute, you can map Secret keys for mutual TLS (mTLS), Basic Authentication, or with custom headers.
You can store the value of the token in the referenced Secret without any prefix or scheme, and you can configure it in the headers section of the MetricPipeline . In this example, the token has the prefix 'Bearer'.
- mTLS:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: output:
```
```
otlp: endpoint: value: https://backend.example.com/otlp:4317 tls: cert: valueFrom: secretKeyRef: name: backend namespace: default key: cert key: valueFrom: secretKeyRef: name: backend namespace: default key: key
```
- Basic Authentication:
- Token-based authentication with custom headers:
```
apiVersion: telemetry.kyma-project.io/v1alpha1
```
```
kind: MetricPipeline metadata: name: backend spec: output: otlp: endpoint: valueFrom: secretKeyRef: name: backend namespace: default key: endpoint authentication: basic: user: valueFrom: secretKeyRef: name: backend namespace: default key: user password: valueFrom: secretKeyRef: name: backend namespace: default key: password
```
```
apiVersion: telemetry.kyma-project.io/v1alpha1 value: https://backend.example.com:4317
```
```
kind: MetricPipeline metadata: name: backend spec: output: otlp: endpoint: headers: - name: Authorization prefix: Bearer valueFrom: secretKeyRef: name: backend namespace: default key: token
```
The related Secret must have the referenced name, be located in the referenced namespace, and contain the mapped key. See the following example:
```
kind: Secret apiVersion: v1 metadata: name: backend namespace: default stringData: endpoint: https://backend.example.com:4317 user: myUser password: XXX token: YYY
```
## 5. Monitor Pipeline Health
By default, a MetricPipeline emits metrics about the health of all pipelines managed by the Telemetry module. Based on these metrics, you can track the status of every individual pipeline and set up alerting for it.
Metrics for Pipelines and the Telemetry Module
| Metric                           | Description                                                                                                                                         | Availability                                                 |
|----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------|
| kyma.resource.status.condi tions | Value represents status of different conditions reported by the resource. Possible values are 1 ('True'), 0 ('False'), and -1 (other status values) | Available for both, the pipelines and the Telemetry resource |
| kyma.resource.status.state       | Value represents the state of the re- source (if present)                                                                                           | Available for the Telemetry resource                         |
Metric Attributes for Monitoring
## Name
| metric.attributes.Type   | Type of the condition                                                                        |
|--------------------------|----------------------------------------------------------------------------------------------|
| metric.attributes.status | Status of the condition                                                                      |
| metric.attributes.reason | Contains a programmatic identifier indicating the reason for the condition's last transition |
To set up alerting, use an alert rule.
In the following example, the alert is triggered if metrics are not delivered to the backend:
```
min by (k8s_resource_name) ((kyma_resource_status_conditions{type="TelemetryFlowHealthy",k8s_resource_kind=" metricpipelines"})) == 0
```
## 7. Activate Istio Metrics
To enable collection of Istio metrics, define a MetricPipeline that has the istio section enabled as input:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: input: istio: enabled: true output: otlp: endpoint:
```
```
value: https://backend.example.com:4317
```
With this, the agent starts collecting all Istio metrics from Istio sidecars.
If you are using the istio input, you can also collect Envoy metrics. Envoy metrics provide insights into the performance and behavior of the Envoy proxy, such as request rates, latencies, and error counts. These metrics are useful for observability and troubleshooting service mesh traffic.
For details, see the list of available Envoy metrics and server metrics .
##  Note
Envoy metrics are only available for the istio input. Ensure that Istio sidecars are correctly injected into your workloads for Envoy metrics to be available.
By default, Envoy metrics collection is disabled.
To activate Envoy metrics, enable the envoyMetrics section in the MetricPipeline specification under the istio input:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: envoy-metrics spec: input: istio: enabled: true envoyMetrics: enabled: true output: otlp: endpoint: value: https://backend.example.com:4317
```
-
- k8s.job.active\_pods
- k8s.job.desired\_successful\_pods
- k8s.job.failed\_pods
- k8s.job.max\_parallel\_pods
- k8s.job.successful\_pods
## 8. Deactivate OTLP Metrics
By default, otlp input is enabled.
To drop the push-based OTLP metrics that are received by the metric gateway, define a MetricPipeline that has the otlp section disabled as an input:
```
apiVersion: telemetry.kyma-project.io/v1alpha1 kind: MetricPipeline metadata: name: backend spec: input: istio: enabled: true otlp: disabled: true output: otlp: endpoint: value: https://backend.example.com:4317
```
With this, the agent starts collecting all Istio metrics from Istio sidecars, and the push-based OTLP metrics are dropped.