Deploy otel-trace-collector with CO south helm chart

The Otel trace collector is a south-side OpenTelemetry collector that receives application traces from customer workloads and forwards them into Virtana Platform’s trace pipeline. It works alongside the existing otel-metric-collector. Both collectors are deployed as part of the CO South Helm chart.

You can deploy the Otel trace collector if you want distributed tracing for applications running in Kubernetes clusters monitored by Virtana Platform. You can also view the traces correlated with metrics and topology in Global View for cross-cluster analysis and troubleshooting.

It collects and routes OTLP traces from cluster workloads into Virtana’s trace-router and back-end trace storage. A otel trace collector allows tagging spans with cluster identity, so traces can be aggregated and analyzed across clusters in Global View.

Prerequisites of the Otel trace collector deployment

You must have access to the cluster jumpbox.
You must have Virtana Platform access to download the South deployment bundle. To perform this task, see Deploy Virtana CO South on GKE Autopilot clusters.

Steps to deploy Otel trace collector

Deployment of otel-trace-collector follows the standard CO South Helm deployment model used for other observability components. Perform the following steps to deploy otel-trace-collector with the CO south helm chart:

In Virtana Platform CO home page, click System status, and select South Deployment.
Download the South deployment configuration bundle.
Edit the South override values YAML to enable the otel trace collector in the global section.
```
global:
  otel-trace-collector:
    enabled: true
```
This flag controls whether the otel trace collector component is deployed for this tenant as part of the south bundle.
Run the helm upgrade command using the provided chart version and your modified values file in the Virtana Platform.
```
helm upgrade <release-name> <chart-name> \
  --namespace <target-namespace> \
  --version <release-version> \
  -f <tenant-south-values>.yaml
```
- <tenant-south-values>.yaml: Your customized South override YAML.
- <target-namespace>: The target namespace will be opscruise.
- <release-version>: South Helm package version corresponding to your Virtana Platform release.
Validate that the otel trace collector pod and service are running in the target namespace.

Default service endpoints

Once the otel trace collector is deployed in the target namespace, you can view the following endpoints that are available inside the cluster:

You can use this otel trace collector service for applications to push spans:
```
otel-trace-collector-service.opscruise.svc.cluster.local:4317
```
Applications should export OTLP/gRPC traces to this endpoint.
Default trace-router service endpoint:
```
trace-router-service.opscruise.svc.cluster.local:4317
```
By default, the otel trace collector forwards spans to this trace router service.

Optional configuration overrides

All of the following overrides live under the otel trace collector key in the south override values YAML. You can further customize the behavior of otel trace collector in the override values file.

Override the trace-router endpoint

You can use this endpoint to override the default trace-router endpoint.

otel-trace-collector:
  config:
    exporters:
      otlp:
        endpoint: trace-router-service.opscruise.svc.cluster.local:4317

Use this when:

The trace-router endpoint differs from the default FQDN.
You need to route to a different trace back end in advanced or special deployments.

Configure cloud provider

The default cloud provider is onprem. You can also select the supported values, such as aws, gcp, azure, and onprem.

otel-trace-collector:
  cloudProvider: "onprem"

This is used for tagging and environment-specific handling inside the collector or Virtana Platform.

Add additional headers to spans

You can add custom headers, such as X-Scope-OrgID, to all exported spans.

otel-trace-collector:
  config:
    exporters:
      otlp:
        endpoint: trace-router-service.opscruise.svc.cluster.local:4317
        headers:
          X-Scope-OrgID: "co-x-scope-ID"

Use this when:

The trace back end expects per-tenant/org routing headers.
You need to logically separate spans by tenant or organization.

Add cluster tag to spans

You can tag spans with a cluster name.

otel-trace-collector:
  cluster:
    name: "co-cluster"

This enables cluster-level filtering and aggregation of trace data.

In this section: