1. 从“救火”到“预防”为什么我们需要监控磁盘空间在运维和开发工作中磁盘空间告警可能是最“朴素”却又最“致命”的问题之一。我经历过太多次这样的场景凌晨被电话叫醒线上服务大面积告警登录服务器一看/var或/home目录已经 100% 占满导致应用日志无法写入、数据库连接中断、甚至系统直接卡死。一通手忙脚乱的du -sh *和rm -rf之后问题虽然暂时解决但根本原因是什么哪个目录或文件增长最快下次什么时候会再次爆满心里完全没底。这种被动的“救火”模式不仅消耗精力更对业务稳定性构成直接威胁。因此将磁盘空间监控从“事后处理”转变为“事前预警”和“趋势分析”是提升系统可观测性和运维成熟度的关键一步。而Grafana Prometheus的组合正是实现这一目标的黄金搭档。Prometheus 负责高效、可靠地采集和存储时序数据Grafana 则以其强大的可视化能力将枯燥的数字转化为直观的图表和清晰的告警。这套组合不仅能告诉你“现在磁盘用了多少”更能展示“过去一周的增长趋势”、“哪个挂载点最吃紧”并预测“按此速度还有多久会写满”。本文将基于一个真实的服务器环境手把手带你搭建一套完整的磁盘空间监控体系。我们不会止步于简单的“安装启动”而是会深入每个配置项背后的逻辑分享我在实际部署中踩过的坑和总结的最佳实践目标是让你部署的监控系统不仅“能用”而且“好用”、“可靠”。2. 监控体系核心组件选型与原理剖析在动手之前理解我们所用工具的核心工作原理至关重要。这能帮助你在出现问题时快速定位也能让你做出更合理的配置决策。2.1 Prometheus不只是个时间序列数据库Prometheus 的核心设计哲学是拉取Pull模型。不同于传统监控代理Agent主动上报数据Prometheus 服务器会周期性地主动去配置好的目标Targets上“抓取”指标。对于磁盘监控这意味着我们需要在每台被监控主机上运行一个导出器Exporter它负责收集本机的磁盘使用数据并通过 HTTP 接口以 Prometheus 规定的文本格式暴露出来。Prometheus 服务器则定时访问这个接口拉取数据。为什么选择 Pull 模型控制权在监控端可以统一控制抓取频率、重试策略避免因被监控端故障导致的数据洪峰冲击监控服务器。易于诊断你可以直接用curl命令访问 Exporter 的端点直接查看它暴露的原始指标调试非常方便。天然支持动态发现结合服务发现如 Kubernetes, Consul可以自动发现新的监控目标。对于磁盘监控我们将使用Node Exporter。它是 Prometheus 生态中用于收集主机层面指标如 CPU、内存、磁盘、网络的官方标准组件。2.2 Node Exporter主机指标的采集器Node Exporter 是一个静态二进制文件运行在被监控主机上默认在9100端口提供一个/metrics接口。当我们访问http://主机IP:9100/metrics时会看到如下格式的文本# HELP node_filesystem_size_bytes Filesystem size in bytes. # TYPE node_filesystem_size_bytes gauge node_filesystem_size_bytes{device/dev/nvme0n1p2,fstypeext4,mountpoint/} 1024203784192 # HELP node_filesystem_free_bytes Filesystem free space in bytes. # TYPE node_filesystem_free_bytes gauge node_filesystem_free_bytes{device/dev/nvme0n1p2,fstypeext4,mountpoint/} 366456987648 # HELP node_filesystem_avail_bytes Filesystem space available to non-root users in bytes. # TYPE node_filesystem_avail_bytes gauge node_filesystem_avail_bytes{device/dev/nvme0n1p2,fstypeext4,mountpoint/} 339789123584这里有几个关键点node_filesystem_size_bytes文件系统总大小。node_filesystem_free_bytes文件系统剩余空间包含保留给root的空间。node_filesystem_avail_bytes非root用户可用的空间更接近df命令看到的Avail列。标签Labelsdevice,fstype,mountpoint。这些标签是 Prometheus 数据模型的精髓它们使得我们可以从不同维度如按挂载点、按设备类型来查询和聚合数据。一个重要的区别free和avail。在 Ext4/XFS 等文件系统中默认会保留约 5% 的空间给 root 用户以防止普通用户写满磁盘导致系统故障。因此node_filesystem_free_bytes可能比node_filesystem_avail_bytes大。在计算使用率时我们通常使用avail来计算“用户可用空间”。2.3 Grafana让数据说话的仪表盘Grafana 本身不存储数据它是一个功能强大的数据可视化平台。它从 Prometheus或其他数据源查询数据并通过丰富的图表类型曲线图、柱状图、仪表盘、表格等展示出来。它的核心优势在于灵活的查询使用 PromQLPrometheus 查询语言可以写出非常强大的查询语句进行多维度分析、聚合计算。可编排的仪表盘可以将多个相关图表组织在一个页面上形成完整的监控视图。强大的告警可以基于查询结果设置告警规则并支持通过钉钉、企业微信、邮件、Webhook 等多种渠道通知。我们的目标就是通过 Grafana创建一个直观的磁盘监控仪表盘并设置合理的告警规则。3. 实战部署一步步搭建监控栈假设我们有一台 IP 为192.168.1.100的 CentOS 7 服务器需要被监控监控服务器运行 Prometheus 和 Grafana的 IP 是192.168.1.200。我们将分步完成部署。3.1 在被监控主机上部署 Node Exporter第一步下载并安装 Node Exporter建议从 Prometheus 官方 GitHub Release 页面下载最新稳定版本。使用wget和tar命令完成安装。# 登录到被监控主机 192.168.1.100 cd /opt wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz tar xzf node_exporter-1.6.0.linux-amd64.tar.gz mv node_exporter-1.6.0.linux-amd64 node_exporter cd node_exporter第二步以系统服务方式运行推荐创建服务文件可以让 Node Exporter 随系统启动并由 systemd 管理生命周期方便运维。sudo vi /etc/systemd/system/node_exporter.service将以下内容写入文件[Unit] DescriptionNode Exporter Afternetwork.target [Service] Usernobody ExecStart/opt/node_exporter/node_exporter Restarton-failure [Install] WantedBymulti-user.target这里指定Usernobody是为了以最小权限运行增强安全性。Restarton-failure确保服务在异常退出时自动重启。第三步启动并测试服务sudo systemctl daemon-reload sudo systemctl start node_exporter sudo systemctl enable node_exporter sudo systemctl status node_exporter # 检查状态是否为 active (running)现在你可以通过浏览器或curl访问http://192.168.1.100:9100/metrics应该能看到大量的指标输出其中包含我们需要的磁盘相关指标。注意如果服务器有防火墙如 firewalld需要开放 9100 端口sudo firewall-cmd --add-port9100/tcp --permanent sudo firewall-cmd --reload。3.2 在监控服务器上部署 Prometheus第一步下载并安装 Prometheus在监控服务器192.168.1.200上操作。cd /opt wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz tar xzf prometheus-2.45.0.linux-amd64.tar.gz mv prometheus-2.45.0.linux-amd64 prometheus cd prometheus第二步配置 Prometheus 抓取 Node Exporter编辑 Prometheus 的主配置文件prometheus.yml。vi prometheus.yml在scrape_configs部分添加一个新的 job指向我们刚才部署的 Node Exporter。global: scrape_interval: 15s # 全局抓取间隔15秒一次对主机监控来说足够 evaluation_interval: 15s # 规则评估间隔 scrape_configs: - job_name: prometheus # 监控 Prometheus 自身 static_configs: - targets: [localhost:9090] - job_name: node # 新增用于监控所有主机 static_configs: - targets: [192.168.1.100:9100] # 这里填入你的被监控主机地址 labels: instance: web-server-01 # 给这台主机起个别名在 Grafana 里更容易识别关键配置解析job_name: node定义一个抓取任务组名字可以自定义。targets: 指定要抓取的目标列表。如果有多台主机可以依次添加如[host1:9100, host2:9100]。labels: 为这个目标添加额外的标签。这里添加了一个instance标签其值web-server-01会附加到从该目标抓取的所有指标上。这在区分多台主机时非常有用。第三步以系统服务方式运行 Prometheussudo vi /etc/systemd/system/prometheus.service[Unit] DescriptionPrometheus Afternetwork.target [Service] Usernobody ExecStart/opt/prometheus/prometheus --config.file/opt/prometheus/prometheus.yml --storage.tsdb.path/opt/prometheus/data Restarton-failure [Install] WantedBymulti-user.target--storage.tsdb.path指定了时序数据的存储路径请确保该目录存在且 Prometheus 进程有写权限。第四步启动并验证sudo systemctl daemon-reload sudo systemctl start prometheus sudo systemctl enable prometheus sudo systemctl status prometheus访问http://192.168.1.200:9090打开 Prometheus 的 Web UI。在顶部导航栏点击 “Status” - “Targets”。你应该能看到node这个 job 下的目标状态为 “UP”这表示 Prometheus 已经成功连接到 Node Exporter 并开始抓取数据。3.3 在监控服务器上部署 Grafana第一步安装 Grafana这里使用官方仓库安装以获取最新版本和方便的升级路径。# 添加 Grafana 仓库 sudo vi /etc/yum.repos.d/grafana.repo写入以下内容[grafana] namegrafana baseurlhttps://packages.grafana.com/oss/rpm repo_gpgcheck1 enabled1 gpgcheck1 gpgkeyhttps://packages.grafana.com/gpg.key sslverify1 sslcacert/etc/pki/tls/certs/ca-bundle.crt然后安装并启动sudo yum install -y grafana sudo systemctl start grafana-server sudo systemctl enable grafana-server默认情况下Grafana 监听在3000端口。访问http://192.168.1.200:3000首次登录使用默认账号admin/admin系统会强制要求修改密码。第二步添加 Prometheus 数据源登录 Grafana 后点击左侧齿轮图标 “Configuration” - “Data sources”。点击 “Add data source”选择 “Prometheus”。在 URL 字段填写http://localhost:9090因为 Prometheus 和 Grafana 在同一台机器。其他参数保持默认。点击 “Save test”如果显示 “Data source is working”则表示配置成功。4. 构建磁盘监控仪表盘从查询到可视化数据已经就绪现在是发挥 Grafana 威力的时候了。我们将创建一个包含核心磁盘指标的新仪表盘。4.1 关键 PromQL 查询语句解析在 Grafana 中创建图表本质上是编写 PromQL 查询。以下是几个核心查询1. 磁盘总空间、已用空间、可用空间字节这是最基础的指标直接取自 Node Exporter。总空间node_filesystem_size_bytes可用空间node_filesystem_avail_bytes已用空间通过计算得到node_filesystem_size_bytes - node_filesystem_avail_bytes2. 磁盘使用率百分比这是最常用的监控指标。计算公式为(总空间 - 可用空间) / 总空间 * 100%。对应的 PromQL 是(1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 1003. 按挂载点过滤一台服务器通常有多个挂载点/,/home,/var等。我们通常更关心根目录/或数据目录。可以使用mountpoint标签进行过滤。(1 - node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 1004. 排除虚拟文件系统Node Exporter 会收集所有文件系统包括tmpfs,devtmpfs,proc等。这些通常不是我们监控的目标。可以使用fstype标签来排除。(1 - node_filesystem_avail_bytes{fstype!~tmpfs|devtmpfs|proc|squashfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|devtmpfs|proc|squashfs|overlay} ) * 100这里使用了正则表达式!~来匹配fstype标签值不为所列类型的文件系统。4.2 创建仪表盘与面板在 Grafana 首页点击 “” - “Dashboard”。点击 “Add visualization” 添加第一个面板。面板一磁盘使用率趋势图Time series数据源选择之前添加的 Prometheus。查询 A粘贴上方的排除虚拟文件系统的使用率查询语句。图例在 “Legend” 字段输入{{mountpoint}} - 使用率这样图例会显示具体的挂载点。单位在右侧 “Standard options” - “Unit” 中选择 “Percent (0-100)”。阈值在 “Thresholds” 中可以添加视觉警报线例如在 80% 处添加黄色标记在 90% 处添加红色标记。给面板起个名字如 “磁盘使用率趋势”。面板二当前磁盘空间详情表Table趋势图看变化表格看当前快照。点击 “Add visualization”选择 “Table”。在 “Query” 标签页下需要添加多个查询来获取不同字段。查询 A (Mountpoint)node_filesystem_size_bytes{fstype!~tmpfs|devtmpfs|proc}在 “Instant” 模式下执行并设置 “Format as” 为 “Table”。在 “Transform” 标签页使用 “Organize fields” 变换只保留mountpoint字段并重命名为 “挂载点”。查询 B (Total)同上一个查询但重命名为 “总容量”。在 “Standard options” - “Unit” 中选择 “Bytes(IEC)”这样会自动显示为 GiB/MiB。查询 C (Avail)node_filesystem_avail_bytes{fstype!~tmpfs|devtmpfs|proc}重命名为 “可用空间”设置单位。查询 D (Used%)使用率查询重命名为 “使用率”设置单位为百分比。使用 “Transform” 中的 “Merge” 或 “Join by field” 变换将这些查询的结果按mountpoint合并成一张完整的表。可以再添加一个 “计算字段” 来显示 “已用空间”总容量 - 可用空间。面板三磁盘空间预测Stat利用 Grafana 的 “Stat” 面板和趋势预测功能可以估算磁盘写满的时间。添加一个 “Stat” 可视化。查询特定挂载点如/的可用空间node_filesystem_avail_bytes{mountpoint/}在右侧 “Value options” 中开启 “Show” - “Sparkline” 显示趋势线。最关键的一步在 “Standard options” 下方找到 “Data links”添加一个链接到 “Explore” 页面并设置查询为predict_linear(node_filesystem_avail_bytes{mountpoint/}[6h], 3600*24*7)。这个predict_linear函数会根据过去6小时的数据线性预测未来7天后的值。虽然不完全准确但能提供一个有价值的参考趋势。4.3 仪表盘布局与优化将以上面板拖拽到合适的位置。一个好的布局可以是顶部放一个 “Stat” 面板显示最关键根目录的使用率和预测中间放大的 “Time series” 趋势图下方放 “Table” 详情表。最后别忘了点击仪表盘右上角的 “Save” 图标给你的仪表盘起一个名字如 “主机磁盘监控”并选择一个有意义的文件夹。5. 设置告警从可视化到自动化预警监控的最终目的是为了在问题发生前得到通知。Grafana 的告警功能非常强大。5.1 创建告警规则我们以“根目录磁盘使用率超过85%”为例创建告警。在刚才创建的 “磁盘使用率趋势图” 面板上点击标题选择 “Edit”。在编辑页面切换到 “Alert” 标签页。点击 “Create alert rule from this panel”。规则配置Rule name:Disk Usage High on /Evaluate every:1m(每分钟评估一次)For:5m(持续5分钟满足条件才触发避免瞬时毛刺)查询条件确保查询是(1 - node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100Condition: 当last()值最新值is above85。告警分类与通知在 “Labels” 部分添加标签如severitywarning,teaminfra便于后续路由。在 “Notifications” 部分选择你已配置好的通知渠道如钉钉、邮件联系点。5.2 告警最佳实践与避坑指南避免告警疲劳不要一超过阈值就告警。使用 “For” 字段设置持续时长比如持续5分钟超过85%才告警。对于磁盘增长这通常是合理的。分级告警可以设置多级告警。例如使用率 85% 为 Warning通知到钉钉群使用率 95% 为 Critical同时打电话或发短信。区分不同挂载点为/,/var,/home等重要但增长模式不同的挂载点设置不同的阈值。/var/log可能增长很快但可以清理阈值可以设低一些而业务数据目录可能需要更保守的阈值。告警消息模板化在通知渠道配置中使用模板化消息包含清晰的信息[${severity}] 告警主机 ${instance} 的 ${mountpoint} 磁盘使用率已达 ${value}%请及时处理。关联静默规则如果你有定期的日志清理或备份任务可能会短暂推高磁盘使用率。可以为这些已知的维护窗口设置静默规则避免产生噪音告警。6. 生产环境进阶考量与优化当监控从单台主机扩展到几十上百台时简单的静态配置将难以维护。以下是一些进阶考量。6.1 使用服务发现动态管理监控目标在prometheus.yml中硬编码 IP 地址是不可持续的。Prometheus 支持多种服务发现方式文件服务发现将目标列表写在一个 JSON 或 YAML 文件中Prometheus 定期读取。scrape_configs: - job_name: node file_sd_configs: - files: - /etc/prometheus/targets/node*.json文件内容示例 (/etc/prometheus/targets/nodes.json)[ { targets: [192.168.1.100:9100], labels: { instance: web-01, env: production, role: webserver } } ]基于 DNS 的服务发现通过 DNS SRV 记录或 A 记录发现目标。基于云平台/容器的服务发现集成 Consul, Kubernetes, Eureka 等。使用服务发现后你可以在 Grafana 中利用这些额外的标签如env,role进行更灵活的分组和过滤。6.2 Node Exporter 的采集优化与安全采集过滤Node Exporter 默认采集大量指标。如果某些指标不需要可以通过启动参数过滤减少数据量。例如--collector.filesystem.mount-points-exclude^/(sys|proc|dev|run|var/lib/docker)($|/)可以排除一些虚拟文件系统。认证与 TLS在生产环境暴露 9100 端口可能存在风险。可以考虑使用防火墙严格限制访问源 IP仅允许 Prometheus 服务器 IP。为 Node Exporter 和 Prometheus 之间的通信配置 TLS 加密和基础认证通过--web.config.file参数。通过反向代理如 Nginx添加认证层。6.3 Prometheus 存储与高可用数据保留与清理默认数据保留15天。可以通过--storage.tsdb.retention.time参数调整如180d保留半年。注意磁盘空间消耗。远程读写对于大规模集群可以考虑使用 Prometheus 的远程读写功能将数据长期存储到更经济的对象存储如 S3或时序数据库如 Thanos, Cortex中实现历史数据的长期存储和全局查询。高可用部署运行两个或多个完全相同的 Prometheus 服务器采集相同的目标。配合 Alertmanager 的集群模式可以实现监控系统本身的高可用避免单点故障。6.4 Grafana 仪表盘模板化与导入手动创建仪表盘效率低下。Grafana 社区有大量优秀的仪表盘模板。你可以直接搜索 “Node Exporter Full” 等模板导入后稍作修改即可使用。这能快速获得一个包含 CPU、内存、磁盘、网络等全方位监控的成熟仪表盘。7. 故障排查与日常维护心得即使搭建完成系统也可能出问题。以下是一些常见问题的排查思路和我积累的经验。问题一Prometheus Targets 页面显示 “DOWN”检查网络从 Prometheus 服务器telnet target_ip 9100。检查 Node Exporter 进程在被监控主机上systemctl status node_exporter。检查防火墙确认 9100 端口在两端防火墙都已放行。检查 Prometheus 配置确认prometheus.yml中targets的 IP 和端口号书写正确。问题二Grafana 中查询不到数据但 Prometheus 里有检查数据源确认 Grafana 中配置的 Prometheus URL 正确且可访问。检查时间范围Grafana 右上角的时间范围选择器是否设置正确是否选择了很久以前的时间。检查查询语句在 Grafana 的 “Explore” 页面或 Prometheus 的 Graph 页面手动执行相同的 PromQL看是否有数据返回。特别注意标签匹配是否正确。问题三磁盘使用率图表显示多条重复或奇怪的线原因可能是同一台主机有多个相同mountpoint的指标例如在容器环境下宿主机和容器内都暴露了相同挂载点。或者instance标签发生了变化。解决在查询中增加更精确的标签过滤例如加上instanceweb-server-01。或者使用group_left等操作符处理多对一的关系。日常维护建议定期检查告警规则确保告警阈值仍然符合业务现状。随着业务增长可能需要调整。监控监控系统自身为 Prometheus 和 Grafana 服务器本身也配置基础监控磁盘、内存确保监控平台健康运行。容量规划定期查看 Prometheus 的存储目录大小预测增长趋势提前扩容。文档化将仪表盘的链接、告警规则的含义、处理流程文档化方便团队协作和新人上手。搭建 Grafana Prometheus 监控磁盘空间起点是一个具体的需求但终点是一个可扩展的、完整的可观测性平台的基础。从这个点切入你可以逐步将监控范围扩大到应用性能、业务指标、日志追踪等领域真正构建起驱动业务稳定性和研发效率的“数据驾驶舱”。