Ubuntu 22.04下Prometheus+Grafana监控多台服务器的保姆级教程（含常见问题解决）

从零构建你的服务器监控中枢：Ubuntu 22.04上Prometheus与Grafana的实战部署与深度调优

最近在整理自己的开发环境，发现手头的几台云服务器和本地虚拟机状态越来越难掌握。CPU使用率是不是又偷偷跑满了？内存泄漏的进程藏在哪里？磁盘空间还剩多少？每次都要一台台SSH登录上去敲命令，效率低下不说，还容易遗漏关键告警。对于小型团队或个人开发者而言，一套轻量、开源且功能强大的监控系统，不再是大型企业的专属，而是提升运维效率、保障服务稳定的必需品。

今天，我们就来亲手搭建这样一套系统。核心是Prometheus，这个云原生时代公认的监控“事实标准”，负责数据的抓取与存储；搭配Grafana，这个数据可视化的利器，将冰冷的数据转化为直观的图表。整个部署基于Ubuntu 22.04 LTS，这是一个长期支持且稳定的发行版，非常适合作为生产环境的基础。我会带你走过从环境准备、组件安装、配置整合到仪表盘定制的完整流程，并重点剖析那些容易踩坑的环节，比如服务启动失败、网络连通性、权限问题等，让你不仅能“搭起来”，更能“用得好”。

1. 架构理解与环境规划：打好地基

在动手敲命令之前，花几分钟理解整个监控系统的运作逻辑至关重要。这能帮助你在遇到问题时，快速定位是数据采集、传输还是展示环节出了岔子。

Prometheus 采用 拉取（Pull）模型。这意味着监控服务器（Prometheus Server）会主动按照配置的时间间隔，去访问被监控目标（Targets）上暴露出的 /metrics 接口，抓取指标数据。这与许多需要代理推送数据的传统监控系统不同。它的核心组件包括：

• Prometheus Server： 主服务器，负责抓取、存储时间序列数据。
• Exporters： 出口器，安装在被监控目标上，将系统或应用的状态转换为Prometheus可读的指标格式。我们主要使用 node_exporter 来收集主机层面的指标（CPU、内存、磁盘、网络等）。
• Service Discovery： 服务发现，用于动态管理监控目标列表（本文先使用静态配置）。
• Alertmanager（可选）： 负责处理由Prometheus Server产生的告警，并进行去重、分组、路由和通知。

Grafana 则是一个跨平台的开源分析和可视化Web应用。它本身不存储数据，而是作为一个强大的“仪表盘”，从多种数据源（如Prometheus、MySQL、InfluxDB等）查询数据，并渲染成各种精美的图表。

基于这个架构，我建议你按照以下表格来规划你的环境，这会让后续的配置清晰很多：

注意：在生产环境中，请确保监控服务器与被监控节点之间的网络是互通的，并且防火墙规则允许相关端口的访问（Prometheus默认端口9090，node_exporter默认端口9100，Grafana默认端口3000）。

规划好后，请确保所有服务器都已安装Ubuntu 22.04，并拥有一个具有sudo权限的非root用户。接下来，我们将从监控服务器开始。

2. 监控服务器核心：Prometheus的安装与精细配置

首先登录到你的监控服务器（例如 monitor-server）。

2.1 安装Prometheus

Ubuntu 22.04的官方仓库中已经包含了较新版本的Prometheus，直接使用apt安装是最简单稳定的方式。

# 首先更新本地软件包索引
sudo apt update

# 安装Prometheus
sudo apt install prometheus -y

安装完成后，系统会自动创建 prometheus 用户和组，并配置一个systemd服务单元。但默认配置可能不符合我们的需求，需要检查和调整。

2.2 深入解读与配置Prometheus

Prometheus的主配置文件位于 /etc/prometheus/prometheus.yml。让我们先查看并理解它的结构：

sudo cat /etc/prometheus/prometheus.yml

你会看到一个YAML格式的配置文件。关键部分解析如下：

global:
scrape_interval: 15s # 全局抓取间隔，每15秒抓取一次指标
evaluation_interval: 15s # 规则评估间隔，每15秒评估一次告警规则

scrape_configs:
– job_name: 'prometheus' # 第一个抓取任务：监控Prometheus自身
static_configs:
– targets: ['localhost:9090'] # 目标地址

– job_name: 'node' # 第二个抓取任务：监控节点（目前只有本机）
static_configs:
– targets: ['localhost:9100']

现在，我们需要修改这个配置，将我们的被监控节点添加进去。假设我们有两台被监控节点，IP分别是 192.168.1.101 和 192.168.1.102。

使用 sudo vim /etc/prometheus/prometheus.yml 编辑文件，找到 job_name: 'node' 部分，修改 targets 列表：

