Datadog Alternatives for Teams Operating in China: Eight Routes to Evaluate

Replacing Datadog means replacing more than a destination for telemetry. Its public product range includes infrastructure monitoring, APM, logs, RUM, alerting and security products. A team that relies on those integrations also has dashboards, permissions, monitors and historical records to account for. That existing work belongs in the migration decision.

For teams operating in mainland China, the question also involves procurement, network access, local support and the paths data takes across clouds and data centers. This guide compares eight routes with those conditions in mind. It is published by Guance, one of the candidates, and uses official product documentation rather than an independent ranking or a production-scale benchmark. A Chinese deployment requirement should be checked against the actual service and contract; translating this article does not establish availability in another market.

Start with the constraint, then make a shortlist

You can evaluate a candidate without retiring Datadog first. A representative service, a controlled collection path and an explicit way back provide more useful evidence than a broad feature matrix. Two to four weeks can be an initial evaluation window, not a promise that migration will finish within it. Guance's free edition is one way to explore a small scope; verify its current quotas, features and retention first.

What usually changes the decision

The bill needs a workload model

A platform's price page lists units, but the application determines how many of them you consume. Logs, indexed events, trace ingestion and retention, custom metrics, RUM, profiles, security data and licensed users can follow different meters. Not every product uses every meter, and contract terms may add commitments or overage rules.

More services and tenants can increase the number of metric series. Keeping more request detail can increase trace and log volume. Engineers may want context available for the next incident while finance wants a predictable bill. Compare the same traffic, signal coverage, sampling and retention, including the overlap period and network egress. Lowering collection or retention can remove evidence as well as cost; it is not an improvement unless the remaining data still meets the team's requirements.

Operating in China adds deployment and purchasing questions

Procurement, invoicing, payment, security review, access performance, support language and incident escalation can decide whether a product is usable. These are account-specific checks, not facts that can be inferred from a headquarters location or a translated website.

Ask where application telemetry is collected, processed, stored and backed up; which network paths are required; and which service and support commitments appear in the agreement. A regional endpoint is not proof of every data-handling commitment. A product with the desired features may still need a different deployment or support arrangement.

Multi-cloud investigations require consistent context

A request may pass through a browser, gateway, application, queue and database across several clouds or an IDC. Cloud-provider tools can accept external data, but collecting it is only the beginning. Service identity, timing, trace context, network access and query permissions need to line up before an engineer can follow that request.

Use that real investigation path as a test. A single interface does not establish that every relevant signal is present or that all service names refer to the same entity.

AI assistance needs more than a callable interface

MCP, a CLI and an API let an Agent access tools. They do not, by themselves, establish a reliable incident-response process. Evaluate how the Agent chooses a time range, cites evidence, handles missing data, observes permissions and asks for approval. Distinguish a proposed explanation from a confirmed cause.

Start with read-only work. Any later action needs a defined scope, audit record and recovery procedure. An approval prompt is not proof that every risky action will be detected, and stopping a task does not undo an operation already performed. Human operators remain responsible for assessing the result.

Use the same criteria for every candidate

1. Guance: a candidate for China and multi-cloud operations

Guance is worth evaluating when local deployment and support, several infrastructure environments and connected investigations are central requirements. Its documented product range includes logs, metrics, traces, RUM, infrastructure, Kubernetes, alerts and events. It is not an item-for-item copy of Datadog. Confirm the required integrations and identities before judging whether the signals form a useful shared investigation.

Chinese documentation, support channels and deployment options can be part of the assessment. They do not establish every customer's contract or prove a lower bill. Model the actual workload and test permissions, fields, queries and data paths. A free trial should remain within the edition's applicable limits.

Separate the tool interface from the task environment. OWL CLI, MCP Server and OpenAPI can expose Guance data and functions to Codex, Claude Code, OpenClaw or an internal Agent. The team then defines the investigation process, tool permissions and recovery procedure. Obsy AI documentation distinguishes Copilot assistance from Agent Teams tasks. Teams can organize Agent responsibilities, Skills, MCP services and Channels; its task documentation covers outputs, approval requests and stopping execution.

A service called checkout-service in logs, checkout-api in traces and “payments” in a runbook needs a verified mapping in either approach. A product cannot reconstruct logs that were never collected or a service owner that was never recorded. Guance's AI service terms require review of AI output and do not establish guaranteed incident resolution or accuracy.

If a team already depends on many Datadog-specific modules or integrations, assess those individually. Keeping Datadog can be reasonable when it meets the deployment requirements and migration work outweighs the benefit. Guance belongs on a shortlist when its operating model fits; the trial should determine the outcome.

2. Grafana LGTM and Prometheus: retain control of the stack

This route suits teams that already maintain Prometheus and Grafana and want to retain that engineering investment. Prometheus handles metrics, Loki logs, Tempo traces and Mimir scalable metrics storage; Thanos is a separate project that can extend a Prometheus-based metrics architecture. Grafana provides query and visualization interfaces across configured sources.

Self-management gives the team choices about deployment and customization. It also leaves collection, high cardinality, access control, storage, upgrades, backups and recovery with the team. Logs, traces, RUM, events and notifications need the appropriate components and deliberate correlation. Grafana Cloud changes the operating boundary; its managed responsibilities should not be judged using the same maintenance list as a self-hosted stack.

Choose this route when running the observability platform is an intentional, staffed engineering responsibility. License cost alone does not establish a lower total cost.

3. Elastic Observability and ELK: start from search requirements

Elasticsearch expertise and substantial log-search requirements make Elastic a candidate. Distinguish an ELK logging installation from the broader Elastic Observability product, which also covers APM, metrics and digital experience. Security analytics should be evaluated against Elastic Security and the relevant edition or license, rather than assumed to be included with every observability configuration.

