node_exporter
by
prometheus

Description: Exporter for machine metrics

View on GitHub ↗

Summary Information

Updated 43 minutes ago
Added to GitGenius on April 7th, 2021
Created on April 18th, 2013
Open Issues & Pull Requests: 311 (+0)
Number of forks: 2,675
Total Stargazers: 13,598 (+0)
Total Subscribers: 171 (+0)

Issue Activity (beta)

Open issues: 92
New in 7 days: 0
Closed in 7 days: 1
Avg open age: 713 days
Stale 30+ days: 87
Stale 90+ days: 74

Recent activity

Opened in 7 days: 0
Closed in 7 days: 1
Comments in 7 days: 3
Events in 7 days: 10

Top labels

  • accepted (36)
  • enhancement (24)
  • bug (16)
  • help wanted (15)
  • platform/Linux (13)
  • good first issue (8)
  • require/feedback (3)
  • collector/systemd (1)

Most active issues this week

Repository Insights (GitGenius)

Median issue/PR response: 23.7 hours
Mean response time: 45.6 days
90th percentile: 67.1 days
Tracked items: 299

Most active contributors

Detailed Description

Node_exporter is a Prometheus exporter written in Go that exposes hardware and operating system metrics from Unix-like kernels through a pluggable collector architecture. It serves as the primary tool for monitoring machine-level metrics in Prometheus-based observability stacks, listening on HTTP port 9100 by default and providing granular control over which metrics are collected through command-line flags.

The project implements a comprehensive collector system with varying support across operating systems. Enabled-by-default collectors cover essential system metrics including CPU statistics, memory information, disk I/O, network interfaces, filesystem usage, and load averages, with support spanning Linux, Darwin, FreeBSD, and other Unix variants. Additional collectors disabled by default address specialized use cases such as NVIDIA GPU metrics through integration with prometheus-dcgm, NFS statistics, InfiniBand networking, and thermal monitoring. The collector framework allows fine-grained filtering through include and exclude flags for specific device types, filesystem types, and metric categories, enabling operators to control metric cardinality and collection overhead.

The repository demonstrates sustained community engagement with a median issue and pull request response latency of 22.3 hours across 298 tracked items, indicating active maintenance. The most active contributors tracked by GitGenius are SuperQ with 311 events and discordianfish with 274 events, reflecting concentrated stewardship. Enhancement requests represent the most common issue type with 24 tracked items, followed by accepted items at 36 and bug reports at 16, suggesting a project focused on feature expansion alongside stability. The codebase maintains connections to broader ecosystems through overlapping contributors with microsoft/vscode, rust-lang/rust, and microsoft/typescript repositories.

Deployment flexibility is a core design consideration. The exporter supports traditional binary installation, Ansible-based automation through the Prometheus Community role, and containerized deployment with special handling for Docker environments. Container deployment requires careful configuration using the path.rootfs argument to ensure the exporter monitors the host system rather than the container itself, with additional flags needed for accessing host namespaces and specific capabilities like SYS_TIME for timex collector functionality.

The project explicitly acknowledges platform-specific tooling needs, recommending the Windows exporter for Windows environments rather than attempting cross-platform coverage within node_exporter itself. This focused scope allows the project to maintain deep integration with Unix kernel interfaces and procfs structures while avoiding the complexity of supporting fundamentally different operating system architectures.

Node_exporter's design reflects production observability requirements through careful attention to performance implications. Disabled-by-default collectors include warnings about high cardinality metrics, extended runtime that might exceed Prometheus scrape intervals, and significant resource demands on monitored hosts. The documentation explicitly recommends testing new collectors on non-production systems first and monitoring scrape_duration_seconds and scrape_samples_post_metric_relabeling metrics to ensure collection completes within configured timeouts and maintains acceptable cardinality levels.

node_exporter
by
prometheusprometheus/node_exporter

Repository Details

Fetching additional details & charts...