Azure Service Fabric集群因数据盘磁盘不足致应用异常，Trace日志占用过高

我之前帮客户处理过几乎一模一样的场景——单节点Service Fabric Trace日志暴增，磁盘被占满，还是周期性出现。咱们一步步来，先找根因，再彻底解决。

首先得搞清楚是节点本身的Fabric系统组件还是部署在这的应用服务在乱打日志：

• 解析ETL日志文件：用Windows自带的tracerpt工具把超大的ETL转成可读格式，比如执行：

  tracerpt fabric_traces_6.1.472.9494_131695673562955183_2.etl -o csv -of csv
  

  打开生成的CSV文件，搜重复出现的日志条目，看是不是某个服务（比如某个应用副本、Fabric系统服务）在高频输出日志——比如我之前遇到过某个应用的错误日志每秒打几十条，直接把磁盘撑爆。
• 检查节点服务分布：登录这个异常节点，用Service Fabric Explorer或者PowerShell命令Get-ServiceFabricDeployedServicePackage -NodeName [你的节点名]，对比其他正常节点，看看有没有独有的服务，或者状态异常（比如一直在重启）的服务。
• 查系统事件日志：打开Windows事件查看器，翻Service Fabric相关的日志、系统日志，看有没有重复触发的报错或警告——比如某个服务崩溃重启循环，每次重启都会打一堆初始化日志。

现在磁盘快满了，先把空间腾出来：

• 手动清理旧ETL：别删最新的几个（留着排查用），把超过7天的旧ETL文件直接删掉就行，不会影响集群运行。
• 用Fabric内置清理命令：执行Invoke-ServiceFabricCleanupLog，这个命令会按集群配置的日志策略清理旧日志，但如果策略没配置好可能没用，先试试总没错。

解决完临时问题，得从根源上堵漏洞：

• 调整日志留存策略：修改集群的ClusterManifest.xml，找到Diagnostics配置段，设置两个关键参数：
  • MaxDiskQuotaInMB：比如设为40960（也就是40GB），限制Trace日志最多占这么多空间
  • LogRetentionDuration：比如设为P7D（7天），自动删除超过7天的旧日志
    配置后Fabric会自动清理日志，不会再让磁盘被撑爆。
• 升级Service Fabric版本：你用的6.1.472是2018年的老版本了，微软在后续版本里修复了超多日志泄露、清理失效的bug，直接升级到最新的LTS（长期支持）版本（比如9.x系列），能解决大部分这类底层问题。
• 加监控告警：用Azure Monitor配置两个告警规则：
  • 节点磁盘使用率超过80%时触发告警，提前处理
  • 监控\SvcFab\Log\Traces文件夹的大小，一旦短时间内暴涨就告警
• 检查应用日志配置：如果是应用服务打日志太多，去看应用的日志级别是不是设成了Debug（没必要的话改成Info或Error），有没有循环打日志的逻辑（比如异常捕获里没退出，一直打错误日志）。

如果解析ETL后发现是Fabric系统服务（比如FabricRM、FabricHost）在疯狂打日志，那基本就是旧版本的bug，升级版本是最有效的解决办法；如果是某个应用实例的问题，那得深入查应用代码，修复日志溢出的逻辑。

内容的提问来源于stack exchange，提问作者Tyler Henrichs