For self-managed Elasticsearch, account for mappings, shards, storage tiers, scaling, upgrades and recovery. Elastic Cloud Hosted and Serverless assign different infrastructure responsibilities. If the deployment only collects logs, it can still leave gaps between a log entry and a user-visible failure. Test the configured cross-signal workflow rather than treating that gap as a universal product limitation.

Bring representative text searches, historical queries and incident investigations. Search performance and cost need the workload, not a generic claim that one engine is best.

4. New Relic: compare another international SaaS platform

New Relic documents APM, browser monitoring, logs, infrastructure and related observability capabilities. It is a candidate when those services and an international SaaS purchasing model meet the organization's requirements.

For China operations, repeat the network, support, purchasing and data-handling checks. Changing SaaS vendors does not automatically remove those constraints. Compare required integrations and the applicable billing model under the same workload, including any user or compute dimensions. If procurement or deployment geography is the original obstacle, confirm that the proposed arrangement actually changes it.

5. Dynatrace: evaluate discovery and governance for complex systems

Dynatrace is worth investigating when service discovery, topology and enterprise governance are important requirements. Coverage depends on supported technologies, instrumentation and deployment, so use an actual application estate to assess it. A topology visualization and an AI-generated explanation still need verification against the system.

Estimate the selected products, consumption, deployment and implementation effort. Do not assume either a higher or lower total cost from the enterprise positioning alone. Check China-specific availability, access and support for the intended arrangement. This route is most useful when it addresses complexity the team actually has, rather than serving only as another brand on a price comparison.

6. Alibaba Cloud SLS and ARMS: fit the cloud's operating model

When most resources are already on Alibaba Cloud, SLS and ARMS can fit existing collection and purchasing arrangements. Evaluate the logging, application-monitoring and resource-monitoring boundaries separately.

SLS also collects logs from other clouds and data centers. It is inaccurate to describe it as Alibaba-only. Cross-cloud use still needs network access, permissions, egress estimates and consistent fields. SLS and ARMS must be configured to provide the required investigation path; a shared vendor does not prove end-to-end correlation.

A workload concentrated on Alibaba Cloud gives this route a clear reason for inclusion. For a broader estate, compare the same cross-cloud incident workflow with other candidates.

7. Tencent Cloud observability, CLS and TMP: assess the configured combination

Tencent Cloud's monitoring, Cloud Log Service and managed Prometheus services can fit teams with a substantial Tencent Cloud estate and an existing procurement channel. The question is which combination covers the application's metrics, logs, dependencies and alerts.

CLS LogListener supports Tencent Cloud, other clouds and self-managed data centers. External ingestion is therefore possible; common identity, tracing relationships, networking and cost still need validation. Avoid using “cloud neutrality” as a vague score. Demonstrate whether an engineer can cross the actual boundaries in the workload.

8. SigNoz and OpenObserve: assess the deployment, not the label

SigNoz and OpenObserve offer self-managed and hosted routes. They are worth examining when deployment control, available code and the chosen product's capabilities match the team's needs. Review the license and edition rather than assuming every feature belongs to every distribution.

Self-management means retaining responsibility for upgrades, security, permissions, capacity, backups and alert governance. Hosted services change some of those responsibilities. Check enterprise features, integration coverage and support against the actual edition. Neither “open source” nor a small initial installation proves a lighter or cheaper long-term platform.

Make the proof of concept answer operational questions

First confirm collection, permissions and the stop procedure in an isolated environment. Then use a representative non-critical service or approved redacted replay. A simple demo can establish connectivity; it cannot establish production-scale completeness, performance or cost.

1. Choose a useful request path. Include a front-end entry point, API, database or middleware, Kubernetes workload and relevant error logs where applicable.
2. Retain the current system. Verify the collector's ability to send in parallel, including queues, retries, overhead, duplicate records and extra charges. Do not assume a second destination is harmless.
3. Revisit historical incidents. Compare how many systems and people are needed to form and verify a hypothesis. Record missing signals and differences in alert behavior.
4. Calculate the same scope. Include logs, metrics, traces, RUM, retention, licensed users, AI features, support and the overlap period using applicable units.
5. Test Agent boundaries. In isolation, review evidence citations, permissions, approval handling, audit outputs, failed actions and recovery. Record human corrections; feature descriptions do not demonstrate a complete operational workflow.
6. Ask the on-call team to use it. Check whether the investigation is understandable and repeatable, not merely presentable in a purchasing spreadsheet.

Before expansion, document acceptance and stop conditions, the old collection and alert configuration, historical-data access, and who verifies restoration. Moving all dashboards or history need not be the first step. Do not remove low-frequency recovery or compliance monitoring solely because it was quiet during the trial.

The shortlist should reflect the actual constraint: deployment and support for China operations, retained open-source expertise, search requirements, a concentrated cloud footprint or complex enterprise governance. The useful replacement is the one that improves the team's work while meeting its data and cost requirements. For Guance, a small parallel ingestion test can assess the workspace; a separate Obsy Agent Teams evaluation can assess authorized task execution and review. Success in either does not prove every Datadog capability has been replaced.

Sources

Technical review: October 27, 2026. This article reports documentation review, not an executed production benchmark, regional compliance assessment or migration exercise.

• Datadog products and pricing
• Prometheus overview and Grafana Cloud
• Elastic Observability
• OpenTelemetry
• Alibaba Cloud SLS collection and Tencent CLS collection, in Chinese
• Guance product overview and Obsy Agent Teams tasks
• SigNoz documentation and OpenObserve documentation