Linux Prometheus 部署与指标采集

Prometheus target 显示 DOWN 的最常见原因是 scrape_config 中 target 端口错误，如将 node_exporter 的 :9100 误写为 :9090；需核对 static_configs 下 targets 端口与实际服务监听端口（node_exporter 默认 0.0.0.0:9100）是否一致。 prometheus.yml 配置文件写错端口导致 target 一直显示 down Prometheus 启动后 target 状态始终是 ，最常见原因是 里写的 地址端口不对，比如把 默认的 写成 （那是 Prometheus 自己的 Web 端口）。 能通，但 Prometheus 抓不到，基本就是配置里地址或端口拼错了。 检查 中 下的 ，确认端口和实际服务监听端口一致 默认监听 ， 是 ， 是 ——别凭印象写 如果 target 是域名或内网 DNS 名，确保 Prometheus 容器或进程能正常解析并访问该地址（宿主机网络、Docker 网络模式、k8s Service DNS 都可能影响） systemd 启动 Prometheus 报 failed to load configuration 用 systemd 管理 Prometheus 时，启动失败日志里出现 ，大概率是 有 YAML 语法错误，比如缩进不一致、用了 tab 而不是空格、漏了冒号或引号。 先手动运行 ，它会校验配置并报具体哪一行出错 YAML 对缩进极其敏感：所有 下的字段必须比上一级多两个空格， 和 必须对齐，不能一个缩进 2 个、一个缩进 4 个 路径中如果有变量（如 ），Prometheus 不支持 shell 展开，得用 relabel_configs 或外部模板工具预处理 node_exporter 没有磁盘 IO 或进程数指标 部署完 ，发现 Grafana 里看不到 或 这类指标，不是采集问题，而是默认启动没开对应收集器。 CentOS Linux 7.9.2009 CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离线兼容性测试。 下载 默认只启用基础收集器（cpu、mem、load），IO、进程、硬件传感器等需显式开启，例如： 注意 收集的是块设备 IO，不是文件系统使用率；后者靠 收集器（对应 ） 某些收集器需要额外权限：比如 收集器要读 ，在容器里得挂载 目录； 收集器依赖 参数指定路径 Prometheus 内存暴涨、查询变慢甚至 OOM 跑几天后 Prometheus 进程 RSS 内存持续上涨，Web 页面响应卡顿， 超时，通常不是 bug，而是时间序列数量失控或保留策略没设好。 检查 数据量： ，如果单日增长超 1GB，大概率有高基数标签（比如带用户 ID、请求 URL 全路径的 metric） 限制采集频率：高频抓取（ ）+ 大量 targets 容易撑爆内存，生产环境建议 ， 通常 就够 务必配 （如 ），否则数据无限堆积；同时确认磁盘有足够空间，TSDB 压缩失败也会导致内存缓存积压 指标基数、label 组合爆炸、retention 和 scrape_interval 的搭配，这几个地方一松动，Prometheus 就容易从监控工具变成被监控对象。