Node Exporter Down - Troubleshooting Guide
Purpose
This document provides a standardized approach for handling and troubleshooting the Node Exporter Down alert, including L1 and L2 actions, escalation flow, and resolution criteria.
Alert Name
Node Exporter Down
Alert Description
This alert is triggered when the Node Exporter service is not responding.
Node Exporter is a system-level monitoring agent used with Prometheus to collect OS and hardware metrics from a Linux server (node).
Severity
P2 – High Impact
Possible Causes
- Node is down or unreachable (network issue)
- Node Exporter service crashed or stopped
- High system load or resource exhaustion
- Firewall or port blocking issues
- Prometheus scraping failure
L1 Engineer Actions
Step 1 – Log the Alert
- Review alert details:
- Timestamp
- Node name
- Alert source
Step 2 – Create Ticket
- Monitor the alert for 20 minutes to check auto-resolution
- If issue persists:
- Create an internal ticket
- Include all alert details
Step 3 – Escalation (If Required)
- Inform L2 Engineer after 20 minutes if unresolved
- Share all relevant details
Step 4 – Documentation
After confirmation with L2, update the Issues Master Sheet/ Issues Tracker Sheet.
L2 Engineer Actions
Step 1 – Check Node Reachability
ping <node_ip>
ssh <user>@<node_ip>
- Verify node is reachable over network.
- Confirm SSH access
Step 2 – Check Node Exporter Service Status
systemctl status node_exporter
- Verify if service is running
Step 3 – Restart Node Exporter Service
systemctl restart node_exporter
Step 4 – Verify Service Status
systemctl status node_exporter
- Ensure service is active
Step 5 – Check Port Accessibility (Default: 9100)
netstat -tulnp | grep 9100
- Confirm port is listening
- Check Prometheus: Verify target status (UP/DOWN)
- Check Grafana: Look for missing metrics
Step 7 – Verify System Health
top
df -h
free -m
- Check CPU, Memory, and Disk usage
Step 8 – Log Analysis & Escalation
journalctl -u node_exporter
- Investigate logs for errors.
- If issue persists:
- Inform customer / create external ticket
Step 9 – Reboot Node (If Required)
reboot
- Perform only if:
- Node is unresponsive
- Service repeatedly fails
Resolution
The issue is considered resolved when:
- Node is reachable
- Node Exporter service is running
- Metrics are visible in Prometheus/Grafana
- Alert is cleared
Escalation
L1 → L2: If not resolved within 20 minutes
L2 → OEM: If infrastructure issue persists
Related Articles
Network Down Extern (P1 Critical Alert) - Troubleshooting Guide
Purpose This document provides a standardized approach for handling and troubleshooting the Network Down - Extern alert, including L1 and L2 actions, escalation procedures, and resolution criteria for critical incidents. Alert Name Network Down - ...
ZFS Pool Capacity Critical Alert - Troubleshooting Guide
Purpose This document provides a standardized approach for handling and troubleshooting the ZFS Pool Capacity Critical alert, enabling rapid response to prevent storage exhaustion, performance degradation, and potential service outages. Alert Name ...
ZFS Pool Capacity Warning Alert - Troubleshooting Guide
Purpose This document provides a standardized approach for handling and troubleshooting the ZFS Pool Capacity Warning alert, helping L1 and L2 engineers prevent storage exhaustion and maintain system stability. Alert Name ZFS Pool Capacity Warning ...
Fan Speed Critical - Troubleshooting Guide
Purpose Provide a troubleshooting guide for engineers when a Fan Speed Critical alert is generated on a server node. This article helps engineers quickly identify cooling issues and perform corrective actions to prevent overheating and potential ...
Filesystem Capacity Critical in Head Node - Troubleshooting guide
Purpose Provide a standard troubleshooting and resolution procedure when filesystem capacity on a Head Node reaches critical levels. When to Use Use this KB when the monitoring system triggers the alert: Filesystem Capacity Critical – Head Node This ...