– job_name: 'node'
# 如果抓取慢，可以单独为这个任务设置更短的超时时间
scrape_timeout: 10s
static_configs:
– targets:
– 'localhost:9100' # 监控服务器自身
– '192.168.1.101:9100' # 被监控节点A
– '192.168.1.102:9100' # 被监控节点B
# 可以继续在此添加更多节点

为了后续在Grafana中能更好地分组筛选，我们还可以为不同组的机器添加标签（labels）。例如，将Web服务器和数据库服务器分组：

– job_name: 'node'
static_configs:
– targets: ['192.168.1.101:9100', '192.168.1.102:9100']
labels:
group: 'web-servers' # 为这组目标添加一个标签
– targets: ['192.168.1.103:9100']
labels:
group: 'db-servers'

2.3 启动服务与排错指南

配置完成后，需要重启Prometheus服务以加载新配置，并设置开机自启。

# 重启服务
sudo systemctl restart prometheus

# 设置开机自启
sudo systemctl enable prometheus

# 检查服务状态，这是最重要的排错第一步！
sudo systemctl status prometheus

如果 status 命令显示 active (running)，恭喜你，第一步成功了。但更常见的是遇到问题。这里有几个关键排错点：

• 状态显示 failed： 首先查看详细的错误日志。sudo journalctl -u prometheus -f –lines=50

  最常见的错误是 配置文件语法错误。YAML对缩进非常敏感，务必使用空格而非Tab键。可以使用 promtool 工具检查配置：sudo promtool check config /etc/prometheus/prometheus.yml

• 服务状态 active，但Web界面无法访问： 这通常是防火墙或安全组问题。
  • 检查本地防火墙：sudo ufw status。如果启用，需要放行9090端口：sudo ufw allow 9090。
  • 如果是云服务器，请登录云控制台，检查安全组规则是否允许入站流量到9090端口。
• Prometheus无法抓取其他节点的数据： 在Prometheus的Web界面（http://<监控服务器IP>:9090）的 Status -> Targets 页面，可以看到所有配置的抓取目标状态。
  • 如果状态为 DOWN，首先确保目标节点的 node_exporter 服务已运行（下一步会装）。
  • 然后在监控服务器上测试网络连通性：telnet 192.168.1.101 9100（如未安装telnet，使用 nc -zv 192.168.1.101 9100）。如果不通，检查目标节点的防火墙是否放行了9100端口。

3. 被监控节点：部署node_exporter采集数据

现在登录到每一台需要被监控的服务器上（例如 web-server-01），执行以下步骤。

3.1 安装与启动node_exporter

同样，使用apt安装：

sudo apt update
sudo apt install prometheus-node-exporter -y

安装后，node_exporter服务会自动启动并启用开机自启。验证一下：

sudo systemctl status prometheus-node-exporter

你应该能看到服务处于活跃状态，并监听在 0.0.0.0:9100。这意味着它已经准备好向任何能访问该端口的主机提供指标数据。

3.2 安全加固与防火墙配置

出于安全考虑，我们通常不希望9100端口对公网开放。可以通过防火墙进行限制。

• 如果使用UFW（Ubuntu默认）：# 假设只允许监控服务器 192.168.1.100 访问
  sudo ufw allow from 192.168.1.100 to any port 9100
  sudo ufw reload

• 如果使用iptables：sudo iptables -A INPUT -p tcp -s 192.168.1.100 –dport 9100 -j ACCEPT
  # 记得保存规则，具体命令取决于你的系统配置

3.3 验证数据采集

在被监控节点上，你可以直接curl本地接口，看看node_exporter是否在输出指标：

curl http://localhost:9100/metrics | head -20

这会输出一大堆以 # HELP 和 # TYPE 开头的注释行，以及像 node_cpu_seconds_total{cpu="0",mode="idle"} 这样的指标行。看到这些，说明node_exporter工作正常。

回到监控服务器的Prometheus Web界面（http://<监控服务器IP>:9090），在顶部表达式输入框里，尝试输入一个简单的指标名，比如 node_memory_MemAvailable_bytes，点击 Execute，如果能在 Graph 或 Console 标签页下看到数据，就证明Prometheus已经成功从该节点抓取到了数据！

4. 数据可视化大师：Grafana的安装与仪表盘打造

数据已经抓取并存储在Prometheus中，现在是时候让它们“说话”了。我们回到监控服务器安装Grafana。

4.1 安装Grafana

Grafana并未包含在Ubuntu默认仓库中，需要添加其官方仓库。

# 安装必要的依赖以通过HTTPS添加仓库
sudo apt install -y software-properties-common wget apt-transport-https

# 导入Grafana的GPG密钥
sudo wget -q -O – https://packages.grafana.com/gpg.key | sudo apt-key add –

# 添加稳定版仓库
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list

# 更新并安装Grafana
sudo apt update
sudo apt install grafana -y

4.2 启动并访问Grafana

