DSE集群节点磁盘占满排查：单节点单表突增600GB的操作溯源

当然有办法定位到导致容量激增的操作！针对你遇到的DSE集群单表容量突增问题，我给你整理了几个实用的排查方向，都是生产环境里常用的方法：

• 系统日志（system.log）：默认路径一般是/var/log/cassandra/system.log（如果是自定义部署路径，就找你配置的日志目录）。这个日志会记录所有DDL操作、大批次DML操作的痕迹，当有异常大量写入时，日志里会出现对应的QUERY、BATCH条目，还会附带发起操作的客户端IP。你可以用grep快速过滤目标表的相关记录：

  grep "your_target_table" /var/log/cassandra/system.log
  

  重点看日志的时间线，找到24小时内开始出现大量写入的时间段，对应客户端IP就是排查重点。
• 审计日志（audit.log）：如果你的集群提前开启了审计功能（默认可能未启用，需要手动配置），这个日志是排查的黄金利器。它会完整记录每一个针对集群的操作，包括操作类型（INSERT/UPDATE/BATCH等）、发起者身份、操作时间、涉及的表名，甚至具体的操作语句。默认路径通常是/var/log/dse/audit/audit.log，过滤命令类似：

  grep "your_keyspace.your_target_table" /var/log/dse/audit/audit.log
  

  如果之前没开审计，这次只能依赖其他日志，但建议排查完后立刻开启审计，预防后续类似问题。

• nodetool tablestats：这个命令能帮你确认表的写入负载情况，执行后可以看到Write Count（写入次数）、Pending Tasks（待处理写入任务）等关键指标，对比历史监控数据（比如你用了Prometheus+Grafana或者DSE OpsCenter），能快速判断是持续高频写入，还是一次性批量操作导致的容量暴涨：

  nodetool tablestats your_keyspace.your_target_table
  

• DSE OpsCenter（如果使用）：OpsCenter的监控面板提供了表级别的读写统计，还有操作历史追踪功能，能直观看到写入量突增的时间点，以及对应的客户端来源，可视化的方式更容易定位问题。

如果从集群日志里定位到了发起操作的客户端IP，直接去对应机器上查应用的业务日志。大概率是应用端出现了异常：比如某个定时任务误触发了全量数据同步、代码BUG导致循环写入、测试环境的批量数据误导入到生产等。

另外，也可以快速排查下表的TTL配置，用DESCRIBE TABLE your_keyspace.your_target_table;查看是否有默认TTL设置，有没有最近修改过TTL导致旧数据未被及时清理——不过你这种24小时内暴涨600G的情况，更可能是主动写入操作，TTL问题一般是缓慢增长，但排查下也没坏处。

最后提醒下：先临时采取措施（比如扩容磁盘、清理非必要数据）让节点恢复正常服务，再慢慢排查根源，避免影响业务运行。

内容的提问来源于stack exchange，提问作者Rajat Awasthi