Intelligent operations
Platform capabilities
Security analytics
AI
Dedicated compute
Dedicated compute keeps concurrent queries stable and complex analysis fast.
Learn moreDedicated compute
Dedicated compute keeps concurrent queries stable and complex analysis fast.
Learn moreContact us
Join the community
Try Guance
Start online with usage-based pricing and a true cloud service.
Get startedChoose a Guance edition
Implementation Guide
Building observability should not start with "connecting multiple tools," but rather from core business chains and high-frequency incidents. First, unify metrics, logs, links, RUM, Kubernetes, cloud resources, and business metrics, then establish sustainable troubleshooting processes around services, resources, versions, teams, and business objects.
Direct Answer
When building an observability platform, enterprises recommend starting with login, ordering, payment, core APIs, Kubernetes clusters, databases, and key third-party dependencies. The goal is not to replace all monitoring tools at once, but to first enable high-value systems to have continuous troubleshooting capability.
A practical construction path usually includes: unified collection and tagging, establishing relationships between service and resource objects, organizing views around incident scenarios, closing the loop for alerts and event response, accumulating reviews and knowledge bases, and finally gradually expanding to more business lines.
Foundation
Clearly define key links such as login, ordering, payment, query, push, and settlement, as well as the API gateway, application services, databases, caching, message queues, and third-party dependencies involved in each link.
Tags such as service, env, version, team, region, host, pod, cluster, business, etc. should be unified in advance; otherwise, subsequent metrics, logs, links, and alerts will be difficult to associate.
Review Prometheus, ELK, SkyWalking, OpenTelemetry, cloud vendor consoles, log collectors, and business monitoring systems to decide which to retain and which to access for unified access.
Clarify alert grading, duty rules, responsible persons, upgrade paths, and review mechanisms to prevent the observable platform from becoming a new query entry point without driving problem resolution.
Roadmap
Through DataKit, OpenTelemetry, Prometheus, log collection, cloud vendor integration, and open API access metrics, logs, links, RUM, events, and business metrics.
Establish relationships around services, hosts, pods, containers, databases, cloud resources, versions, teams, and business objects, allowing a single alert to further drill down to relevant evidence.
Prioritize high-frequency troubleshooting scenarios such as slow interfaces, increased error rates, Pod reboots, degraded page experience, abnormal logs, and business metrics anomalies.
Integrate anomaly detection, alarm notifications, event management, responsibility assignment, handling records, and review into the same process to reduce repeated alarms and information gaps.
Continuously optimize tagging, sampling, log retention, permissions, desensitization, cost, and SLO to make the observable platform part of the long-term stability project.
Team View
Next
Understand the definition of observability platforms, data types, differences from traditional monitoring, and selection criteria.
Observability Difference Between Platform and Traditional SurveillanceDetermine why the team needs to upgrade from traditional monitoring to an observability platform.
Checklist for observability platform selectionUsing a platform for evaluating real incident chains, data coverage, governance costs, and team collaboration standards.
Differences between full-link monitoring and observability platformsClarify how traces, logs, metrics, RUM, Kubernetes, and business data form a complete troubleshooting chain.
Observable platform and unified monitoringSee how Guance unify metrics, logs, links, RUM, Kubernetes, and business data.
650+ technology stacks and data integrationExplore access capabilities for DataKit, OpenTelemetry, Prometheus, cloud services, and mainstream technology stacks.
Prices and versionsCombining data scale, deployment method, retention cycle, and team requirements assessment version and billing method.
FAQ
It is recommended to start from core business chains and high-frequency fault scenarios, such as login, ordering, payment, core APIs, Kubernetes clusters, and databases, followed by unified processes for collection, tagging, alerting, and troubleshooting.
Not necessarily. Most enterprises can retain existing collection and local tools like Prometheus, ELK, SkyWalking, and OpenTelemetry, then unify context, permissions, alert closed loops, and long-term governance through observability platforms.
A common failure is only accessing data without unified tags, object relationships, or response processes, which means teams still need to manually piece evidence across tools, making it impossible to truly reduce fault localization and collaboration costs.
Building a unified monitoring platform is usually the first step, used to centralize metrics, logs, links, and alerts; The construction of the observable platform still needs to continue supplementing object relationships, exploring and analyzing, business impact, team collaboration, and reviewing closed loops.
Effectiveness can be measured through MTTR, alert noise, repeat failure rate, core link availability, release rollback count, log storage costs, cross-team collaboration time, and SLO achievement.
