docs: add External Observability Platforms integration page

[rajshah4]

Summary

Add a customer-facing integration guide for redirecting OpenHands Enterprise conversation traces to an external OTLP-compatible observability platform (Langfuse, Honeycomb, Grafana Tempo, or any OTLP backend) instead of, or in addition to, the bundled Laminar.

• New page: enterprise/integrations/observability-platforms.mdx
• Nav: added enterprise/integrations/observability-platforms to the Enterprise → Integrations group in docs.json

Why

OHE ships with Laminar as its built-in tracing backend. Customers who already operate a different OTel-compatible observability platform want all conversation traces to flow into their platform with the same richness they get from Laminar today. This guide documents how to do that.

How it works

OHE's tracing layer is the Laminar Python SDK (lmnr), which wraps the OpenTelemetry SDK. The lmnr SDK respects standard OTEL_EXPORTER_OTLP_TRACES_* environment variables whenever LMNR_BASE_URL is not set. So the entire integration is an env-var change on the runtime pod — no source changes, no Helm chart patch.

The doc covers:

• The LMNR_BASE_URL → OTEL_EXPORTER_OTLP_TRACES_* switch (with a warning that LMNR_BASE_URL must be unset for the OTEL_* vars to take effect)
• Helm (Kubernetes) and Replicated VM (Admin Console) configuration paths
• Backend-specific config for Langfuse, Honeycomb, Tempo, and generic OTLP
• The nested conversation trace tree that lands in the backend (conversation → conversation.run → agent.step → llm.completion + tool.execute), with LLM spans carrying gen_ai.* model/token/input/output attributes
• Cost calculation and model-catalog registration
• Optional OTel Collector tap for batching/retry/dual-sink, plus a keep-Laminar-and-mirror recipe
• Troubleshooting accordion for the common failure modes

This was validated end-to-end against a self-hosted Langfuse v4 instance: traces emitted by the lmnr SDK inside a real OHE runtime pod landed in Langfuse with correct trace grouping, nesting, and observation-type classification (AGENT/CHAIN/GENERATION/TOOL).

Notes

• The Replicated VM / Admin Console path is flagged honestly as limited — the Admin Console does not currently expose OTEL_EXPORTER_OTLP_TRACES_* fields directly, mirroring how the existing Analytics page notes the Admin Console limitation for LLM_* settings.
• Cross-links to the existing Analytics page and the SDK Observability & Tracing guide are included.
• The doc uses the same Mintlify components (Info, Warning, Note, Tabs/Tab, CardGroup/Card, Tree, AccordionGroup/Accordion) and voice as the existing enterprise integration pages (azure-devops, slack, external-postgres).
• Opening from a same-repo branch (not a fork) so the Mintlify preview bot triggers.

Supersedes #700 (fork-based PR; closed because the Mintlify preview bot does not trigger on fork-based PRs).

Related Linear ticket: OHE-3032

This PR was created by an AI agent (OpenHands) on behalf of rajshah4.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
all-hands-ai	🟢 Ready	View Preview	Aug 7, 2026, 11:46 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[rajshah4]

Update: I rebased this branch on main to resolve a docs.json nav conflict. The sibling PR #702 (External LLM Gateways) merged on Aug 14 and touched the same Enterprise → Integrations nav group. The resolved nav now lists both new pages in order:

enterprise/integrations/external-llm-gateways
enterprise/integrations/observability-platforms

I also added a cross-link from this page to the new External LLM Gateways page so operators can distinguish trace export (this page) from LLM traffic routing (the gateways page). No content changes to the observability guide itself.

mergeable: true now. A fresh Mintlify preview should regenerate on this push. Happy to make any further edits the reviewers request.

This comment was created by an AI agent (OpenHands) on behalf of rajshah4.