SupportConsoleDevelopersStart a trialContact

Chapter 1. Forward to third-party systems

You can forward logs to third-party systems by using various output types, including OTLP, HTTP, and external Loki instances. This section covers destination-specific configuration for external systems. For general ClusterLogForwarder setup, inputs, outputs, filters, and pipelines, see the Configure section.

The following table lists external log forwarding destinations tested and validated with Red Hat OpenShift Logging.

Table 1.1. Tested and validated external log forwarding destinations
Output typeProtocolTested versionsLogging versions

Elasticsearch v6

HTTP 1.1

6.8.1

6.0+

Elasticsearch v7

HTTP 1.1

7.12.2

6.0+

Elasticsearch v8

HTTP 1.1

8.6.1

6.0+

Elasticsearch v9

HTTP 1.1

9.3.3

6.0+

Google Cloud Logging

REST over HTTPS

Latest

6.0+

HTTP (Generic)

HTTP 1.1

Vector 0.28-1, 0.34-1

6.0+

Kafka

Kafka 0.11

2.4.1, 2.7.0

6.0+

Loki (External)

REST over HTTP/HTTPS

2.3.0

6.0+

OTLP

HTTP/HTTPS

OpenTelemetry Collector 0.88+

6.1+

Splunk

HEC

9.0.0

6.0+

Syslog

RFC3164, RFC5424

rsyslog 8.39.0

6.0+

Amazon CloudWatch

REST over HTTPS

Latest

6.0+

Amazon S3

REST over HTTPS

Latest

6.0+

Azure Monitor Logs

REST over HTTPS

Latest

6.0+

Note

This table lists versions that Red Hat has tested. Other versions might work but Red Hat has not validated them. For Red Hat OpenShift Logging managed destinations (LokiStack), version compatibility is managed automatically.

1.2. Log forwarding to third-party systems
Copy link

To send logs to specific endpoints inside and outside your OpenShift Container Platform cluster, you specify a combination of outputs and pipelines in a ClusterLogForwarder custom resource (CR). You can also use inputs to forward the application logs associated with a specific project to an endpoint. A Kubernetes Secret object provides authentication.

pipeline

Defines simple routing from one log type to one or more outputs, or the logs to send. The log types are one of the following:

  • application. Container logs generated by user applications running in the cluster, except infrastructure container applications.
  • infrastructure. Container logs from pods that run in the openshift*, kube*, or default projects and journal logs sourced from node file system.
  • audit. Audit logs generated by the node audit system, auditd, Kubernetes API server, OpenShift API server, and OVN network.

You can add labels to outbound log messages by using key:value pairs in the pipeline. For example, you might add a label to messages that the collector forwards to other data centers or label the logs by type. The collector also forwards labels added to objects with the log message.

input

Forwards the application logs associated with a specific project to a pipeline.

In the pipeline, you define the input sources to forward using an inputRef parameter and where to forward the logs to using an outputRef parameter.

Secret
A key:value map that has confidential data such as user credentials.

Note the following:

  • You can use many types of outputs in the ClusterLogForwarder custom resource (CR) to send logs to servers that support different protocols.

The following example forwards the audit logs to a secure external Elasticsearch instance.

Sample log forwarding outputs and pipelines

kind: ClusterLogForwarder
apiVersion: observability.openshift.io/v1
metadata:
  name: instance
  namespace: openshift-logging
spec:
  serviceAccount:
    name: logging-admin
  outputs:
    - name: external-es
      type: elasticsearch
      elasticsearch:
        url: <elasticsearch_url>
        version: 8
        index: '{.log_type||"undefined"}'
        authentication:
          username:
            key: username
            secretName: es-secret
          password:
            key: password
            secretName: es-secret
      tls:
        ca:
          key: ca-bundle.crt
          secretName: es-secret
        certificate:
          key: tls.crt
          secretName: es-secret
        key:
          key: tls.key
          secretName: es-secret
  pipelines:
    - name: my-logs
      inputRefs:
        - application
        - infrastructure
      outputRefs:
        - external-es

version
Forwarding to an external Elasticsearch of version 8.x or greater requires you to specify the version field.
index
The index field reads the .log_type field value and falls back to "unknown" if not found.
secretName
Use username and password to authenticate to the server
ca
Enable Mutual Transport Layer Security (mTLS) between collector and Elasticsearch. The spec identifies the keys and secret for the certificates that they represent.

1.3. Create a secret by using the CLI
Copy link

Create a secret by using the CLI.

You can create a secret by using the OpenShift CLI (oc).

Prerequisites

  • You have administrator permissions.
  • You installed the Loki Operator.
  • You installed the OpenShift CLI (oc).

Procedure

  • Create a secret in the directory that contains your certificate and key files by running the following command: 

    $ oc create secret generic -n openshift-logging <your_secret_name> \
  --from-file=tls.key=<your_key_file> \
  --from-file=tls.crt=<your_crt_file> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password>
    Note

    Use generic or opaque secrets for best results.

Verification

  • Verify that a secret was created by running the following command: 

    $ oc get secret -n openshift-logging

1.4. Configure OTLP output
Copy link

Cluster administrators can use the OpenTelemetry Protocol (OTLP) output to collect and forward logs to OTLP receivers. The OTLP output uses the specification defined by the OpenTelemetry Observability framework to send data over HTTP with JSON encoding.

Important

Before implementing OTLP log forwarding, be aware of the following limitations:

  • Field name compatibility: The log collector uses the ViaQ data model internally and then translates to the OpenTelemetry data model before sending logs to OTLP receivers. Due to this internal translation, you must use ViaQ field names (not OpenTelemetry field names) in the following contexts:

    • Filters: When configuring prune, drop, or other filters in your ClusterLogForwarder custom resource, use ViaQ field names such as kubernetes.pod_name. The filter operates on the internal ViaQ representation before translating to OpenTelemetry. Filters do not work with OpenTelemetry field names such as k8s.pod_name.
    • Alerting rules: When creating log-based alerting rules, use ViaQ field names. For authorization purposes, your filter must include kubernetes_namespace_name, not k8s_namespace_name.
  • Data model translation: Although logs are stored and queried in OpenTelemetry format, the internal ViaQ-to-OpenTelemetry translation means that some OpenTelemetry-native features might not work as expected.

Procedure

  1. Create or edit a ClusterLogForwarder custom resource (CR) to enable forwarding using OTLP. 

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: clf-otlp
spec:
  serviceAccount:
    name: <service_account_name>
  outputs:
  - name: otlp
    type: otlp
    otlp:
      tuning:
        compression: gzip
        deliveryMode: AtLeastOnce
        maxRetryDuration: 20
        maxWrite: 10M
        minRetryDuration: 5
      url: <otlp_url>
  pipelines:
  - inputRefs:
    - application
    - infrastructure
    - audit
    name: otlp-logs
    outputRefs:
    - otlp
    url
    This URL must be absolute and is a placeholder for the OTLP endpoint where logs are sent.
    tuning.compression
    Compression algorithm to use. Valid values are gzip, snappy, or none.
    tuning.deliveryMode
    Delivery mode for log forwarding. Valid values are AtLeastOnce or AtMostOnce.
    tuning.maxRetryDuration
    Maximum time in seconds to retry failed deliveries.
    tuning.maxWrite
    Maximum size of a single write request.
    tuning.minRetryDuration

    Minimum time in seconds between retries.

    Note

    The OTLP output uses the OpenTelemetry data model, which is different from the ViaQ data model that is used by other output types. For more information, see OpenTelemetry Semantic Conventions.

  2. Apply the ClusterLogForwarder custom resource: 

    $ oc apply -f <filename>.yaml

Verification

  1. Verify that the ClusterLogForwarder status shows Ready: 

    $ oc get clusterlogforwarder clf-otlp -n openshift-logging \
  -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}'

    The output should show True.

  2. Verify that OTLP is functioning correctly by checking the LokiStack metrics dashboard:

    1. In the OpenShift Container Platform web console, navigate to Observe Dashboards.
    2. From the Dashboard dropdown, select OpenShift Logging / LokiStack / Writes.
    3. Check the Distributor - structured metadata panel for incoming OTLP log records.

To configure log forwarding to Loki, you must create a ClusterLogForwarder custom resource (CR) with an output to Loki, and a pipeline that uses the output. The output to Loki can use the HTTP (insecure) or HTTPS (secure HTTP) connection.

Prerequisites

  • You have installed Red Hat OpenShift Logging Operator.
  • You have administrator access to OpenShift Container Platform.
  • You have installed OpenShift CLI (oc).
  • You have a Loki logging system running at the URL specified in the url field.

Procedure

  1. Create or edit a YAML file that defines the ClusterLogForwarder CR object: 

    apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
  namespace: <log_forwarder_namespace>
spec:
  serviceAccount:
    name: <service_account_name>
  outputs:
  - name: loki-output
    type: loki
    loki:
      authentication:
        username:
          key: username
          secretName: to-loki-secret
        password:
          key: password
          secretName: to-loki-secret
        token:
          from: secret
          secret:
            key: ca-bundle.crt
            name: to-loki-secret
      labelKeys:
        - <label_keys>
      tenantKey: '{.kubernetes.namespace_name||"application"}'
      url: https://loki.example.com:3100
  pipelines:
  - name:  my-pipeline
    inputRefs:
    - application
    - audit
    outputRefs:
    - loki-output
    serviceAccount.name
    Specify the name of your service account.
    outputs.name
    Specify a name for the output.
    type
    Specify the type as loki.
    authentication
    Specify the authentication information.
    labelKeys
    Specify the log record keys to map to Loki stream labels. If you do not set the labelKeys field, the ClusterLogForwarder CR uses these default keys: log_type, kubernetes.container_name, kubernetes.namespace_name, kubernetes.pod_name.
    tenantKey
    Specify the tenant for the logs. The value can be a combination of static and dynamic values consisting of field paths separated by ||. Encase dynamic values inside single curly brackets {}. Follow dynamic values with a static fallback value.
    url
    Specify the URL for Loki.
    inputRefs
    Specify the names of inputs defined in the input.name field for this pipeline. You can also use the built-in values application, infrastructure, audit.
    outputRefs

    Specify the names of outputs defined in the outputs.name field for this pipeline.

    Note

    Because Loki requires log streams to be correctly ordered by timestamp, labelKeys always includes the kubernetes_host label set, even if you do not specify it. This inclusion ensures that each stream originates from a single host, which prevents timestamps from becoming disordered due to clock differences on different hosts.

  2. Apply the ClusterLogForwarder CR object by running the following command: 

    $ oc apply -f <filename>.yaml
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top