Kubernetes Monitoring

Kubernetes monitoring for every cluster, workload, and release

Correlate cluster health, nodes, pods, workloads, services, events, logs, and traces in one operational context. Start with a restart, scheduling failure, latency spike, or failed rollout, then determine whether the cause is capacity, configuration, code, or a dependency.

Get started 获取你的专属技术栈监控方案

Why Kubernetes troubleshooting needs shared operational context

01Objects change continuously

Pods, nodes, services, and workloads are short-lived, so discovery and relationships must stay current.

02Resource and application health interact

CPU, memory, restarts, scheduling, latency, and errors need to be read together.

03Every release changes risk

Rollouts, scaling, and configuration changes should be compared with errors, latency, and user impact.

04Multi-cluster ownership is complex

Shared tags, access controls, dashboards, and alert rules keep teams aligned across clusters and namespaces.

Kubernetes troubleshooting

Move from a production symptom to the responsible object and cause

Begin with a real service signal, narrow the affected cluster, workload, pod, service, and version, then validate the explanation with metrics, Kubernetes events, logs, traces, and release changes.

  1. 01

    Confirm business impact

    Use latency, errors, alerts, and real user signals to establish scope and priority.

  2. 02

    Narrow the runtime objects

    Filter by cluster, namespace, workload, pod, node, environment, and version.

  3. 03

    Correlate the evidence

    Align resource pressure, Kubernetes events, container logs, traces, and releases on one timeline.

  4. 04

    Verify recovery

    Compare errors, latency, resources, and alert state before and after the change.

Follow object relationships before guessing the failing layer

Continuously map clusters, nodes, namespaces, workloads, pods, containers, services, ingress resources, and events. Move from an unhealthy pod to its workload, node, and service, or start with a service error and identify the affected instances without manually joining several control planes.
获取你的专属技术栈监控方案
Follow object relationships before guessing the failing layer
Determine whether resource pressure is affecting the service

Determine whether resource pressure is affecting the service

CPU, memory, disk, network, requests and limits, pod restarts, and scheduling failures are signals, not conclusions. Compare them with request latency, errors, throughput, queues, and business metrics to separate real capacity constraints from configuration issues or short-lived noise.
获取你的专属技术栈监控方案

Align releases, traces, and logs on the same timeline

Carry deployment, version, service, and pod attributes across release events, service topology, distributed traces, and container logs. This makes it easier to determine whether a regression came from a new version, an upstream dependency, a database call, or resource contention.
获取你的专属技术栈监控方案
Align releases, traces, and logs on the same timeline
Operate multiple clusters with consistent context and ownership

Operate multiple clusters with consistent context and ownership

Organise telemetry by cluster, environment, namespace, team, and service while keeping access and alert ownership explicit. Platform, development, and SRE teams can work from the same evidence without losing their operational boundaries.
获取你的专属技术栈监控方案

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 monitoringInspect pods, containers, workloads, requests and limits, and Kubernetes events. Application Performance MonitoringTrace service errors and slow endpoints through dependencies and code paths. Log monitoring and analyticsSearch container and application logs by service, pod, version, and trace ID. Infrastructure monitoringConnect nodes to hosts, networks, databases, and cloud resources.

Already using Prometheus and Grafana? Plan a gradual migration that preserves your collection assets

Extend your cloud-native monitoring stack

OpenTelemetry observability

OpenTelemetry observability

 AWS monitoring

AWS monitoring

 Alibaba Cloud monitoring

Alibaba Cloud monitoring

 Azure monitoring

Azure monitoring

 Huawei Cloud monitoring

Huawei Cloud monitoring

Frequently Asked Questions

What should Kubernetes monitoring cover?

Production coverage normally includes clusters, nodes, namespaces, deployments, daemon sets, services, pods, containers, networks, storage, Kubernetes events, logs, and application traces.

How do I troubleshoot pod restarts or a slow service?

Start with the affected pod or service, then compare node and pod resources, Kubernetes events, container logs, and distributed traces. This separates capacity pressure and scheduling failures from dependency or code issues.

Can Guance monitor multiple Kubernetes clusters?

Yes. Teams can use common tags, workspaces, permissions, dashboards, and alert policies to analyse multiple clusters while preserving environment and ownership boundaries.

How is Kubernetes monitoring different from container monitoring?

Container monitoring focuses on container and workload health. Kubernetes monitoring also models clusters, nodes, services, scheduling, events, networking, and application relationships. Production troubleshooting usually needs both views in one context.

Can I keep Prometheus and Grafana while adopting Guance?

Yes. You can retain existing collectors and dashboards while bringing Kubernetes metrics together with logs, traces, RUM, alert events, and business telemetry. Migration can be staged around the workflows that need shared context first.

Bring your cluster scale, failure scenarios, and current toolchain to plan a practical Kubernetes monitoring path

获取你的专属技术栈监控方案

Next steps

Get started > View documentation > View pricing >