Distributed tracing

• The monitor tab in the Jaeger UI for TempoStack instances uses a new default metrics namespace: traces.span.metrics. Before this update, the Jaeger UI used an empty namespace. The new traces.span.metrics namespace default is also used by the OpenTelemetry Collector 0.113.0. You can set the empty value for the metrics namespace by using the following field in the TempoStack custom resouce: spec.template.queryFrontend.monitorTab.redMetricsNamespace: "".

  Warning

  This is a breaking change. If you are using both the Red Hat OpenShift distributed tracing platform (Tempo) and Red Hat build of OpenTelemetry, you must upgrade to the Red Hat build of OpenTelemetry 3.4 before upgrading to the Red Hat OpenShift distributed tracing platform (Tempo) 3.4.

• New and optional spec.timeout field in the TempoStack and TempoMonolithic custom resource definitions for configuring one timeout value for all components. The timeout value is set to 30 seconds, 30s, by default.

  Warning

  This is a breaking change.

• Before this update, the distributed tracing platform (Tempo) failed on the IBM Z (s390x) architecture. With this update, the distributed tracing platform (Tempo) is available for the IBM Z (s390x) architecture. (TRACING-3545)
• Before this update, the distributed tracing platform (Tempo) failed on clusters with non-private networks. With this update, you can deploy the distributed tracing platform (Tempo) on clusters with non-private networks. (TRACING-4507)

• Before this update, the Jaeger UI might fail due to reaching a trace quantity limit, resulting in the 504 Gateway Timeout error in the tempo-query logs. After this update, the issue is resolved by introducing two optional fields in the tempostack or tempomonolithic custom resource:

  • New spec.timeout field for configuring the timeout.

  • New spec.template.queryFrontend.jaegerQuery.findTracesConcurrentRequests field for improving the query performance of the Jaeger UI.

    Tip

    One querier can handle up to 20 concurrent queries by default. Increasing the number of concurrent queries further is achieved by scaling up the querier instances.

• Before this update, the Jaeger UI could fail with the 502 - Bad Gateway Timeout error. After this update, you can configure timeout in ingress annotations. (TRACING-4238)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Support for securing the Jaeger UI and Jaeger APIs with the OpenShift OAuth Proxy. (TRACING-4108)
• Support for using the service serving certificates, which are generated by OpenShift Container Platform, on ingestion APIs when multitenancy is disabled. (TRACING-3954)
• Support for ingesting by using the OTLP/HTTP protocol when multitenancy is enabled. (TRACING-4171)
• Support for the AWS S3 Secure Token authentication. (TRACING-4176)
• Support for automatically reloading certificates. (TRACING-4185)
• Support for configuring the duration for which service names are available for querying. (TRACING-4214)

• Before this update, storage certificate names did not support dots. With this update, storage certificate name can contain dots. (TRACING-4348)
• Before this update, some users had to select a certificate when accessing the gateway route. With this update, there is no prompt to select a certificate. (TRACING-4431)
• Before this update, the gateway component was not scalable. With this update, the gateway component is scalable. (TRACING-4497)
• Before this update the Jaeger UI might fail with the 504 Gateway Time-out error when accessed via a route. With this update, users can specify route annotations for increasing timeout, such as haproxy.router.openshift.io/timeout: 3m, when querying large data sets. (TRACING-4511)

• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Before this update, secrets were perpetually generated on OpenShift Container Platform 4.16 because the operator tried to reconcile a new openshift.io/internal-registry-pull-secret-ref annotation for service accounts, causing a loop. With this update, the operator ignores this new annotation. (TRACING-4434)

• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Support for the Tempo monolithic deployment.

• Red Hat OpenShift distributed tracing platform (Tempo) 3.2 is based on the open source Grafana Tempo 2.4.1.
• Allowing the overriding of resources per component.

• Before this update, the Jaeger UI only displayed services that sent traces in the previous 15 minutes. With this update, the availability of the service and operation names can be configured by using the following field: spec.template.queryFrontend.jaegerQuery.servicesQueryDuration. (TRACING-3139)
• Before this update, the query-frontend pod might get stopped when out-of-memory (OOM) as a result of searching a large trace. With this update, resource limits can be set to prevent this issue. (TRACING-4009)

• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Red Hat OpenShift distributed tracing platform (Jaeger) 3.2 is based on the open source Jaeger release 1.57.0.

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Currently, when used with the Tempo Operator, the Jaeger UI only displays services that have sent traces in the last 15 minutes. For services that did not send traces in the last 15 minutes, traces are still stored but not displayed in the Jaeger UI. (TRACING-3139)
• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Red Hat OpenShift distributed tracing platform (Tempo) 3.1 is based on the open source Grafana Tempo 2.3.1.
• Support for cluster-wide proxy environments.
• Support for TraceQL to Gateway component.

• Before this update, when a TempoStack instance was created with the monitorTab enabled in OpenShift Container Platform 4.15, the required tempo-redmetrics-cluster-monitoring-view ClusterRoleBinding was not created. This update resolves the issue by fixing the Operator RBAC for the monitor tab when the Operator is deployed in an arbitrary namespace. (TRACING-3786)
• Before this update, when a TempoStack instance was created on an OpenShift Container Platform cluster with only an IPv6 networking stack, the compactor and ingestor pods ran in the CrashLoopBackOff state, resulting in multiple errors. This update provides support for IPv6 clusters.(TRACING-3226)

• Currently, when used with the Tempo Operator, the Jaeger UI only displays services that have sent traces in the last 15 minutes. For services that did not send traces in the last 15 minutes, traces are still stored but not displayed in the Jaeger UI. (TRACING-3139)
• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Red Hat OpenShift distributed tracing platform (Jaeger) 3.1 is based on the open source Jaeger release 1.53.0.

• Before this update, the connection target URL for the jaeger-agent container in the jager-query pod was overwritten with another namespace URL in OpenShift Container Platform 4.13. This was caused by a bug in the sidecar injection code in the jaeger-operator, causing nondeterministic jaeger-agent injection. With this update, the Operator prioritizes the Jaeger instance from the same namespace as the target deployment. (TRACING-3722)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Support for the ARM architecture.
• Support for cluster-wide proxy environments.

• Before this update, the Red Hat OpenShift distributed tracing platform (Jaeger) Operator used other images than relatedImages. This caused the ImagePullBackOff error in disconnected network environments when launching the jaeger pod because the oc adm catalog mirror command mirrors images specified in relatedImages. This update provides support for disconnected environments when using the oc adm catalog mirror CLI command. (TRACING-3546)

• Currently, Apache Spark is not supported.
• Currently, the streaming deployment via AMQ/Kafka is not supported on the IBM Z and IBM Power architectures.

• Support for the ARM architecture.
• Support for span request count, duration, and error count (RED) metrics. The metrics can be visualized in the Jaeger console deployed as part of Tempo or in the web console in the Observe menu.

• Before this update, the TempoStack CRD was not accepting custom CA certificate despite the option to choose CA certificates. This update fixes support for the custom TLS CA option for connecting to object storage. (TRACING-3462)
• Before this update, when mirroring the Red Hat OpenShift distributed tracing platform Operator images to a mirror registry for use in a disconnected cluster, the related Operator images for tempo, tempo-gateway, opa-openshift, and tempo-query were not mirrored. This update fixes support for disconnected environments when using the oc adm catalog mirror CLI command. (TRACING-3523)
• Before this update, the query frontend service of the Red Hat OpenShift distributed tracing platform was using internal mTLS when gateway was not deployed. This caused endpoint failure errors. This update fixes mTLS when Gateway is not deployed. (TRACING-3510)

• Currently, when used with the Tempo Operator, the Jaeger UI only displays services that have sent traces in the last 15 minutes. For services that did not send traces in the last 15 minutes, traces are still stored but not displayed in the Jaeger UI. (TRACING-3139)
• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Apache Spark is not supported.
• The streaming deployment via AMQ/Kafka is unsupported on the IBM Z and IBM Power architectures.

• Currently, the custom TLS CA option is not implemented for connecting to object storage. (TRACING-3462)
• Currently, when used with the Tempo Operator, the Jaeger UI only displays services that have sent traces in the last 15 minutes. For services that did not send traces in the last 15 minutes, traces are still stored but not displayed in the Jaeger UI. (TRACING-3139)
• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, the Tempo query frontend service must not use internal mTLS when Gateway is not deployed. This issue does not affect the Jaeger Query API. The workaround is to disable mTLS. (TRACING-3510)

  Workaround

  Disable mTLS as follows:

  1. Open the Tempo Operator ConfigMap for editing by running the following command:

     $ oc edit configmap tempo-operator-manager-config -n openshift-tempo-operator 1

     1

     The project where the Tempo Operator is installed.

  2. Disable the mTLS in the Operator configuration by updating the YAML file:

     data:
       controller_manager_config.yaml: |
         featureGates:
           httpEncryption: false
           grpcEncryption: false
           builtInCertManagement:
             enabled: false

  3. Restart the Tempo Operator pod by running the following command:

     $ oc rollout restart deployment.apps/tempo-operator-controller -n openshift-tempo-operator

