OpenChoreo Chooses OpenObserve for Cloud-Native Logging and Tracing

OpenObserve Is Growing Across the Cloud-Native Ecosystem

We are thrilled to announce that OpenChoreo, a CNCF sandbox open-source Internal Developer Platform (IDP) for Kubernetes, has integrated OpenObserve as a supported backend for logging and tracing.

This is more than just a new integration; it’s a signal that OpenObserve is becoming the go-to observability platform for cloud-native teams who want powerful, easy-to-use, and truly open-source observability without the complexity and cost of heavyweight commercial alternatives.

OpenChoreo + OpenObserve: A Real-World Validation

OpenChoreo is a CNCF sandbox project that provides a modular, open-source Internal Developer Platform for Kubernetes. Its architecture is specifically designed to let platform teams plug in their preferred tools for different concerns including observability.

When the OpenChoreo community went looking for an observability backend to integrate, they chose OpenObserve. They built two dedicated modules:

• Logging module : Routes application and platform logs to OpenObserve, queryable directly from OpenChoreo's Backstage portal, CLI, and MCP server.
• Tracing module : Sends distributed traces to OpenObserve, surfaced seamlessly across all OpenChoreo interfaces via a module adapter.

How To: Install the Tracing Module for OpenObserve in OpenChoreo

Want to try it yourself? Here's a concise walkthrough to get the OpenObserve-backed tracing module running in your OpenChoreo cluster. Read deatils here.

Prerequisites

• OpenChoreo must be installed with the observability plane enabled
• Deploy the openchoreo-observability-plane Helm chart with tracing adapter enabled:

--set observer.tracingAdapter.enabled="true"

Step 1 : Store Your OpenObserve Credentials

OpenChoreo uses the External Secrets Operator to manage secrets. Add your OpenObserve credentials to your secret store and create a Kubernetes secret named openobserve-admin-credentials.

The example below uses OpenBao (as set up in the OpenChoreo installation guide):

kubectl exec -it -n openbao openbao-0 -- \
    bao kv put secret/openobserve-admin-credentials \
    ZO_ROOT_USER_EMAIL='YOUR_USERNAME' \
    ZO_ROOT_USER_PASSWORD='YOUR_PASSWORD'

Then create an ExternalSecret to pull those credentials into your cluster:

kubectl apply -f - <<EOF
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: openobserve-admin-credentials
  namespace: openchoreo-observability-plane
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: ClusterSecretStore
    name: default
  target:
    name: openobserve-admin-credentials
  data:
    - secretKey: ZO_ROOT_USER_EMAIL
      remoteRef:
        key: openobserve-admin-credentials
        property: ZO_ROOT_USER_EMAIL
    - secretKey: ZO_ROOT_USER_PASSWORD
      remoteRef:
        key: openobserve-admin-credentials
        property: ZO_ROOT_USER_PASSWORD
EOF

Step 2: Install the Tracing Module

Run the following Helm command to install the tracing module in standalone mode (default, recommended for most use cases):

helm upgrade --install observability-tracing-openobserve \
  oci://ghcr.io/openchoreo/helm-charts/observability-tracing-openobserve \
  --create-namespace \
  --namespace openchoreo-observability-plane \
  --version 0.2.1

That's it! OpenObserve is now your distributed tracing backend in OpenChoreo.

Step 3 (Optional) : Switch to High-Availability Mode

Need production-grade scale? Switch to the distributed HA deployment, which uses separate components (router, ingester, querier, etc.) backed by object storage (S3, MinIO, etc.):

helm upgrade --install observability-tracing-openobserve \
  oci://ghcr.io/openchoreo/helm-charts/observability-tracing-openobserve \
  --namespace openchoreo-observability-plane \
  --version 0.2.1 \
  --reuse-values \
  --set openobserve-standalone.enabled=false \
  --set openobserve.enabled=true

Refer to the OpenObserve Helm chart documentation to configure the distributed deployment.

Note: Avoiding Conflicts with the Logging Module

If OpenObserve is already installed via the observability-logs-openobserve module, disable the bundled standalone chart to avoid conflicts:

helm upgrade --install observability-tracing-openobserve \
  oci://ghcr.io/openchoreo/helm-charts/observability-tracing-openobserve \
  --create-namespace \
  --namespace openchoreo-observability-plane \
  --version 0.2.1 \
  --set openobserve-standalone.enabled=false

Community That Shows Up

One thing the OpenChoreo contributor specifically called out was the responsiveness of the OpenObserve community on Slack. When questions came up during development, answers came quickly.

This matters to us. OpenObserve is not just a product, it's a community. We believe that open source only works when the people behind it are genuinely invested in helping others succeed. We're proud of our community, and we're grateful to the OpenChoreo team for giving us the opportunity to support them.

What This Means for You

If you are building or running a Kubernetes-based platform and you need observability that is:

• Easy to deploy and operate
• Unified across logs, metrics, and traces
• OpenTelemetry compatible
• Truly open source

then OpenObserve is worth a serious look.

The OpenChoreo integration is a real-world example of teams choosing OpenObserve not because they had to, but because it genuinely made their lives easier. That's the kind of adoption we're building toward.

Get Started with OpenObserve

• OpenObserve Website: openobserve.ai
• Documentation: openobserve.ai/docs
• Join our Slack Community
• GitHub

And if you want to explore OpenChoreo and the OpenObserve modules:

• 🌐 openchoreo.dev
• 📦 openchoreo.dev/modules

Have you integrated OpenObserve into your project? We'd love to hear about it. Reach out to us on Slack or tag us on social media.