直接用syscall.Statfs获取文件系统剩余空间最可靠，已用=总-可用，使用率=已用/总；需区分Available（含root保留）与Free（实际可写），按业务选；挂载点路径必须准确，Windows用GetDiskFreeSpaceEx，Linux/macOS用Statfs。
如何判断磁盘使用率是否触发告警阈值
直接用 syscall.Statfs 获取文件系统剩余空间最可靠，避免依赖 shell 命令或外部工具。Go 标准库不提供跨平台的磁盘使用率封装，必须自己算：已用 = 总 - 可用，使用率 = 已用 / 总。
常见错误是把 Available 当成“剩余可用”，其实它受 root 保留空间影响；更稳妥的是用 Free（非 root 用户实际能写入的空间）或 Available（考虑 reserve 后的用户可用空间），按业务容忍度选。
- 监控根路径时，传入挂载点路径（如
"/data"），不是任意子目录路径 - 注意
Statfs返回的块大小单位是字节，别漏乘Bsize或Frsize - Windows 下需用
golang.org/x/sys/windows的GetDiskFreeSpaceEx，Linux/macOS 统一走syscall.Statfs
告警状态去重与抑制的关键逻辑
频繁写入小文件的场景下，每秒轮询会大量重复触发同一阈值告警。不能只靠“上次告警时间 > 5 分钟”这种简单限流——真正要解决的是状态跃迁检测：只有从“正常 → 超阈值”才发告警，持续超阈值不重复通知。
建议用 map 记录各存储路径的上一次状态（normal / warn / critical），每次检查后对比更新。状态变化才触发动作，同时记录时间戳用于后续抑制。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 状态键用挂载点 + 阈值组合，例如
"/data:85%"，避免不同阈值混用 - 不要在告警函数里做耗时操作（如发邮件、调 webhook），应投递到异步队列
- 若集成 Prometheus，可暴露
storage_usage_percent{mount="/data"}指标，由 Alertmanager 统一处理抑制
多路径存储下的容量聚合与分层告警
一个服务挂载多个磁盘（如 /data01、/data02）时，“整体容量超限”这种聚合判断容易误报——某块盘打满但其他盘空闲，不应全局降级。
更合理的做法是分层设置：单盘 >90% 触发 warning，任一盘 >95% 触发 critical；同时加一条“有效容量低于总容量 30%”作为兜底（防碎片化导致无法分配大块连续空间）。
- 遍历所有目标路径时，跳过不可访问或无权限的路径，记录 error 但不停止整体检查
- 聚合计算前先过滤掉
0 total或nil Statfs_t的异常结果，防止除零 panic - 对 SSD 和 HDD 存储路径建议设不同阈值，SSD 可预留更多空间（如 15%），避免写放大影响寿命
测试磁盘满载场景的本地模拟方法
没法真把生产盘写满来测告警，用 loop device 或 dd 创建虚拟块设备最接近真实行为。容器环境可用 tmpfs 挂载点配 quota 模拟，但注意 Statfs 在 tmpfs 上返回的 Blocks 是内存页数，不是磁盘块。
单元测试里不要 mock syscall.Statfs——它太底层，mock 容易漏掉结构体字段差异。改用 integration test：启动临时文件系统，跑完立刻 umount。
- Linux 下快速创建 1GB 满载盘：
dd if=/dev/zero of=/tmp/test.img bs=1M count=1000 && mkfs.ext4 /tmp/test.img && mkdir /mnt/test && mount -o loop /tmp/test.img /mnt/test - 测试临界点时，务必验证 89.9%、90.0%、90.1% 三个值的状态跃迁是否准确
- CI 中运行这类测试需加
sudo权限，且清理逻辑（umount && rm）必须放在 defer 或 finally 块里
真正难的不是算百分比，而是搞清“谁在用空间”——du -sh /path/* | sort -hr | head -10 这类诊断命令得配套集成进去，否则告警来了只能干瞪眼。