启动服务并设置开机自启：

sudo systemctl start grafana-server
sudo systemctl enable grafana-server
sudo systemctl status grafana-server # 确认状态

现在，打开浏览器，访问 http://<监控服务器IP>:3000。你将看到Grafana的登录页面。默认用户名和密码都是 admin。首次登录会强制要求你修改密码，请务必设置一个强密码。

4.3 连接Prometheus数据源

登录后，第一步是告诉Grafana数据在哪里。

4.4 导入炫酷的仪表盘

从头创建仪表盘很费时间，社区提供了大量优秀的模板。最流行的Linux主机监控仪表盘之一是 Node Exporter Full（ID: 1860）。

操作步骤如下：

瞬间，一个功能极其丰富、图表专业的服务器监控仪表盘就出现在你面前！它包含了CPU、内存、磁盘IO、网络流量、系统负载、进程数等几乎所有你关心的维度。

你可以根据前面在Prometheus配置中设置的 group 标签，在仪表盘顶部的变量下拉框中进行筛选，分别查看“web-servers”或“db-servers”组的数据。

4.5 仪表盘个性化与告警设置（进阶）

个性化： 你可以点击任何图表的标题，选择 Edit，进入面板编辑模式。在这里可以修改查询语句（PromQL）、调整可视化类型（如图形、仪表、表格等）、设置阈值和颜色。这是深入学习PromQL和Grafana的好机会。

告警设置： Grafana内置了强大的告警引擎。例如，你想在某个服务器的可用内存低于10%时收到通知。

5. 生产环境进阶考量与优化技巧

当你的监控系统从“能用”走向“好用”时，下面这些点值得关注。

1. 配置管理自动化：
手动编辑YAML文件和管理多个节点的exporter在服务器数量增长后会变得繁琐。考虑使用Ansible、SaltStack或Terraform等工具，将Prometheus配置、node_exporter安装和防火墙规则配置都代码化、自动化。

2. Prometheus数据持久化与保留策略：
默认情况下，Prometheus数据存储在 /var/lib/prometheus/ 下。你需要关注磁盘空间。可以在 prometheus.yml 的同级目录下创建或修改 prometheus.yml 的全局配置，或通过服务启动参数来设置数据保留时间。

# 在 prometheus.yml 的 global 部分添加
global:
scrape_interval: 15s
evaluation_interval: 15s
# 设置数据保留时间为30天
retention_time: 30d

或者，编辑systemd服务文件 /etc/systemd/system/prometheus.service.d/custom.conf（如不存在则创建）：

[Service]
ExecStart=
ExecStart=/usr/bin/prometheus –config.file=/etc/prometheus/prometheus.yml –storage.tsdb.retention.time=30d –web.console.templates=/usr/share/prometheus/consoles –web.console.libraries=/usr/share/prometheus/console_libraries

然后执行 sudo systemctl daemon-reload 和 sudo systemctl restart prometheus。

3. 监控高可用与分片：
对于更关键的环境，单一的Prometheus服务器可能成为单点故障。可以考虑：

• 联邦集群（Federation）： 设置一个中心的Prometheus，从多个下游Prometheus服务器聚合数据。
• 使用Thanos或Cortex： 这些项目为Prometheus提供了全局视图、长期存储和无缝高可用能力，但架构复杂度显著增加。

4. 探索更多Exporter：
node_exporter 只是冰山一角。Prometheus生态有海量的Exporter，几乎可以监控一切：

• mysqld_exporter / postgres_exporter： 数据库监控
• nginx-vts-exporter / haproxy_exporter： Web服务/代理监控
• blackbox_exporter： 网络探测（HTTP、TCP、ICMP等），用于监控服务外部可用性。
• cadvisor： 容器监控（与Docker/Kubernetes集成极佳）。

部署这些exporter的流程与node_exporter类似：下载、配置、运行为服务，然后在Prometheus配置中添加新的抓取任务。

5. 性能调优：
如果监控目标非常多（数百上千），Prometheus的抓取和存储可能会成为瓶颈。可以：

• 调整 scrape_interval，对于不常变化的指标可以适当拉长间隔。
• 使用 Prometheus Recording Rules，将频繁查询或计算复杂的表达式预先计算好并存储为新指标，极大减轻查询时负载。
• 确保Prometheus服务器有足够的CPU、内存，尤其是高速的IOPS（对于时间序列数据库，磁盘IO性能至关重要，SSD是标配）。

搭建这套系统的过程，其实也是理解现代可观测性理念的过程。从最初的手忙脚乱到看着仪表盘上所有指标平稳运行，那种对基础设施的掌控感是非常实在的。我自己的几台服务器在接入监控后，成功预警了两次磁盘空间不足和一次内存异常增长，避免了服务中断。现在，任何风吹草动都尽在掌握，再也不用半夜被报警电话吵醒才发现问题了。