Host Metrics (node_exporter)

Collect host metrics — CPU, memory, disk, filesystem, network — plus the hardware sensors: temperatures, fan speeds, CPU package power draw, and ECC memory errors, from every host in your fleet, with curated dashboards and alerts you import in one step.

Metrics are produced by Prometheus node_exporter running on each host. An OpenTelemetry Collector scrapes every host’s :9100/metrics endpoint with the Prometheus receiver and forwards OTLP to your LeanSignal agent gateway (one per cluster or environment). The gateway keeps full fidelity locally and forwards only the demanded subset to your central dataplane. Metric names pass through natively (node_cpu_seconds_total, node_hwmon_temp_celsius, …) — no OTLP renaming — so existing node_exporter knowledge and PromQL transfer directly.

Which Host Metrics integration?

LeanSignal ships two host-metrics flavors:

• Host Metrics — the OpenTelemetry hostmetrics receiver, a per-node collector with no extra exporter process. Its receiver has no hardware sensors: no temperatures, fans, power, or ECC.
• Host Metrics (node_exporter) (this page) — the same golden signals sourced from node_exporter, plus a dedicated Hardware health dashboard in the Extended variant and a host-down alert on the scrape itself. The natural choice if your fleet already runs node_exporter, or for bare metal where hardware health matters.

Import one flavor per fleet — they cover the same ground with different metric names, so running both doubles the demanded series for no extra signal.

The hardware sensors are read from /sys (hwmon, thermal zones, RAPL powercap, EDAC), which only physical machines populate — on VMs and containers the Hardware panels and alerts simply stay empty. That is expected, not a misconfiguration; the host-level panels work everywhere.

Prerequisites

• A LeanSignal agent gateway deployed and connected — one per cluster or environment. If you haven’t deployed it yet, follow Install the agent (source: LeanSignal/leansignal-agent). It should show as Connected under Agents in the LeanSignal app.
• Network reachability to the gateway’s OTLP port — 4317 (gRPC) or 4318 (HTTP). See Agent configuration.
• node_exporter running on each host you want to observe — it exposes Prometheus metrics at :9100/metrics — plus an OpenTelemetry Collector that scrapes every host and forwards OTLP to the gateway, configured in Setup.
• Editor or admin role in the LeanSignal app (importing a demand creates dashboards and alert rules).

Setup

On each host, run node_exporter (most distros package it as prometheus-node-exporter; a systemd unit or the official binary both work). No flags are needed — the collectors this integration queries (cpu, meminfo, filesystem, diskstats, netdev, and the hardware ones: hwmon, thermal_zone, rapl, edac) are enabled by default on Linux. Confirm a host is exposing metrics:

curl -s http://<host>:9100/metrics | grep -E '^node_(load1|hwmon_temp_celsius)'

Then point an OpenTelemetry Collector at every host’s :9100 endpoint and forward OTLP to your LeanSignal agent gateway (not a SaaS endpoint):

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: node    # keep this name — the "host down" alert matches on it
          scrape_interval: 15s
          static_configs:
            - targets:      # every host running node_exporter
                - host-a:9100
                - host-b:9100
                - host-c:9100

processors:
  batch: {}

exporters:
  otlp:
    endpoint: leansignal-agent:4317   # per-cluster gateway (use :4318 for HTTP)
    tls:
      insecure: true                  # in-cluster plaintext; provide ca_file for TLS

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      processors: [batch]
      exporters: [otlp]

List every host under targets (or use file_sd_configs / kubernetes_sd_configs to discover them); each scrape target becomes one value in the dashboard’s Instance filter. One collector can scrape the whole fleet — node_exporter exposes an HTTP endpoint, so nothing else runs per host.

Keep job_name: node

The Host down or unreachable alert evaluates up{job="node"} — it is the only alert that fires when a host stops reporting entirely. If you use a different job_name, edit that alert rule after importing the demand, or it will never fire.

Going further

The Hardware section covers what node_exporter reads from the kernel. For BMC-level sensors (PSU status, ambient temperature) add ipmi_exporter, and for disk SMART health (drive temperature, wear, reallocated sectors) add smartctl_exporter — scrape them with additional scrape_configs entries, then extend the imported dashboard with panels for their metrics; your edits reshape the demand automatically.

Where to run this

You have two options:

• On the LeanSignal agent gateway. It is an OpenTelemetry Collector distribution and bundles the prometheus receiver, so you can add the receivers: block above straight to its own config.
• On a separate OpenTelemetry Collector, in agent mode. Run a standalone collector close to the target with just this receiver plus an otlp exporter pointed at the gateway (leansignal-agent:4317); it forwards everything on.

Both are supported — pick whichever suits your topology. A separate collector tends to fit when the gateway has no route to the /metrics endpoint (a different network or cluster), or when you’d simply rather keep collection close to the source; running it on the gateway means one less process to operate.

Multiple instances

Prometheus scraping tags every series with an instance label (the scrape target), so instances are distinguished automatically. The imported dashboard has an Instance filter — view all instances at once or focus on one.

Logs and traces

Round out host observability with host logs: run a collector with the filelog/journald receivers next to node_exporter (or on the gateway, if it runs on the host) and forward OTLP — or repoint an existing Promtail/Alloy shipper at the gateway’s Loki push endpoint (:3500). Traces are an application concern, not a host one — instrument the workloads running on the host via the runtime integrations.

