共计 1573 个字符，预计需要花费 4 分钟才能阅读完成。
哈喽哈喽大家猴，我是把代码写成 bug 的大头菜。公众号：大头菜技术(bigheadit)。原创不易，但欢送转载。
明天不晓得为啥醒得特地早，可能就是缘分吧。醒来一看微信，就发现线上的服务器的磁盘使用率超过 70%，真是早起的鸟儿有 bug 修。。。。。
过后我就立马跑去看看监控，看看 cpu, 内存,io 这些是否都失常。看了一圈，发现除了磁盘异样外，其余所有都失常。
我过后是 7 点左右看到的音讯，看到后，磁盘的使用率达到 72%，超过了设定阈值 70%。就如上图的红色箭头所示。
过后我是间接进入服务器，用 df - h 查看服务器的磁盘应用空间。
看到上图，过后我人都傻了。2.7T 空间，而后应用才 5%，哪来的 70% 磁盘使用率。
起初深呼吸，喝口冰水沉着一下，发现，公司用的是容器，而 df - h 查的是物理服务器的磁盘空间。过后我状况比拟紧急，我也忘了什么命令能够查容器的硬盘空间。只好去谷歌输入框输出：“如何查看容器的磁盘空间”
很快，我就搜到相干命令：docker system df -v
然而，期待我的却是
docker system df -v
-bash: docker: command not found牛逼！！！牛逼！！！
好吧，看来是没方法通过命令查看哪个中央用的磁盘空间比拟大了。不过又比拟紧急，只能用最笨的办法：遍历查问。然而这个遍历，我优先遍历查看日志文件。没想到一击即中，立马就找到了磁盘爆满的根本原因。
你看，从 2 月 25 号日志到当初 3.21 号的日志都在，总共占用了 20G。我问了运维每台容器调配 30G。20G/30G=66.7%。单纯日志曾经占用磁盘空间的 66.7%，再加上其余的利用，占用 70+%。实锤了，找到真凶了。我也没想到这么快找到。
至于为什么我一开始就找日志文件呢？
次要是因为教训吧，因为之前别的服务器也呈现过磁盘使用率问题，过后也是因为日志文件问题。简略总结一下，尽管教训不总是牢靠，但排查线上问题时，教训又总是那么有用。因而，排查问题时，一开始要依据监控数据，进行排查，不要先入为主，用想当然去排查，就是不必教训去想问题。先跳出固有圈子，依据实实在在的监控指标数据排查。切实没方法时，再用教训去排查也不迟。
那么当初咱们曾经定位到磁盘空间问题的根本原因：日志文件占用空间过多。
那接下来应该怎么做呢？
只能删文件，腾出空间。遇到磁盘使用率问题，除了删文件，还有其余方法吗？有，扩充磁盘空间，但多大才够，这计划显然不是最高效的解决方案
这时候终于能够搬出好久没应用的：rm -rf 命令了。
我过后就间接把 2 月份的日志都删除了。
立马看一下监控图
磁盘使用率立马断崖式降落到 70% 以下，首要任务让服务器失常运行再说。
到这里后，你认为就完结了吗？。。。。。。。并没有
交代一下服务器的背景：四台服务器，每台服务器 2 核 8G。
删文件前：
删文件后：
咱们能够看到，删文件的操作，确实临时让磁盘的使用率从 71% 降到 63%。然而，你发现没发现另一个问题。
另外 2 台服务器的磁盘使用率只有 1%。然而另外 2 台的服务器的日志文件都占了大概 20G（容器的硬盘空间 30G）
这让我再一次傻眼儿了！！！！
明明大家都占用了 20G，2 台服务器 70% 的使用率，另外 2 台服务器的使用率却高达 1%。
amazing!!!!!
害，母鸡道点算(粤语)！！！
过后心想，先不论了。服务器当初也失常服务了，等下班后，再和运维聊聊，找找起因。毕竟当初才 7 点，离下班还有 3 个小时。没法找运维的！！！
带着满怀冲动的情绪，终于等到 10 点下班了。
通过和运维的一番形容 (battle) 后，终于找到了答案，解开了纳闷。
其实，就是监控数据的获取有 bug，从而导致数据不精确。
最初我还抓着运维，问了一下如何查看容器的硬盘应用空间？
然而。。。。他如同也不太会。。。。
好了，明天的 bug 顺利解决了。就是查看容器的命令，到当初也没找到。如果你有方法，留言告诉我！感激！
