Kubernetes Observability

Kubernetes monitoring solutions

Put clusters, nodes, pods, containers, workloads, services, events, logs, and application links into the same operational context. Determine whether the problem comes from resources, configuration, code, or dependencies based on reboots, scheduling failures, interface slowdowns, or release exceptions.

Get started Request a demo

Why does K8s monitoring require unified observability context?

01Object relationships change dynamically

Pods, nodes, services, and workloads frequently change, requiring automatic discovery and continuous contextual association.

02Resources and applications influence each other

CPU, memory, reboot, scheduling, and interface time need to be reviewed together to determine which layer the problem is at which level.

03Release risks need to be visible

After deployment, scaling, and configuration changes, it is necessary to promptly monitor error rates, latency, and user impact.

04Multi-cluster governance is complex

Multi-cluster, multi-namespace, and multi-team collaboration require unified tags, permissions, and alert calibers.

Kubernetes Troubleshooting

From a single anomaly to the root cause, we traced the same chain of evidence

The team doesn't need to guess at which floor the problem is at first. Using real fault signals as the entry point, gradually narrowing the cluster, workload, services, and version ranges, then using metrics, events, logs, and traces for mutual verification.

  1. 01

    Confirm the impact of the business

    Determine the scope of impact and processing priority based on interface latency, error rates, alerts, or changes in user experience.

  2. 02

    Lock the running object

    Shrink exception objects by cluster, namespace, workload, Pod, Node, and version.

  3. 03

    Evidence from the related scene

    Align resource levels, Kubernetes events, container logs, traces, and release changes on the same timeline.

  4. 04

    Verify the recovery results

    By comparing errors, delays, resources, and alarm states before and after changes, we confirm recovery rather than temporarily hide symptoms.

First, look at the relationship between objects, not guess the level of failure

Guance continuously collect data from Kubernetes clusters, nodes, namespaces, workloads, pods, containers, Service, Ingress, and events, and maintain the relationships between them. Teams can continue to view workloads, nodes, and services from an exception Pod, or reverse locate affected instances from service errors, avoiding manually stitching objects and times across multiple consoles.
Request a demo
First, look at the relationship between objects, not guess the level of failure
After the resource alert, continue to assess whether it affects the service

After the resource alert, continue to assess whether it affects the service

CPU, memory, disk, network, resource requests and limits, Pod reboot, and scheduling failures are just warning signs. Guance place resource levels in the same window as interface latency, error rate, throughput, queue, and business metrics, helping platforms and SRE teams distinguish between real capacity bottlenecks, unreasonable configurations, and short-term fluctuations, reducing resource waste caused by scaling based solely on thresholds.
Request a demo

Align release changes, traces, and logs on the same timeline

After release, scaling, or configuration changes, interface slowdowns, error rates increase, and Pod anomalies often occur simultaneously. Guance integrate tags such as deployment, version, service, and pod across deployment events, service topology, APM traces, and container logs, helping the R&D team determine whether issues are triggered by new versions, upstream dependencies, database calls, or resource contention, while preserving verifiable on-site evidence.
Request a demo
Align release changes, traces, and logs on the same timeline
Multi-cluster governance is more than just a big dashboard

Multi-cluster governance is more than just a big dashboard

Multi-cluster environments require unified object naming, labels, permissions, dashboards, and alert calibers, and teams must also be allowed to drill down along business boundaries. Guance supports organizing data by cluster, environment, namespace, team, and service, allowing platforms, R&D, and SRE teams to share the same evidence while controlling their respective data access scopes and alert responsibilities.
Request a demo

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.

Container monitoringView Pods, containers, workloads, resource requests and limits, and Kubernetes events. APM Application Performance MonitoringContinue to dive down from service errors and slow interfaces to traces, dependencies, and code methods. log monitoring and log analysisSearch container and application logs by service, pod, version, and trace_id. Infrastructure MonitoringAssociate the operational status of nodes, hosts, networks, databases, and cloud resources.

Already have Prometheus / Grafana? See the gradual migration guide for retaining existing gathering assets

Continue to improve the cloud-native technology stack

OpenTelemetry access

OpenTelemetry access

 AWS monitoring

AWS monitoring

 Alibaba Cloud Monitoring

Alibaba Cloud Monitoring

 Azure Monitoring

Azure Monitoring

 Huawei Cloud Monitoring

Huawei Cloud Monitoring

Frequently Asked Questions

Which objects does Kubernetes monitoring need to cover?

Typically, it is necessary to cover clusters, Node nodes, namespaces, Deployment, DaemonSet, Service, Pod, containers, networks, storage, events, logs, and application links.

How do you locate Pod reboots or service slowdowns?

You can drill down layer by layer from Pods, nodes, resource levels, events, logs, and traces to determine whether the problem comes from resource shortages, scheduling anomalies, dependency errors, or code performance.

Can multi-cluster environments be monitored uniformly?

Yes, you can. Guance manage multiple Kubernetes clusters on the same platform by unifying tags, spaces, permissions, dashboards, and alert policies.

What is the difference between Kubernetes monitoring and container monitoring?

Container monitoring focuses more on the container and the workload itself; Kubernetes monitoring also requires understanding the relationships between clusters, nodes, services, schedules, events, networks, and applications. Production troubleshooting usually requires placing both in the same context.

Can Prometheus and Grafana still connect to Guance?

Yes, you can. Teams can retain their existing data collection and dashboard capabilities, then integrate Kubernetes metrics with logs, traces, RUM, alert events, and business data into a unified observability system, gradually reducing contextual fragmentation between tools.

Bring your cluster size, failure scenarios, and existing tools to plan your Kubernetes monitoring path together

Request a demo

Next steps

Get started > View documentation > View pricing >