Demand-driven, like metrics

Logs and traces land in the gateway’s edge stores (a roughly one-hour full-fidelity window) and are queryable immediately in the LeanSignal app under Logs and Traces with the source set to Available. Nothing is stored centrally until a dashboard demands it — the ready-made demands on this page stay metrics-only. See Logs and Traces.

Demands

Host Metrics (node_exporter) ships as a ready-made demand in three variants. You don’t copy any JSON — in the LeanSignal app go to Demands, press the ˅ arrow on the Add Demand button (the arrow opens the import menu), choose Import from catalog…, and pick the variant. Each variant below lists the slug that identifies its published bundle. See Integrations for the full import flow.

The variants are nested — Standard is a superset of Essential, Extended a superset of Standard. Pick whichever is closest to what you need and treat it as a starting point: after import everything is a normal, editable copy, so retune thresholds, add or drop panels, and adjust queries for your environment — your edits reshape the demand automatically. Start small and re-import a larger variant later if you outgrow it.

Essential

The golden signals. 1 dashboard · 4 panels · 4 alerts — load, memory, filesystem, and network, plus a host-down alert.

Import this variant from the catalog. Its demand slug:

Demand slug

host-metrics-node-exporter-otel-demand-essential

Dashboard — Load average, Memory utilization, Filesystem utilization, and Network I/O.

Alerts (4)

Alert	Severity	Fires when
Host down or unreachable	critical	scrape up = 0 for 5m
Host load high (critical)	critical	5m load > 3× cores for 10m
Host memory usage high (critical)	critical	memory used > 90% for 5m
Host filesystem usage high (critical)	critical	any mount > 90% for 10m

Review the bundle JSON →

Standard

Well-rounded overview. 1 dashboard · 7 panels · 6 alerts — adds memory breakdown, disk I/O, and network errors, with paired warning/critical thresholds. The recommended default.

Import this variant from the catalog. Its demand slug:

Demand slug

host-metrics-node-exporter-otel-demand-standard

Dashboard — everything in Essential, plus Memory usage by state, Disk I/O, and Network errors.

Alerts (6)

Alert	Severity	Fires when
Host down or unreachable	critical	scrape up = 0 for 5m
Host load high (critical)	critical	5m load > 3× cores for 10m
Host load high (warning)	warning	5m load > 1.5× cores for 15m
Host memory usage high (critical)	critical	memory used > 90% for 5m
Host filesystem usage high (critical)	critical	any mount > 90% for 10m
Host filesystem usage high (warning)	warning	any mount > 80% for 15m

Review the bundle JSON →

Extended

Deep host + hardware visibility. 2 dashboards · 18 panels · 14 alerts — every subsystem plus a dedicated hardware dashboard — temperatures, fans, power draw, and ECC errors. For bare metal you need to diagnose, not just watch.

Import this variant from the catalog. Its demand slug:

Demand slug

host-metrics-node-exporter-otel-demand-extended

Dashboards (2) — everything in Standard, plus CPU utilization, CPU by mode, Swap usage, Inode utilization, Disk operations, Disk busy time, Network dropped packets, Temperatures (°C), Fan speeds (RPM), CPU package power (W), and ECC memory errors. Panels are split across Host overview (14) and Hardware health (4).

Alerts (14)

Alert	Severity	Fires when
Host down or unreachable	critical	scrape up = 0 for 5m
Host load high (critical)	critical	5m load > 3× cores for 10m
Host load high (warning)	warning	5m load > 1.5× cores for 15m
Host memory usage high (critical)	critical	memory used > 90% for 5m
Host memory usage high (warning)	warning	memory used > 80% for 15m
Host filesystem usage high (critical)	critical	any mount > 90% for 10m
Host filesystem usage high (warning)	warning	any mount > 80% for 15m
Host filesystem inodes high	warning	inodes > 85% for 15m
Host swap usage high	warning	swap used > 50% for 15m
Host network errors high	warning	error rate > 10/s for 5m
Host temperature high (warning)	warning	any sensor > 85°C for 15m
Host temperature high (critical)	critical	any sensor > 95°C for 5m
Host ECC memory errors (correctable)	warning	any corrected errors in 1h
Host ECC memory errors (uncorrectable)	critical	any uncorrected errors in 1h

Review the bundle JSON →

Dashboards

Each variant imports its panels grouped into collapsible sections; in the larger variants they split into separate dashboards (Host overview and Hardware health) so each answers one set of questions. Every dashboard carries an Instance filter (on the instance label), so one import covers the whole fleet — view every instance at once, or focus on one. Legends are sortable tables showing last/mean/max per series, so the outlier instance stands out. Dashboards are demand-driven: importing one tells your agents to forward exactly the timeseries its panels query, and nothing else. Panels are ordinary Perses panels — edit queries, add panels, or retune them after import, and your changes reshape the demand automatically.

Alerts

Thresholds are conservative starting points — tune them to your workload.

Caution

Imported alert rules arrive without a notification channel and start out paused — with nowhere to deliver, they do not evaluate. After importing, create or pick a channel under Alerts → Manage Channels, attach it to each rule, and resume. Rules without a channel are marked with a warning icon in the alerts list.

Next steps

• Demand-driven observability — why importing a demand also shapes what your agents collect.
• Agent configuration — the full agent config surface.