Observability for Xinchuang environments: compatibility, deployment, and migration

Replacing infrastructure with China-developed processors, operating systems, and databases changes the monitoring requirements too. An Agent that worked on the previous server may not run on the new architecture. An exporter may connect to a database while omitting the metrics the on-call team needs.

In a Xinchuang program—China's domestic IT adoption and substitution initiatives—the useful question is therefore concrete: can the proposed monitoring system observe the exact hardware, software versions, and mixed environment being deployed? Product origin and a long integration list are insufficient answers.

This guide compares a domestic integrated platform such as Guance, open-source self-hosting, domestic cloud monitoring, and international products. It focuses on compatibility, control over data, and gradual migration. Procurement rules and timelines must be established for the organization and project; no universal deadline or blanket product exclusion is assumed here.

Published by Guance. This documentation-based evaluation framework was reviewed on October 14, 2026. It does not certify a product against a regulatory regime or claim that the listed hardware combinations were tested.

Overview

Three requirements that change the evaluation

Compatibility must be specific. A statement that an Agent supports Linux or ARM does not establish support for every Kunpeng or Phytium system, Kylin or UnionTech UOS release, or hardened kernel configuration. Include CPU architecture, OS release, kernel, runtime libraries, container runtime, and package format in the inventory. Database checks should identify the product and version, including Dameng, KingbaseES, OceanBase, or openGauss where relevant.

Control over data is an architecture requirement. Identify where logs, metrics, traces, metadata, backups, and diagnostic bundles go. If the project requires operation inside a defined network boundary, test installation, upgrades, licensing, support access, and optional AI features under that constraint. A private deployment label does not prove that every component has no external dependency.

The transition creates a mixed estate. Old and new platforms may run together for years. Monitor both until their responsibilities actually change. Otherwise the migration can replace one gap with another: a new dashboard for the replacement infrastructure and no common view of the business transaction crossing both environments.

Domestic integrated observability: Guance

Guance documents private deployment and DataKit installation. Use those requirements as the starting point for a supported configuration, then obtain confirmation for the exact target estate. A collector binary's architecture and the backend's deployment prerequisites are separate checks. Private deployment and DataKit installation

There are documented Guance integrations for OceanBase and openGauss. An integration page establishes a documented collection path, not certification for every release, edition, operating system, or deployment topology. Compare the required permissions and collected metrics with the actual database configuration. For other domestic databases, require the same evidence instead of extrapolating from those two integrations.

An integrated platform is valuable when the team can investigate a service across the traditional and replacement environments using consistent identity and telemetry. Test the handoff between them: does the trace continue, are the relevant logs available, and do host and container attributes identify the correct machine?

Also evaluate workspace isolation, role permissions, token lifecycle, access records, and retention in the purchased version. These controls have to satisfy the project's defined acceptance requirements; the presence of a feature does not itself establish an audit outcome. An unrelated customer's audit or uptime history would not prove this deployment compliant or reliable.

For AI-assisted features, specify which components execute locally, which model endpoints they call, what data they receive, and how they are updated. A private backend and an external model service are distinct deployment decisions. Guance is a candidate when its supported configuration and operational model cover the estate, with those boundaries confirmed in the delivery scope.

Open-source self-hosting: Zabbix or Prometheus with Grafana

Open-source software offers source access and deployment control, subject to its license obligations. It does not eliminate package compatibility, maintenance, or support requirements. Zabbix publishes component requirements; Prometheus describes a metrics-based system with exporters and related components. Use those primary descriptions to decide what must be deployed, rather than assuming that one product name supplies every observability signal. Zabbix requirements and Prometheus overview

A successful build on one ARM machine does not validate every domestic OS image. Check runtime dependencies, security settings, service management, upgrade behavior, and any architecture-specific collector. An exporter also needs semantic review: a metric named “connections” is useful only if its meaning, scope, and refresh behavior match the query and alert that use it.

For a community database exporter, inspect maintenance activity, supported versions, credentials, collection load, and the response to a failed query. Decide who fixes it when a database upgrade changes a system table. Avoid assuming either that all community integrations are immature or that every required integration is already production-ready.

