OpenTelemetry Observability

OpenTelemetry observability without rebuilding your backend

Send telemetry from OpenTelemetry SDKs, OTel Collector, and OTLP into Guance, then analyse metrics, logs, traces, profiles, and incident context together while preserving vendor-neutral instrumentation.

Get started 获取你的专属技术栈监控方案

Why connect OpenTelemetry to a shared observability platform

01Preserve open instrumentation

Collect metrics, logs, and traces with OpenTelemetry while reducing backend lock-in.

02Correlate beyond individual signals

Connect OTel data to hosts, containers, RUM, events, and service ownership.

03Support polyglot services

Use consistent resource and service attributes across Java, Go, Python, Node.js, and other runtimes.

04Reduce backend operations

Combine open collection with managed storage, querying, alerting, and data pipelines.

05Keep migration options open

Reuse existing SDK and Collector deployments as the architecture evolves.

OpenTelemetry data path

Carry consistent service context from instrumentation to investigation

Connect collection, processing, service identity, and investigation so open telemetry remains useful after it reaches daily operations.

  1. Standardise instrumentation

    Collect metrics, logs, and traces with OpenTelemetry SDKs, automatic instrumentation, or an existing Agent.

  2. Process and route telemetry

    Use OTel Collector, OTLP, or DataKit to transform, filter, and forward telemetry.

  3. Preserve service identity

    Keep service, environment, version, and resource attributes consistent across signals.

  4. Investigate and validate

    Use DQL, dashboards, monitors, events, logs, and traces to find the issue and confirm recovery.

Ingest OpenTelemetry metrics, logs, and traces

Send data from OpenTelemetry SDKs, OTel Collector, and OTLP-compatible pipelines into Guance. Preserve open instrumentation while adding managed analysis for metrics, logs, traces, profiles, dashboards, and alerts.
获取你的专属技术栈监控方案
Ingest OpenTelemetry metrics, logs, and traces
Move from a trace to services, logs, and infrastructure

Move from a trace to services, logs, and infrastructure

Continue from a slow or failed request into service topology, related logs, hosts, containers, and dependent resources. Shared resource and service attributes keep the investigation connected.
获取你的专属技术栈监控方案

Standardise service identity and attributes across teams

Use consistent service, environment, version, and resource attributes to organise telemetry from different languages and teams. The same context becomes searchable, alertable, and reusable across investigations.
获取你的专属技术栈监控方案
Standardise service identity and attributes across teams
Turn OTel telemetry into dashboards, alerts, and incident workflows

Turn OTel telemetry into dashboards, alerts, and incident workflows

Use DQL queries, dashboards, anomaly detection, monitors, and events so OpenTelemetry data participates in daily operations instead of stopping at the collection layer.
获取你的专属技术栈监控方案

Combine OpenTelemetry with full-stack observability

Connect OTel telemetry with RUM, CI, infrastructure, Kubernetes, log management, and security data to understand complete system behavior and user impact.
获取你的专属技术栈监控方案
Combine OpenTelemetry with full-stack observability

Connected Observability

Bring Kubernetes on-site back to the full running context

Continue to access the corresponding capabilities based on the current issue, without needing to re-search the product catalog for entry points.

Application Performance MonitoringContinue from OTel traces into service latency, errors, dependencies, and code-level methods. Log ManagementCorrelate OpenTelemetry logs and traces with service, environment, version, and trace identifiers. Infrastructure MonitoringConnect service telemetry to hosts, containers, processes, networks, and cloud resources. Kubernetes MonitoringCorrelate workloads, pods, containers, Kubernetes events, and application traces.

Continue building an open observability stack

Kubernetes monitoring

Kubernetes monitoring

 AWS monitoring

AWS monitoring

 Alibaba Cloud monitoring

Alibaba Cloud monitoring

 Azure monitoring

Azure monitoring

 Huawei Cloud monitoring

Huawei Cloud monitoring

Frequently Asked Questions

Can OpenTelemetry data be sent directly to Guance?

Yes. Teams can use OpenTelemetry SDKs, OTel Collector, or OTLP-compatible pipelines to send metrics, logs, and traces to Guance for unified analysis.

Do I still need DataKit if I already run OTel Collector?

It depends on the collection architecture. DataKit can provide Guance collection and processing capabilities, while existing OpenTelemetry pipelines can remain in place and forward compatible telemetry. The two can be used together.

How are OpenTelemetry and APM related?

OpenTelemetry standardises instrumentation and telemetry transport. APM focuses on analysing service performance, request traces, errors, dependencies, and operational workflows. Guance uses OpenTelemetry data as part of that broader analysis layer.

Does Guance replace OTel Collector?

No. OTel Collector receives, processes, and routes telemetry. Guance provides managed storage, querying, correlation, alerting, and incident workflows. Existing Collector deployments can remain in place and export telemetry to Guance.

Which OpenTelemetry signals and protocols can I use?

Teams can send metrics, logs, and traces over OTLP, plus profiles where the relevant instrumentation supports them. Guance preserves service and resource attributes for cross-signal queries and investigations.

See how Guance receives OpenTelemetry data and connects it to full-stack operational context

获取你的专属技术栈监控方案

Next steps

Get started > View documentation > View pricing >