• Missing images for running the Tempo Operator in restricted environments. The Red Hat OpenShift distributed tracing platform (Tempo) CSV is missing references to the operand images. (TRACING-3523)

  Workaround

  Add the Tempo Operator related images in the mirroring tool to mirror the images to the registry:

  kind: ImageSetConfiguration
  apiVersion: mirror.openshift.io/v1alpha2
  archiveSize: 20
  storageConfig:
    local:
      path: /home/user/images
  mirror:
    operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13
      packages:
      - name: tempo-product
        channels:
        - name: stable
    additionalImages:
    - name: registry.redhat.io/rhosdt/tempo-rhel8@sha256:e4295f837066efb05bcc5897f31eb2bdbd81684a8c59d6f9498dd3590c62c12a
    - name: registry.redhat.io/rhosdt/tempo-gateway-rhel8@sha256:b62f5cedfeb5907b638f14ca6aaeea50f41642980a8a6f87b7061e88d90fac23
    - name: registry.redhat.io/rhosdt/tempo-gateway-opa-rhel8@sha256:8cd134deca47d6817b26566e272e6c3f75367653d589f5c90855c59b2fab01e9
    - name: registry.redhat.io/rhosdt/tempo-query-rhel8@sha256:0da43034f440b8258a48a0697ba643b5643d48b615cdb882ac7f4f1f80aad08e

• Apache Spark is not supported.
• The streaming deployment via AMQ/Kafka is unsupported on the IBM Z and IBM Power architectures.

• Currently, the custom TLS CA option is not implemented for connecting to object storage. (TRACING-3462)
• Currently, when used with the Tempo Operator, the Jaeger UI only displays services that have sent traces in the last 15 minutes. For services that did not send traces in the last 15 minutes, traces are still stored but not displayed in the Jaeger UI. (TRACING-3139)
• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, the Tempo query frontend service must not use internal mTLS when Gateway is not deployed. This issue does not affect the Jaeger Query API. The workaround is to disable mTLS. (TRACING-3510)

  Workaround

  Disable mTLS as follows:

  1. Open the Tempo Operator ConfigMap for editing by running the following command:

     $ oc edit configmap tempo-operator-manager-config -n openshift-tempo-operator 1

     1

     The project where the Tempo Operator is installed.

  2. Disable the mTLS in the Operator configuration by updating the YAML file:

     data:
       controller_manager_config.yaml: |
         featureGates:
           httpEncryption: false
           grpcEncryption: false
           builtInCertManagement:
             enabled: false

  3. Restart the Tempo Operator pod by running the following command:

     $ oc rollout restart deployment.apps/tempo-operator-controller -n openshift-tempo-operator

• Missing images for running the Tempo Operator in restricted environments. The Red Hat OpenShift distributed tracing platform (Tempo) CSV is missing references to the operand images. (TRACING-3523)

  Workaround

  Add the Tempo Operator related images in the mirroring tool to mirror the images to the registry:

  kind: ImageSetConfiguration
  apiVersion: mirror.openshift.io/v1alpha2
  archiveSize: 20
  storageConfig:
    local:
      path: /home/user/images
  mirror:
    operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13
      packages:
      - name: tempo-product
        channels:
        - name: stable
    additionalImages:
    - name: registry.redhat.io/rhosdt/tempo-rhel8@sha256:e4295f837066efb05bcc5897f31eb2bdbd81684a8c59d6f9498dd3590c62c12a
    - name: registry.redhat.io/rhosdt/tempo-gateway-rhel8@sha256:b62f5cedfeb5907b638f14ca6aaeea50f41642980a8a6f87b7061e88d90fac23
    - name: registry.redhat.io/rhosdt/tempo-gateway-opa-rhel8@sha256:8cd134deca47d6817b26566e272e6c3f75367653d589f5c90855c59b2fab01e9
    - name: registry.redhat.io/rhosdt/tempo-query-rhel8@sha256:0da43034f440b8258a48a0697ba643b5643d48b615cdb882ac7f4f1f80aad08e

• Before this update, connection was refused due to a missing gRPC port on the jaeger-query deployment. This issue resulted in transport: Error while dialing: dial tcp :16685: connect: connection refused error message. With this update, the Jaeger Query gRPC port (16685) is successfully exposed on the Jaeger Query service. (TRACING-3322)
• Before this update, the wrong port was exposed for jaeger-production-query, resulting in refused connection. With this update, the issue is fixed by exposing the Jaeger Query gRPC port (16685) on the Jaeger Query deployment. (TRACING-2968)
• Before this update, when deploying Service Mesh on single-node OpenShift clusters in disconnected environments, the Jaeger pod frequently went into the Pending state. With this update, the issue is fixed. (TRACING-3312)
• Before this update, the Jaeger Operator pod restarted with the default memory value due to the reason: OOMKilled error message. With this update, this issue is fixed by removing the resource limits. (TRACING-3173)

• Apache Spark is not supported.
• The streaming deployment via AMQ/Kafka is unsupported on the IBM Z and IBM Power architectures.

• Support the operator maturity Level IV, Deep Insights, which enables upgrading, monitoring, and alerting of the TempoStack instances and the Tempo Operator.
• Add Ingress and Route configuration for the Gateway.
• Support the managed and unmanaged states in the TempoStack custom resource.
• Expose the following additional ingestion protocols in the Distributor service: Jaeger Thrift binary, Jaeger Thrift compact, Jaeger gRPC, and Zipkin. When the Gateway is enabled, only the OpenTelemetry protocol (OTLP) gRPC is enabled.
• Expose the Jaeger Query gRPC endpoint on the Query Frontend service.
• Support multitenancy without Gateway authentication and authorization.

• Before this update, the Tempo Operator was not compatible with disconnected environments. With this update, the Tempo Operator supports disconnected environments. (TRACING-3145)
• Before this update, the Tempo Operator with TLS failed to start on OpenShift Container Platform. With this update, the mTLS communication is enabled between Tempo components, the Operand starts successfully, and the Jaeger UI is accessible. (TRACING-3091)
• Before this update, the resource limits from the Tempo Operator caused error messages such as reason: OOMKilled. With this update, the resource limits for the Tempo Operator are removed to avoid such errors. (TRACING-3204)

• Currently, the custom TLS CA option is not implemented for connecting to object storage. (TRACING-3462)
• Currently, when used with the Tempo Operator, the Jaeger UI only displays services that have sent traces in the last 15 minutes. For services that did not send traces in the last 15 minutes, traces are still stored but not displayed in the Jaeger UI. (TRACING-3139)
• Currently, the distributed tracing platform (Tempo) fails on the IBM Z (s390x) architecture. (TRACING-3545)

• Currently, the Tempo query frontend service must not use internal mTLS when Gateway is not deployed. This issue does not affect the Jaeger Query API. The workaround is to disable mTLS. (TRACING-3510)

  Workaround

  Disable mTLS as follows:

  1. Open the Tempo Operator ConfigMap for editing by running the following command:

     $ oc edit configmap tempo-operator-manager-config -n openshift-tempo-operator 1

     1

     The project where the Tempo Operator is installed.

  2. Disable the mTLS in the Operator configuration by updating the YAML file:

     data:
       controller_manager_config.yaml: |
         featureGates:
           httpEncryption: false
           grpcEncryption: false
           builtInCertManagement:
             enabled: false

  3. Restart the Tempo Operator pod by running the following command:

     $ oc rollout restart deployment.apps/tempo-operator-controller -n openshift-tempo-operator

• Missing images for running the Tempo Operator in restricted environments. The Red Hat OpenShift distributed tracing platform (Tempo) CSV is missing references to the operand images. (TRACING-3523)

  Workaround

  Add the Tempo Operator related images in the mirroring tool to mirror the images to the registry:

  kind: ImageSetConfiguration
  apiVersion: mirror.openshift.io/v1alpha2
  archiveSize: 20
  storageConfig:
    local:
      path: /home/user/images
  mirror:
    operators:
    - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.13
      packages:
      - name: tempo-product
        channels:
        - name: stable
    additionalImages:
    - name: registry.redhat.io/rhosdt/tempo-rhel8@sha256:e4295f837066efb05bcc5897f31eb2bdbd81684a8c59d6f9498dd3590c62c12a
    - name: registry.redhat.io/rhosdt/tempo-gateway-rhel8@sha256:b62f5cedfeb5907b638f14ca6aaeea50f41642980a8a6f87b7061e88d90fac23
    - name: registry.redhat.io/rhosdt/tempo-gateway-opa-rhel8@sha256:8cd134deca47d6817b26566e272e6c3f75367653d589f5c90855c59b2fab01e9
    - name: registry.redhat.io/rhosdt/tempo-query-rhel8@sha256:0da43034f440b8258a48a0697ba643b5643d48b615cdb882ac7f4f1f80aad08e

