Linux怎么安装Prometheus监控 Linux时序数据库部署详解

很多刚接触Prometheus的朋友，可能下意识地会去搜索“如何安装”。但实际上，Prometheus的设计哲学决定了它并不需要传统意义上的“安装”。它本质上是一个独立的二进制文件，部署的核心动作就是解压、配置、然后运行。所谓“部署”，其实就是配置好那个关键的 prometheus.yml 文件，并确保这个进程能够稳定、持久地运行起来。

快速验证：先跑起来再说

在折腾systemd服务或者调整文件权限之前，有个更高效的做法：用最简化的方式，先确认Prometheus的核心功能是否正常。这能帮你快速定位问题，避免在错误的方向上浪费时间。

• 获取软件包：直接下载对应架构的最新版本，例如使用命令 wget https://github.com/prometheus/prometheus/releases/download/v2.47.2/prometheus-2.47.2.linux-amd64.tar.gz。
• 解压并进入目录：执行 tar -xzf prometheus-*.tar.gz && cd prometheus-*/。
• 直接启动：解压后的目录里已经包含了一个默认的 prometheus.yml 配置文件，它自带了对自身的监控示例。直接在前台启动它：./prometheus --config.file=prometheus.yml --web.listen-address=":9090"。
• 关键验证点：打开浏览器，访问 http://<你的服务器IP>:9090，然后导航到 Status → Targets 页面。如果看到状态显示为 UP，那就恭喜你，Prometheus已经成功启动并开始采集数据了。

如果这一步就卡住了，别慌，90%的原因逃不出这几点：端口被占用（可以用 netstat -tunlp | grep :9090 检查）、配置文件缩进错误（YAML语法对空格非常敏感）、或者当前用户没有读取配置文件的权限。

Systemd服务报“Permission Denied”的真相

很多人喜欢用systemd来管理Prometheus服务，但经常会遇到启动失败，报权限错误。这通常是因为文件路径和系统服务用户不匹配造成的。

一个典型的踩坑场景是：你把Prometheus的二进制文件和配置文件放在了 /root/ 目录或者某个普通用户的家目录下，但在systemd的服务单元文件里，却指定了以非root用户（比如专门创建的 prometheus 用户）来运行。这个用户自然没有权限去访问root的家目录。

• 统一路径：必须将所有运行所需的文件（二进制文件、配置文件、数据目录）都放在系统级的公共路径下，例如 /usr/local/prometheus/。
• 权限归属：使用 chown -R prometheus:prometheus /usr/local/prometheus 命令，将整个目录的所有权赋予给 prometheus 用户和组。
• 检查服务文件：仔细核对systemd服务文件中的 ExecStart= 指令，这里必须填写二进制文件的绝对路径，比如 /usr/local/prometheus/prometheus，而不能只写一个 prometheus。
• 注意数据目录：如果你通过 --storage.tsdb.path 参数指定了自定义的数据存储路径，那么这个路径的权限也必须属于 prometheus 用户，否则服务会在首次尝试写入TSDB时失败并静默退出，排查起来很麻烦。

Targets配置：为什么写localhost:9100却抓不到数据？

这是新手配置监控目标时最高频的“坑”。关键在于理解：scrape_configs 里的 targets 地址，是从Prometheus服务器自身的视角去解析的。

举个例子：你在A机器上部署了Prometheus，想要监控B机器上的 node_exporter。如果你在配置里写了 targets: ['localhost:9100']，那么Prometheus会试图去连接它自己（A机器）的9100端口，而不是B机器的。这当然会失败。

• 正确写法：填写目标机器的真实IP地址或可解析的主机名，例如 targets: ['192.168.1.26:9100']。
• 网络连通性：确保目标机器的防火墙已经放行了9100端口（例如使用 ufw allow 9100 或 firewall-cmd 相关命令）。
• 两步排查法：
  1. 在目标机器上执行 curl http://localhost:9100/metrics，确认 node_exporter 本身工作正常，能返回指标文本。
  2. 在Prometheus服务器上执行 curl http://192.168.1.26:9100/metrics，确认从监控端到被监控端的网络是通的。如果这一步不通，那就不是Prometheus配置问题，而是网络或目标服务本身的问题。
• 采集间隔：注意 scrape_interval 默认是1分钟，修改这个值后，需要重启Prometheus才能生效。

控制数据增长：TSDB目录膨胀太快怎么办？

Prometheus默认会永久保存所有时序数据，这对于生产环境来说显然是不现实的，磁盘被撑爆只是时间问题。控制数据保留期的关键，并不在主配置文件 prometheus.yml 里，而是在启动参数中。

• 核心参数：通过添加启动参数 --storage.tsdb.retention.time=30d 来设置数据保留时间（支持 d（天）、w（周）、y（年）单位）。这是最常用也最推荐的方式。
• 避坑提示：不要使用已被废弃的参数，例如 --storage.local.retention（在v2.0及以上版本中已移除）。
• 关于WAL：如果启用了WAL（预写日志），其大小主要由内存和写入压力决定，没有直接的配置上限。但只要上面提到的 retention.time 设置合理，过期的WAL文件会在后续的压缩清理过程中被自动移除。
• 版本差异：执行 prometheus --version 确认你的版本。不同大版本的行为可能有细微差别，例如从v3.x开始，引入了 --storage.tsdb.retention.size 参数来直接限制磁盘使用量。

还有一个容易产生的误解：设置的数据保留时间到期后，Prometheus不会立即删除数据。它会等待下一个压缩周期（默认约2小时）才进行清理。所以，如果你刚设置完保留时间，发现磁盘空间没有立刻释放，请不要怀疑是配置没生效，给它一点处理时间。