Service Fabric日志占用了所有可用磁盘空间 [英] Service Fabric logs consuming all available disk space

问题描述

我有一些已经运行了一个月左右的群集，并且发现临时存储已被Service Fabric日志文件完全吞噬.在只有16GB本地存储的F1 VM机群中，我的空间几乎已不足，其中一些现在已降至30MB，是的，是几兆字节的存储(我的应用程序在其中消耗的空间不足1GB)所有版本).

I've got a few clusters that have now been running for a month or so and am finding that temporary storage is being entirely gobbled up by Service Fabric log files. On a sweet fleet of F1 VMs where there is only 16GB of local storage I am just about out of space, a few of them are now down to 30MB, yes mega-bytes of storage (where less than 1GB is consumed by my application in all its versions).

在查看群集VM上的磁盘使用情况时，我可以清楚地看到SvcFab \ Log和SvcFab \ ReplicatorLog文件夹占用了90％以上的可用空间.毫无疑问，SF可以更好地处理此问题.我可以切换或配置一些东西来刷新某些数据吗?还是最好将其移至Blob或表存储中?

In looking at the disk usage on the cluster VMs I can see clearly that the SvcFab\Log and SvcFab\ReplicatorLog folders are consuming over 90% of available space. Surely the SF can better handle this. Is there something I can toggle or configure to get it to flush some of it's data? Or better yet move it up to blob or table storage?

这对其他人来说应该是一个问题.别人在做什么?和Service Fabric团队一起，最佳做法是什么?

This must be an issue for others. What are others doing? And Service Fabric team, what is best practice for this?

推荐答案

因此，对此没有有用的帮助.我求助于拆除该集群并对其进行重建.对我来说幸运的是，该群集是一对群集中的一个，我能够通过TrafficMgr将所有流量简单地重定向到另一个群集，而我又销毁了一个故障群集并创建了一个新群集.

So no useful help on this one. I resorting to tearing down that cluster and rebuilding it. Fortunately for me the cluster was one of a pair and I was able to simply redirect all traffic via TrafficMgr to the other cluster while I destroyed the faulty one and created a fresh one.

我很不高兴.如果没有这种冗余，那将是一个相当大的问题. :-(

Pretty disconcerting to me. Had I not had this redundancy it would have been a rather huge problem. :-(

这篇关于Service Fabric日志占用了所有可用磁盘空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！