If the scope includes logs and tracing, select the additional components deliberately. Define common service names, time handling, retention, and investigation links. Budget storage, backups, upgrades, recovery, and on-call ownership alongside implementation. This route fits a team prepared to maintain the integration, especially when the immediate requirement is infrastructure monitoring with a manageable set of custom collectors.

Monitoring from domestic cloud providers

Services from Alibaba Cloud, Huawei Cloud, or Tencent Cloud may simplify monitoring for workloads already concentrated on the corresponding platform. Evaluate the specific managed database and infrastructure integration included in the service and region being purchased.

Do not group database products under a cloud provider merely because of a historical association or similar name. Verify the actual service, ownership boundary, supported API, and billing relationship. Nor should monitoring be assumed to stop at the cloud boundary: supported external collection must be checked individually.

A useful trial includes an on-premises server or another-cloud service that participates in the same business path. Check network access, identity, collection, time alignment, query permissions, and how responders move between systems. A cloud-native service fits when that scope meets the need; the mixed transition becomes more expensive if the team must maintain several independent alert and dashboard systems.

For data placement, examine the selected region and associated services, backups, support procedures, and exports. A domestic cloud endpoint alone is not a complete description of where all operational information is processed.

Evaluate international products against the same requirements

An international vendor should not be declared universally incompatible with domestic processors, operating systems, or databases without inspecting its supported configuration. Some requirements may be met through standard telemetry or an existing integration; others may lack a supported path.

Equally, protocol acceptance does not prove that a product satisfies a procurement rule or can run within a required network boundary. Establish the available deployment model, exact processing locations, support arrangements, and required external dependencies. If a mandatory requirement cannot be met, exclude that offering on the documented requirement rather than on a broad claim about every product from that region.

This keeps technical suitability and procurement eligibility distinct. A platform can be technically capable and still unsuitable for a particular project, or suitable for an overseas workload while excluded from a restricted domestic environment.

Plan a gradual migration and a measurable acceptance test

Begin with a written inventory and support matrix. Include versions and responsibility for each collector, backend, database integration, and operating system. Sample that matrix on real equipment before expanding deployment.

Next, run a representative business service across both old and new environments. Compare host measurements, database metrics, logs, and a trace that crosses the boundary. Preserve existing monitoring while the new data is reconciled. Compatibility with an ingestion protocol does not automatically migrate historical data, dashboard definitions, or alert thresholds.

Then test the operational boundary. In a project requiring offline operation, install and upgrade from the approved package supply, remove external access, and exercise normal operation and recovery. Test backup restoration as well as data collection. Document the behavior of optional features when their dependencies are unavailable.

Finally, verify access separation, administrative records, retention, and exports against the project's audit requirements. Define measurable limits for collector CPU and memory, data delay, missing metrics, and failure recovery. A 72-hour sustained run can be one agreed test window, but it is neither a universal certification standard nor proof of long-term reliability. Include realistic load changes and interruptions.

Common questions

Can an existing Zabbix installation remain in use?

Yes, where the actual components and templates remain supported and satisfy the requirements. Validate the new environment first. Coexistence can preserve working alerts while new database or container coverage is added; it needs clear ownership to avoid duplicate notifications.

Will a private deployment have the same AI features as SaaS?

That depends on the delivered version, model service, permissions, and network design. Put feature availability, data movement, updates, and acceptance criteria into the delivery scope. Do not infer equivalence from the product name.

What matters most at acceptance?

A working supported configuration on the specified equipment, demonstrated operation within the required network boundary, and evidence that access and retention controls behave as designed. Tie each test to an actual requirement.

How can the transition avoid two disconnected monitoring systems?

Preserve common service identifiers and test an investigation across both environments. A shared view can help, but data collection, field mapping, and permissions have to support it. Keep the old monitoring path until the new one has passed reconciliation.

How can a compatibility list be tested rather than trusted?

Run the exact versions under representative load, observe the collector itself, introduce a service interruption, and check recovery. Record missing metrics and resource costs. Require an owner and remediation plan for each gap before broad rollout.