Platform metrics reference

This page expands on the node_exporter and process_exporter sections of Exporters with Platform-specific PromQL expressions, alert thresholds, and troubleshooting guidance for CPU, memory, and disk usage at both the system/container level and the individual process level.

System or container CPU usage

CPU utilization across Platform nodes or containers, normalized to a percentage. High usage can come from resource-intensive processes, inefficient application code, a CPU-bound workload, context switching overhead, or another process competing for the same CPU. Sustained high CPU causes increased response latency, request queuing, thread pool starvation, and degraded throughput, and can cascade to dependent services.

PromQL:

# System-level
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
# Container-level
sum by (container, pod, namespace) (rate(container_cpu_usage_seconds_total[5m])) * 100

Identify the top CPU consumers with process-level metrics, analyze thread dumps for blocked or spinning threads, check for CPU throttling in containerized environments, and evaluate whether autoscaling policy adjustments or vertical scaling are the right response.

System or container memory usage

Memory utilization across Platform nodes or containers, as a percentage of available memory. High usage can indicate a memory leak, an inefficient data structure, an undersized heap, or general cache bloat. Sustained high memory increases garbage collection frequency and pause times, and can lead to out-of-memory errors, container eviction in Kubernetes, or swap usage that degrades performance dramatically.

PromQL:

# System-level
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100
# Container-level
(sum by (container, pod, namespace) (container_memory_working_set_bytes) /
 sum by (container, pod, namespace) (container_spec_memory_limit_bytes)) * 100

Analyze heap dumps for a memory leak, review garbage collection logs, tune runtime memory parameters (heap size, GC algorithm), and confirm the configured memory limit is appropriate for the workload before scaling vertically.

System or container disk usage

Disk space utilization across Platform nodes or containers. High usage typically comes from uncontrolled log growth, database bloat, a missing log rotation policy, or backup retention that’s grown beyond plan. Sustained high disk usage can crash an application unable to write data, break logging (an observability gap right when you need it most), and fail deployments that need disk space for new artifacts.

PromQL:

# System-level
(1 - (node_filesystem_avail_bytes{fstype!~"tmpfs|fuse.lxcfs|squashfs|vfat"} /
      node_filesystem_size_bytes{fstype!~"tmpfs|fuse.lxcfs|squashfs|vfat"})) * 100
# Container-level (ephemeral storage)
(sum by (pod, namespace) (container_fs_usage_bytes) /
 sum by (pod, namespace) (container_fs_limit_bytes)) * 100

Identify large files and directories, fix or implement log rotation, clean up old logs and temporary files, and archive or delete old backups ahead of expanding the volume.

Per-node process CPU usage

CPU utilization of an individual process on a node, normalized relative to total system CPU capacity. This is what distinguishes “the host is under load” from “this specific process is the reason.” High process-level CPU can come from an inefficient algorithm, a tight loop without a sleep or yield, thread contention or lock spinning, or a bug causing an infinite loop.

PromQL:

# Requires process-exporter or similar
rate(namedprocess_namegroup_cpu_seconds_total[5m]) * 100
# Alternative using node_exporter's process collector
sum by (instance, comm) (rate(node_processes_cpu_seconds_total[5m])) * 100

Profile the specific process to find hot code paths, review recent code changes, and check for debug logging left enabled in production before deciding between a restart, a code fix, or scaling out.

Per-node process memory usage

Memory consumption of an individual process, in bytes or as a percentage of allocated memory. High or steadily growing process memory can indicate a memory leak, unbounded cache growth, a retained reference chain preventing garbage collection, or connection pool bloat.

PromQL:

# Requires process-exporter or similar
namedprocess_namegroup_memory_bytes{memtype="resident"}
# As a percentage of system memory
(namedprocess_namegroup_memory_bytes{memtype="resident"} /
 node_memory_MemTotal_bytes) * 100

Analyze the process’s heap and memory maps for a leak, review object retention and reference chains, check for unclosed resources or connection leaks, and set appropriate memory requests and limits in Kubernetes so a single process can’t starve its neighbors.