## 6. Deploy the Pipeline
To activate the LogPipeline , apply the logpipeline.yaml resource file in your cluster:
```
kubectl apply -f logpipeline.yaml
```
## Result
You activated a LogPipeline and logs start streaming to your backend.
To check that the pipeline is running, wait until the status conditions of the LogPipeline in your cluster have status True :
```
 Output Code kubectl get logpipeline
```
backend   True                      True              True
## Kyma Modules With Logging Capabilities
Kyma bundles modules that can be involved in user flows. If you want to collect all logs of all modules, enable the application input for the kyma-system namespace.
## Istio
The Istio module is crucial as it provides the Ingress Gateway . Typically, this is where external requests enter the cluster scope. Furthermore, every component that's part of the Istio Service Mesh runs an Istio proxy. Using the Istio telemetry API, you can enable access logs for the Ingress Gateway and the proxies individually.
The Istio module is configured with an extension provider called kyma-logs . T o activate the provider on the global mesh level using the Istio Telemetry API, place a resource to the istio-system namespace.
The following example configures all Istio proxies with the kyma-logs extension provider, which, by default, reports access logs to the log gateway of the Telemetry module.
## 
```
Sample Code apiVersion: telemetry.istio.io/v1
```
```
kind: Telemetry metadata: name: mesh-default namespace: istio-system spec: accessLogging: - providers: - name: kyma-logs
```
## Operations
A LogPipeline runs several OTel Collector instances in your cluster. This Deployment serves OTLP endpoints and ships received data to the configured backend.
The Telemetry module ensures that the OTel Collector instances are operational and healthy at any time, for example, with buffering and retries. However, there may be situations when the instances drop logs, or cannot handle the log load.
To detect and fix such situations, check the pipeline status and check out Troubleshooting [page 1968]. If you have set up pipeline health monitoring, check the alerts and reports in an integrated backend like SAP Cloud Logging. For details, see Setting up a MetricPipeline [page 1996], step Monitor Pipeline Health , as well as Integrate with SAP Cloud Logging [page 2011].
##  Caution
It's not recommended to access the metrics endpoint of the used OTel Collector instances directly, because the exposed metrics are no official API of the Telemetry module. Breaking changes can happen if the underlying OTel Collector version introduces such. Instead, use the pipeline status .
## Limitations
## · Throughput :
- When pushing OTLP logs of an average size of 2KB to the log gateway, using its default configuration (two instances), the Telemetry module can process approximately 12,000 logs per second (LPS). To ensure availability, the log gateway runs with multiple instances. For higher throughput, manually scale out the gateway by increasing the number of replicas. See Module Configuration and Status [page 1952]. Ensure that the chosen scaling factor does not exceed the maximum throughput of the backend, as it may refuse logs if the rate is too high.
- For example, to scale out the gateway for scenarios like a Large instance of SAP Cloud Logging (up to 30,000 LPS), you can raise the throughput to about 20,000 LPS by increasing the number of replicas to 4 instances.
- The log agent, running one instance per node, handles tailing logs from stdout using the runtime input. When writing logs of an average size of 2KB to stdout , a single log agent instance can process approximately 9,000 LPS.
- Load Balancing With Istio : By design, the connections to the gateway are long-living connections (because OTLP is based on gRPC and HTTP/2). For optimal scaling of the gateway, the clients or applications must balance the connections across the available instances, which is automatically achieved if you use an Istio sidecar. If your application has no Istio sidecar, the data is always sent to one instance of the gateway.
- Unavailability of Output : For up to 5 minutes, a retry for data is attempted when the destination is unavailable. After that, data is dropped.
- No Guaranteed Delivery : The used buffers are volatile. If the gateway or agent instances crash, logs data can be lost.
- Multiple LogPipeline Support : The maximum amount of LogPipeline resources is 5.
## Troubleshooting
## No Logs Arrive at the Backend
## Symptom :
- No logs arrive at the backend.
- In the LogPipeline status, the TelemetryFlowHealthy condition has status GatewayAllTelemetryDataDropped or AgentAllTelemetryDataDropped .
Cause : Incorrect backend endpoint configuration (such as using the wrong authentication credentials) or the backend is unreachable.
## Solution :
1. Check the error logs for the affected Pod by calling kubectl logs -n kyma-system {POD\_NAME} :
- For GatewayAllTelemetryDataDropped , check Pod telemetry-log-gateway .
- For AgentAllTelemetryDataDropped , check Pod telemetry-log-agent .
2. Check if the backend is up and reachable.
3. Fix the errors.
## Not All Logs Arrive at the Backend
## Symptom :
- The backend is reachable and the connection is properly configured, but some logs are refused.
- In the LogPipeline status, the TelemetryFlowHealthy condition has status GatewaySomeTelemetryDataDropped or AgentSomeTelemetryDataDropped .
Cause : It can happen due to a variety of reasons - for example, the backend is limiting the ingestion rate.
## Solution :
1. Check the error logs for the affected Pod by calling kubectl logs -n kyma-system {POD\_NAME} :
- For GatewaySomeTelemetryDataDropped , check Pod telemetry-log-gateway .
- For AgentSomeTelemetryDataDropped , check Pod telemetry-log-agent .
2. Check your observability backend to investigate potential causes.
3. If the backend is limiting the rate by refusing logs, try the options described in Buffer Filling Up [page 1969].
4. Otherwise, take the actions appropriate to the cause indicated in the logs.
## No Access Logs With Push-Based OTLP LogPipeline
Symptom : The Istio telemetry resource uses a push-based OTLP LogPipeline . Even though this pipeline is healthy, access logs do not arrive at the backend.
Cause : Istio cannot discover the OTLP endpoint.
Solution : Recreate the Istio telemetry resource. For details, see Istio [page 1967].
## Buffer Filling Up
Symptom : In the LogPipeline status, the TelemetryFlowHealthy condition has status GatewayBufferFillingUp or AgentBufferFillingUp .
Cause : The backend ingestion rate is too low compared to the export rate of the gateway or agent.
## Solution :
- Option 1: Increase maximum backend ingestion rate. For example, by scaling out the SAP Cloud Logging instances.
- Option 2: Reduce emitted logs by re-configuring the LogPipeline (for example, by disabling certain inputs or applying namespace filters).
- Option 3: Reduce emitted logs in your applications.
## Gateway Throttling
Symptom : In the LogPipeline status, the TelemetryFlowHealthy condition has status GatewayThrottling .
Cause : Gateway cannot receive logs at the given rate.
Solution : Manually scale out the gateway by increasing the number of replicas for the log gateway. See Module Configuration and Status [page 1952].