---
title: Host Metrics
slug: telemetry-pipeline/host-metrics
docTags: 
createdAt: 2025-04-21T00:46:12.231Z
---

## Host Metrics Source

Collect metric data directly from the local system.

The Host Metrics source allows worker to run as a lightweight system agent, periodically collecting resource utilization metrics from the host operating system. It is designed for node-level observability and infrastructure monitoring.

This source is optimized for continuous, low-overhead metric collection on individual hosts.

## Collection Model

Worker inspects native operating system interfaces to gather metrics describing system resource usage, including:

- CPU utilization 
- Memory consumption 
- Disk I/O and usage 
- Filesystem capacity 
- Network throughput 
- Load averages 
- Process-level metrics 
- cgroups (Linux only) 
- TCP connection statistics 

Metrics are emitted at a configurable scrape interval and forwarded in batches to downstream sinks.

## Operating Environment

### Host-Based Execution

- Designed to run directly on virtual machines, bare-metal servers, or nodes 
- Commonly deployed as: 
  - A system service 
  - A container with host access 
  - A DaemonSet in Kubernetes environments 

### Stateless Behavior

- No local state is persisted 
- Each scrape cycle is independent 
- Suitable for ephemeral and autoscaled environments 

## Linux cgroups Support

On Linux systems, Host Metrics can collect resource usage from control groups (cgroups):

- Supports **cgroups v2** and **hybrid** configurations 
- Enables visibility into: 
  - Container-level CPU usage 
  - Memory limits and consumption 
  - Resource isolation behavior 

This is particularly valuable in containerized and multi-tenant environments.

## Kubernetes Considerations

When running under Kubernetes, certain virtual filesystems may cause filesystem metric collection errors due to symbolic link recursion.

Typical symptoms include failures when inspecting paths under /proc.

To mitigate this:

- Specific devices, filesystems, or mount points can be excluded from collection 
- This exclusion is enabled by default in the official Worker Helm chart 

These safeguards prevent unnecessary errors while maintaining accurate host-level metrics.

## Metric Namespacing

- All emitted metrics share a configurable namespace 
- Defaults to a host prefix 
- Helps distinguish host-level metrics from: 
  - Application metrics 
  - Container metrics 
  - Platform-specific telemetry 

## Collector Architecture

Host Metrics is composed of independent collectors, each responsible for a specific subsystem:

- CPU 
- Memory 
- Disk 
- Filesystem 
- Network 
- Load 
- Processes 
- cgroups 
- TCP 

Collectors can be selectively enabled or disabled to:

- Reduce overhead 
- Limit metric cardinality 
- Focus on relevant subsystems 

## Filtering and Scope Control

Fine-grained filtering is supported across multiple dimensions:

- Disk devices 
- Network interfaces 
- Filesystems 
- Mount points 
- Process names 
- cgroup hierarchies 

Pattern-based inclusion and exclusion allow precise control in complex environments with high resource churn.

## Reliability Characteristics

- Periodic, interval-based scraping 
- Batch-oriented metric delivery 
- At-least-once semantics 
- No acknowledgement tracking 
- Minimal runtime overhead 

This design makes Host Metrics suitable for continuous infrastructure monitoring without impacting application performance.

## Common Use Cases

- Node-level infrastructure monitoring 
- Capacity and utilization tracking 
- Kubernetes node observability 
- VM and bare-metal monitoring 
- Baseline metrics for alerting systems 
- Feeding metrics into: 
  - Prometheus-compatible backends 
  - Time-series databases 
  - Centralized observability platforms