集群日志轮转与磁盘空间预警配置应该怎么落地？

在分布式系统运维中，日志文件会随着服务长期运行不断膨胀。如果不加控制，单个节点上的日志可能在几天内占满系统盘，进而导致进程无法写入状态文件、容器被驱逐甚至节点宕机。集群日志轮转与磁盘空间预警配置的核心目标，是把日志体积控制在安全范围内，并且在磁盘使用率异常升高时第一时间通知责任人。这里不依赖云厂商控制台，而是用开源组件在自建集群上完成自动化闭环。

基于logrotate的集群日志轮转策略

logrotate是Linux系统自带的日志管理工具，它通过读取配置文件决定何时对日志进行切割、压缩和删除。在集群场景下，我们通常不会逐台登录机器去修改/etc/logrotate.d/下的文件，而是借助配置管理工具如Ansible将同一份模板下发到所有节点。这样做能保证轮转规则一致，避免出现有的节点按大小切、有的节点按天切的混乱局面。

一个典型的集群日志轮转配置需要明确几个关键参数。size表示当日志达到指定体积就触发轮转，适合写入量波动大的服务；daily表示按天轮转，适合访问量较平稳的业务。两者可以并存，logrotate只要满足其中一个条件就会执行。另外rotate指定保留几份历史日志，compress开启压缩以节省空间，missingok允许日志暂时不存在而不报错。

在集群中还需注意sharedscripts的使用。如果配置中对多个日志文件使用了同一个postrotate脚本，未加sharedscripts时脚本会对每个文件各执行一次，可能导致服务信号重复发送。加上后脚本只在所有匹配文件处理完执行一次，更适合Nginx、Java多实例等场景。下面是一段通用的logrotate配置示例：

/var/log/myapp/*.log {
    daily
    size 200M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload myapp > /dev/null 2>&1 || true
    endscript
}

这段配置意味着：在/var/log/myapp/下的日志每天检查一次，若单文件超200M也会立即切；保留最近7份，旧日志延迟到下次轮转时压缩，空文件不处理。通过Ansible批量下发后，所有节点行为完全一致，极大降低了运维负担。

利用Node Exporter与Prometheus采集磁盘指标

光有日志轮转并不能预防非日志文件导致的磁盘满，比如临时文件、核心转储或容器层叠加写。因此必须实时采集节点磁盘使用率。Node Exporter是Prometheus生态中收集主机指标的标准组件，它默认会暴露node_filesystem_avail_bytes和node_filesystem_size_bytes等时间序列，涵盖每个挂载点。

在集群部署时，每个节点都运行一个Node Exporter，通过DaemonSet或系统服务保证不漏机。Prometheus服务端采用kubernetes_sd_configs或静态配置发现这些target，抓取间隔设为15秒到30秒即可，过频会增加存储压力。我们需要用PromQL计算使用率，例如：

100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100)

上述表达式得出根分区已用百分比。如果集群有数据盘挂载在/data，应额外加一条针对该挂载点的规则。相比单机用df -h人工看，Prometheus能保存历史曲线，帮助判断是突发增长还是缓慢泄漏。同时可结合node_textfile_collector把业务自定义磁盘阈值写入，方便分角色告警。

磁盘空间预警规则与告警通知落地

拿到磁盘使用率指标后，要在Prometheus中写告警规则文件，定义什么条件下触发。一般建议设置两级：警告级例如使用率大于80%持续5分钟，严重级大于90%持续2分钟。这样既能给处理留缓冲，又不会因瞬间抖动误报。规则片段如下：

groups:
- name: disk-alert
  rules:
  - alert: DiskUsageWarning
    expr: 100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100) > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "节点 {{ $labels.instance }} 根分区使用率超80%"
  - alert: DiskUsageCritical
    expr: 100 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100) > 90
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "节点 {{ $labels.instance }} 根分区使用率超90%"

告警产生后由Alertmanager负责路由。我们可以按severity标签把warning发到运维邮箱，critical同时发钉钉或企业微信机器人。配置route与receiver时需注意避免告警风暴，比如同节点短时间内重复触发只通知一次，用group_interval控制。最终效果为：当某节点日志异常未轮转或别人误存大文件，手机立刻收到带实例名的消息，人工介入前系统已自动压缩旧日志降低风险。

把logrotate与Prometheus告警结合起来，才是完整的集群磁盘治理方案。前者在本地默默兜底，后者在全局视角盯着水位。两者配置都应以代码形式纳入版本库，任何改动经评审后下发，杜绝手工改线上。随着节点增多，这套机制边际成本几乎为零，却能有效挡住最基础的可用性事故。

logrotatedisk_alertPrometheus修改时间：2026-08-19 00:00:36