Prerequisites

• You are logged in to the OpenShift Container Platform web console as a cluster administrator with the cluster-admin role.
• For Red Hat OpenShift Dedicated, you must be logged in using an account with the dedicated-admin role.

• You have completed setting up the required object storage by a supported provider: Red Hat OpenShift Data Foundation, MinIO, Amazon S3, Azure Blob Storage, Google Cloud Storage. For more information, see "Object storage setup".

  Warning

  Object storage is required and not included with the distributed tracing platform (Tempo). You must choose and set up object storage by a supported provider before installing the distributed tracing platform (Tempo).

Verification

• In the Details tab of the page of the installed Operator, under ClusterServiceVersion details, verify that the installation Status is Succeeded.

Prerequisites

• An active OpenShift CLI (oc) session by a cluster administrator with the cluster-admin role.

  Tip
  • Ensure that your OpenShift CLI (oc) version is up to date and matches your OpenShift Container Platform version.

  • Run oc login:

    $ oc login --username=<your_username>

• You have completed setting up the required object storage by a supported provider: Red Hat OpenShift Data Foundation, MinIO, Amazon S3, Azure Blob Storage, Google Cloud Storage. For more information, see "Object storage setup".

  Warning

  Object storage is required and not included with the distributed tracing platform (Tempo). You must choose and set up object storage by a supported provider before installing the distributed tracing platform (Tempo).

Verification

• Check the Operator status by running the following command:

  $ oc get csv -n openshift-tempo-operator

Prerequisites

• You are logged in to the OpenShift Container Platform web console as a cluster administrator with the cluster-admin role.
• For Red Hat OpenShift Dedicated, you must be logged in using an account with the dedicated-admin role.

• You have completed setting up the required object storage by a supported provider: Red Hat OpenShift Data Foundation, MinIO, Amazon S3, Azure Blob Storage, Google Cloud Storage. For more information, see "Object storage setup".

  Warning

  Object storage is required and not included with the distributed tracing platform (Tempo). You must choose and set up object storage by a supported provider before installing the distributed tracing platform (Tempo).

Prerequisites

• An active OpenShift CLI (oc) session by a cluster administrator with the cluster-admin role.

  Tip
  • Ensure that your OpenShift CLI (oc) version is up to date and matches your OpenShift Container Platform version.

  • Run the oc login command:

    $ oc login --username=<your_username>

• You have completed setting up the required object storage by a supported provider: Red Hat OpenShift Data Foundation, MinIO, Amazon S3, Azure Blob Storage, Google Cloud Storage. For more information, see "Object storage setup".

  Warning

  Object storage is required and not included with the distributed tracing platform (Tempo). You must choose and set up object storage by a supported provider before installing the distributed tracing platform (Tempo).

Prerequisites

• You are logged in to the OpenShift Container Platform web console as a cluster administrator with the cluster-admin role.
• For Red Hat OpenShift Dedicated, you must be logged in using an account with the dedicated-admin role.

Prerequisites

• An active OpenShift CLI (oc) session by a cluster administrator with the cluster-admin role.

  Tip
  • Ensure that your OpenShift CLI (oc) version is up to date and matches your OpenShift Container Platform version.

  • Run the oc login command:

    $ oc login --username=<your_username>

Prerequisites

• You have installed the latest version of the AWS CLI.

• To provide a TLS certificate in a secret, configure it in the TempoStack custom resource.

  Note

  This feature is not supported with the enabled Tempo Gateway.

  TLS for receivers and using a user-provided certificate in a secret

  apiVersion: tempo.grafana.com/v1alpha1
  kind:  TempoStack
  # ...
  spec:
  # ...
    template:
      distributor:
        tls:
          enabled: true 1
          certName: <tls_secret> 2
          caName: <ca_name> 3
  # ...

  1

  TLS enabled at the Tempo Distributor.

  2

  Secret containing a tls.key key and tls.crt certificate that you apply in advance.

  3

  Optional: CA in a config map to enable mutual TLS authentication (mTLS).

