node_exporter主机指标导出默认9100端口【免费下载链接】node_exporterExporter for machine metrics项目地址: https://gitcode.com/GitHub_Trending/no/node_exporter主机指标散落在 /proc 与 /sys 的数十种格式中手写采集脚本难以维护一次抓取若被挂死的 NFS 挂载点拖住监控链路整体超时。node_exporter 是 Prometheus 体系的主机指标导出器单个 Go 进程把 CPU、内存、磁盘、网络指标收敛到默认 9100 端口的 /metrics 接口内置 51 个默认启用的 collector默认限制 40 个并发抓取--web.max-requests40。拆解 collector 并发采集机制把单点故障隔离在单次抓取内一次抓取从 HTTP 请求开始node_exporter.go中的 handler 先判断是否带collect[]/exclude[]过滤参数无过滤时直接复用启动时预构建的 handler有过滤时按参数临时构建只含指定 collector 的 handler。随后请求进入collector/collector.go的NodeCollector.Collect它给每个已启用 collector 起一个 goroutine 并行执行Update用 WaitGroup 汇总func (n NodeCollector) Collect(ch chan- prometheus.Metric) { wg : sync.WaitGroup{} wg.Add(len(n.Collectors)) for name, c : range n.Collectors { go func(name string, c Collector) { execute(name, c, ch, n.logger) wg.Done() }(name, c) } wg.Wait() }这段代码定义了并发边界collector 之间互不等待最慢的那个决定整次抓取时长。关键在execute的收尾——它给每个 collector 单独输出node_scrape_collector_duration_seconds和node_scrape_collector_success两条指标。于是某个 collector 因权限或内核缺失返回错误时其余数据照常返回故障只体现在该 collector 的 success0 上而不是整次抓取报错。这就是部分成功优于整体失败的取舍代价是响应拼装时间取决于最慢 collector收益是任一子系统异常都不会让主机监控整体失明。配置 node_exporter 的 filesystem 与 textfile 参数控制采集开销collector/filesystem_linux.go里有两个隐藏参数直接影响采集耗时var mountTimeout kingpin.Flag(collector.filesystem.mount-timeout, how long to wait for a mount to respond before marking it as stale). Hidden().Default(5s).Duration() var statWorkerCount kingpin.Flag(collector.filesystem.stat-workers, how many stat calls to process simultaneously). Hidden().Default(4).Int()它们定义了挂载点探测的两个上限单个无响应挂载点默认最多等 5s 后被标记 stalestatfs 调用默认走 4 条并行通道。建议一NFS 较多的主机把--collector.filesystem.mount-timeout从 5s 调至 3s挂死挂载点占用的采集窗口从约 5 秒缩到约 3 秒代价是慢挂载误判为 stale 的阈值同步降低。建议二挂载点超过 100 的主机把--collector.filesystem.stat-workers从 4 调至 8statfs 并行通道翻倍探测阶段的串行等待按通道数摊薄默认排除正则已过滤 dev/proc/sys 等挂载调整前先看日志确认实际探测量。外部指标走--collector.textfile.directory指向一个目录后collector/textfile.go每次抓取解析其中全部*.prom文件cron 任务用mv原子写入即可在下次抓取生效单文件解析失败只把node_textfile_scrape_error置 1不影响其余文件。容器化部署时挂载宿主根目录采集到主机而非容器的指标问题把 node_exporter 装进容器却不加参数时它读到的是容器自己的 /proc 与 /sys指标反映的是容器而非宿主机。方案按 README.md 的 Docker 部署说明把宿主根目录只读挂进容器并指定路径前缀docker run -d --nethost --pidhost -v /:/host:ro,rslave quay.io/prometheus/node-exporter:latest --path.rootfs/host。collector/paths.go中path.rootfs默认是/设为/host后所有文件系统读取经rootfsFilePath重定向到宿主路径--nethost与--pidhost则让网络与进程指标落在宿主命名空间。结果容器保持可销毁、可替换的运维优势而 CPU、磁盘、网络指标全部来自主机与裸机部署examples/systemd/node_exporter.service的服务化形态采集口径一致。采集项⚠️ 不加参数的容器部署✅ README 推荐配置关键差异文件系统读容器自身 /proc--path.rootfs/host指标来自主机进程数容器 PID 命名空间--pidhost统计宿主进程网卡流量容器网络栈--nethost采集宿主网卡梳理 node_exporter 的上下游依赖与废弃路线评估落地成本依赖面很小go.mod显示核心依赖为prometheus/client_golang、prometheus/procfs与exporter-toolkit三个 Prometheus 系库外加各操作系统的 netlink/kstat 等系统接口封装。下游就是 Prometheus 服务端按抓取配置拉取 9100 端点README 同时划出边界Windows 用 windows_exporterNVIDIA GPU 用 dcgm-exporternode_exporter 不覆盖这两块。演进方向上维护者已把 ntp、runit、supervisord 三个 collector 标记为废弃下一主版本移除TLS 端点--web.config.file仍标注 EXPERIMENTALwhitelist/blacklist 旧旗标将在 2.0.0 移除。对运维与平台工程师而言它的落地价值在于一个单文件二进制加一组旗标就能在 Prometheus 体系内获得标准化且可持续演进的主机指标来源。【免费下载链接】node_exporterExporter for machine metrics项目地址: https://gitcode.com/GitHub_Trending/no/node_exporter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考