哈喽哈喽大家猴,我是把代码写成 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 顺利解决了。就是查看容器的命令,到当初也没找到。如果你有方法,留言告诉我!感激!