Contact us

Join the community

Scan with WeChat
Join the official community group

Try Guance

Start online with usage-based pricing and a true cloud service.

Get started

Choose a Guance edition

Code repositories

Unified Observability Platform

Unified monitoring platform solution

For R&D, SRE, operations and maintenance, and platform teams, it unifies analysis metrics, logs, links, RUM, profiles, Kubernetes, cloud resources, business metrics, AI analysis, and alert events, ensuring fault troubleshooting is based on the same context.

What is a unified monitoring platform?

A unified monitoring platform is used to centrally collect, store, query, and correlate metrics, Logs, Traces, RUM, Profile, Kubernetes, cloud resources, events, and business metrics, enabling teams to understand why system anomalies occur, which services and users are affected, and who should handle them from the same context. Guance is not about simply lumping APM, logs, infrastructure monitoring, and alerts together, but about building relationships around services, hosts, pods, interfaces, access sessions, publishing, and business objects, helping R&D, SRE, operations, and platform teams reduce tool switching, unify data standards, and improve fault localization efficiency.

How does the unified monitoring platform handle real production faults?

When evaluating a unified monitoring platform, it's not enough to just look at metrics, logs, and links; it's even more important to see if a real fault can move from symptom to root cause and action.

The microservices interface suddenly slows down

When a Java/Spring Cloud service experiences interface timeouts, increased error rates, or order failures, Guance associate APM Trace, application logs, database slow queries, Redis/Kafka metrics, Pod status, and release events into the same troubleshooting loop.

R&D and SRE can start from alerts or business metrics, then continue to locate specific interfaces, dependencies, SQL, instances, versions, or responsible teams, reducing the back-and-forth between Prometheus, ELK, SkyWalking, and cloud consoles.

EntranceAlerts or business metrics
EvidenceTrace + Log + SQL
ActionPositioning service and responsible person

Abnormalities occur after Kubernetes release

When a new version releases a Pod reboot, 5xx interface, CPU spikes, or Kafka consumption delays, Guance Kubernetes events, container logs, service topology, resource levels, and change logs are placed on the same timeline.

The platform team can determine whether the anomaly is caused by image version, resource constraints, node pressure, dependency inavailability, or configuration changes, and assign rollback, scaling, rate limiting, or configuration fixes to the corresponding teams for execution.

EntranceRelease changes and Pod events
EvidenceResources + Logs + Service Topology
ActionRollback, scaling, or repairing configurations

The frontend experience declines, but the backend seems normal

When web pages are white screens, JS errors, resource loading is slow, or key conversions drop, Guance analyze RUM's real user experience monitoring, API requests, backend traces, CDN/gateway logs, and regional operator dimensions.

Business, front-end, and back-end teams can identify issues such as page resources, browser errors, interface timeouts, network paths, or backend dependencies, avoiding focusing only on server metrics and missing the real impact on user experience.

EntranceRUM experience and conversion anomaly
EvidenceJS error + API + Trace
ActionFix frontend, gateway, or backend dependencies

Why do enterprises need a unified monitoring platform?

APM, logs, and metrics are disconnected in context:A single interface timeout may involve application traces, error logs, Pod reboots, slow database queries, and user access experience. If data is scattered across multiple tools, troubleshooting requires manually building a timeline.

Multiple teams lack the same evidence:R&D, SRE, operations, platform, and business teams see different perspectives, making it easy to repeatedly communicate around "Is it my problem?" rather than directly locating services, resources, versions, or responsible persons.

Cloud-native and multi-cloud environments change rapidly:Kubernetes pods, containers, nodes, workloads, cloud resources, and release events are constantly changing, making static monitoring difficult to reflect true dependencies and the scope of impact.

Alarm noise affects fault response:The same failure can trigger multiple types of alerts, and if object relationships, business impact, and root context are missing, teams find it difficult to prioritize and reduce duplicate notifications.

Guance how to unify data monitoring and troubleshooting processes?

Unified access to observable data:Through DataKit, OpenTelemetry, RUM SDK, cloud vendor integration, and log collection, metrics, logs, links, RUM, profiles, events, infrastructure, and business data are integrated into a single data foundation.

Establishing object relationships and unified tags:Establish associations around services, hosts, pods, containers, cloud resources, interfaces, access sessions, and business objects, allowing a single alert to continue drilling down to traces, logs, resources, and the scope of impact.

Forming a full-link fault location process:Starting from degraded user experience, slow interfaces, rising error rates, pod reboots, or business metrics anomalies, locate service, dependency, version, resource, or team leader along a unified timeline.

Closed the loop of alerts, AI analysis, and review:Anomaly detection, alert notifications, event center, Obsy AI analysis, note-taking, and review are consolidated on a single platform, reducing duplicate alerts and information gaps.

Core capabilities of the unified monitoring platform

Frequently asked questions

What is an observability platform?

The observability platform is used to uniformly collect and correlate metrics, logs, links, RUM, Profile, Kubernetes, cloud resources, events, and business metrics, helping teams understand system status, user impact, and root causes from the same context.

What is the difference between observability platforms and traditional monitoring?

Traditional monitoring focuses more on fixed metrics and alerts, while observability platforms emphasize correlation analysis across metrics, Logs, Traces, RUM, infrastructure, and business data, using real data to explain system anomalies.

What is the relationship between observability platforms and unified monitoring platforms?

The unified monitoring platform emphasizes centralized management of multiple monitoring capabilities; The observability platform further emphasizes object relationships, contextual association, exploratory analysis, and fault closure. Guance simultaneously covers unified monitoring and observable analysis capabilities.

Can Prometheus, ELK, and Grafana still connect to Guance?

Yes, you can. Guance supports open standards and multiple data source access, allowing teams to establish unified query, alert, correlation analysis, and collaboration entry points while retaining existing collection capabilities.

How does the observability platform reduce MTTR?

By unifying timelines, relationships between service and resource objects, log chain jumps, RUM and APM association, AI-assisted analysis, and alert contexts, reduce the time spent manually switching tools and piecing evidence.

Let Guance match your unified monitoring platform solution implementation path

Book a demo