临近年关,发生两起磁盘占满引发的服务下线故障

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 一口气说两个因为磁盘空间不足引发的应用故障。

作为拿起键盘一把梭的Coder, 开发--->部署-->收工--->心旷神怡,滋一口82年的可乐.


过了几个月,服务突然下线了!CTO又有杀程序员祭天的理由了!


事故1:Azure App Service


Azure App Service运行一段时间之后,你也许会遇到磁盘占满的错误, 表象如下:


  1. 应用程序触发System.Io.IOException:There is not enough space on the disk异常


  1. 你会在KUDU控制台发现磁盘错误(红色警告)


  1. 当你使用Visual Studio部署新的代码,你会得到失败结果。
    ERROR_NOT_ENOUGH_DISK_SPACE: Web deployment task failed. (Web Deploy detected insufficient space on disk)


每个App Service Plan只获得与定价层匹配的磁盘空间分配,故面向Azure App Service开发的应用需要关注空间消耗!



Shared Basic STANDARD PREMIUM
Disk Space 1G 10G 50G 250G


一个App Service Plan可支撑多个web应用共享付费套餐里面的所有资源,如果磁盘文件大小超过配额,你会看到上面的错误!


你可以在每个应用的[App Service Paln]--->[Quotas] 配置节下面发现当前应用占用的磁盘空间。


一个常规的Web应用包含如下内容:


--- --- 描述 转移方案
1 WebSite Content
刚需
2 App_Data 存储持久化数据/图片 尝试转移到Azure其他存储组件
3 Log Files 本地日志文件 尝试转移到Azure其他存储组件


Azure Storage Account为任意数据提供可扩展、持久化的云存储、备份和恢复解决方案,包括非结构化文本或二进制数据,如视频、音频和图像。


本文点到为止,演示将日志数据转移到Azure Storage Container (非结构化数据存储)。


# 还是以常见的NLog为蓝本:
# 引入`NLog.Extensions.AzureBlobStorage`库文件
  <target xsi:type="AzureBlobStorage"
        name="Cloud_applogs"
        layout="${format}"
        connectionString="********"
        container="actionlogs" 
        blobName="applogs/applog-${date:format=yyyyMMdd}.log"  />
# 其中的ConnectionString参见[Settings]-->[Access Keys]  
 <logger name ="LoggingActionFilter" minlevel="Info" writeTo="Cloud_applogs" />


事故2:  Docker


Docker默认以Json的形式将日志存储到/var/lib/docker/containers


使用 docker system df命令查看Docker磁盘占用


6acda72942d3b18fa6ad5d05971793ef.png


使用docker ps --size定位每个容器的磁盘占用


48eee8b594cd2bcdc99a9b301c0f192c.png


我手上的应用,部署了EFK采集数据,并为ES的索引指定了较充裕的独立磁盘, 但是对EFK本身却忘记了控制日志大小。


清理容器治标不治本,要从根本上解决问题,需要限制容器的日志大小上限。


  1. 配置每个容器的docker-compose中的max-size


logging:
      driver: "json-file"
      options:
        max-size: 100k
        max-file: "5"


  1. 全局设置、

    新建/etc/docker/daemon.json,若有就不用新建了,添加log-dirver和log-opts参数


# vim /etc/docker/daemon.json
{
  "log-driver":"json-file",
  "log-opts": {"max-size":"500m", "max-file":"3"}
}


剖析以上事故,因为是我一个人开发+部署,考虑了一些事,也遗漏了一些事,凸显了职业运维的重要性。


开发和运维,相爱相杀!相辅相成!相得益彰!


临近年关,大家也检查一下部署的应用是否有此低级的风险, 不要像我一样晚节不保!


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
4月前
|
微服务
服务恢复正常
【8月更文挑战第19天】
57 2
|
28天前
|
存储 Shell 数据库
某客户多节点磁盘故障集群恢复
gbase 数据 某客户多节点磁盘故障集群恢复
|
3月前
|
存储 缓存 监控
物理机磁盘水位清理
物理机磁盘水位清理
47 1
|
7月前
|
存储 缓存 Java
线上机器 swap 过高导致告警
线上机器 swap 过高导致告警
|
IDE 安全 开发工具
硬盘故障大全(很详细哦)
硬盘故障大全(很详细哦)
96 1
|
IDE 安全 开发工具
|
运维 监控 Shell
磁盘占用高生产故障复盘总结
磁盘占用高生产故障复盘总结
336 0
|
Java Linux
线上故障快速定位及恢复(上)
线上故障快速定位及恢复(上)
232 0
线上故障快速定位及恢复(上)
|
运维 Java
线上故障快速定位及恢复(下)
线上故障快速定位及恢复(下)
196 0
线上故障快速定位及恢复(下)
|
监控
smartctl定位磁盘故障信息
​ Smartctl(S.M.A.R.T 自监控,分析和报告技术)是用于查看和检测磁盘硬件信息的工具,可以打印SMART自检和错误日志,启用并禁用SMRAT自动检测,以及初始化设备自检。服务器环境中,一般磁盘都是通过RAID卡挂载,如果配置了直通模式,则可以直接使用smartctl查询磁盘信息,如果非直通模式则需要调用raid卡对应接口才可以查询
21194 2