• Alternatively, you can use the service serving certificates that are generated by OpenShift Container Platform.

  Note

  Mutual TLS authentication (mTLS) is not supported with this feature.

  TLS for receivers and using the service serving certificates that are generated by OpenShift Container Platform

  apiVersion: tempo.grafana.com/v1alpha1
  kind:  TempoStack
  # ...
  spec:
  # ...
    template:
      distributor:
        tls:
          enabled: true 1
  # ...

  1

  Sufficient configuration for the TLS at the Tempo Distributor.

• To provide a TLS certificate in a secret, configure it in the TempoMonolithic custom resource.

  Note

  This feature is not supported with the enabled Tempo Gateway.

  TLS for receivers and using a user-provided certificate in a secret

  apiVersion: tempo.grafana.com/v1alpha1
  kind:  TempoMonolithic
  # ...
    spec:
  # ...
    ingestion:
      otlp:
        grpc:
          tls:
            enabled: true 1
            certName: <tls_secret> 2
            caName: <ca_name> 3
  # ...

  1

  TLS enabled at the Tempo Distributor.

  2

  Secret containing a tls.key key and tls.crt certificate that you apply in advance.

  3

  Optional: CA in a config map to enable mutual TLS authentication (mTLS).

• Alternatively, you can use the service serving certificates that are generated by OpenShift Container Platform.

  Note

  Mutual TLS authentication (mTLS) is not supported with this feature.

  TLS for receivers and using the service serving certificates that are generated by OpenShift Container Platform

  apiVersion: tempo.grafana.com/v1alpha1
  kind:  TempoMonolithic
  # ...
    spec:
  # ...
    ingestion:
      otlp:
        grpc:
          tls:
            enabled: true
        http:
          tls:
            enabled: true 1
  # ...

  1

  Minimal configuration for the TLS at the Tempo Distributor.

Prerequisites

• Monitoring for user-defined projects is enabled in the cluster.

Procedure

• Add the openshift.io/cluster-monitoring: "true" label in the project where the Tempo Operator is installed, which is openshift-tempo-operator by default.

Prerequisites

• The Red Hat OpenShift distributed tracing platform (Jaeger) Operator has been installed and verified.
• You have reviewed the instructions for how to customize the deployment.
• You have access to the OpenShift CLI (oc) that matches your OpenShift Container Platform version.
• You have access to the cluster as a user with the cluster-admin role.

Prerequisites

• The OpenShift Elasticsearch Operator has been installed.
• The Red Hat OpenShift distributed tracing platform (Jaeger) Operator has been installed.
• You have reviewed the instructions for how to customize the deployment.
• You have access to the OpenShift CLI (oc) that matches your OpenShift Container Platform version.
• You have access to the cluster as a user with the cluster-admin role.

Prerequisites

• The AMQ Streams Operator has been installed. If using version 1.4.0 or higher you can use self-provisioning. Otherwise you must create the Kafka instance.
• The Red Hat OpenShift distributed tracing platform (Jaeger) Operator has been installed.
• You have reviewed the instructions for how to customize the deployment.
• You have access to the OpenShift CLI (oc) that matches your OpenShift Container Platform version.
• You have access to the cluster as a user with the cluster-admin role.

• Red Hat OpenShift distributed tracing platform instance names must be unique. If you want to have multiple Red Hat OpenShift distributed tracing platform (Jaeger) instances and are using sidecar injected agents, then the Red Hat OpenShift distributed tracing platform (Jaeger) instances should have unique names, and the injection annotation should explicitly specify the Red Hat OpenShift distributed tracing platform (Jaeger) instance name the tracing data should be reported to.
• If you have a multitenant implementation and tenants are separated by namespaces, deploy a Red Hat OpenShift distributed tracing platform (Jaeger) instance to each tenant namespace.

• Probabilistic - The sampler makes a random sampling decision with the probability of sampling equal to the value of the sampling.param property. For example, using sampling.param=0.1 samples approximately 1 in 10 traces.
• Rate Limiting - The sampler uses a leaky bucket rate limiter to ensure that traces are sampled with a certain constant rate. For example, using sampling.param=2.0 samples requests with the rate of 2 traces per second.

• logging.openshift.io/elasticsearch-cert-management: "true"
• logging.openshift.io/elasticsearch-cert.jaeger-<shared-es-node-name>: "user.jaeger"
• logging.openshift.io/elasticsearch-cert.curator-<shared-es-node-name>: "system.logging.curator"

Prerequisites

• The Red Hat OpenShift Service Mesh Operator is installed.
• The {logging-title} is installed with default configuration in your cluster.
• The Elasticsearch node and the Jaeger instances must be deployed in the same namespace. For example, tracing-system.