-
我的服务跑了几个月一直好好的,某天突然各种 No space left on device,数据写不进、健康检查失败,连同节点上别的服务一起遭殃,排查发现是日志文件没配轮转涨到了几十 G 把磁盘撑满了的深度复盘
我的服务一直把日志写到一个文件 app.log,平稳跑了好几个月。某天毫无征兆地一堆故障同时爆发:报 No space left on device、数据写不进、健康检查失败被重启,连同节点上别的服务也跟着遭殃。登机器 df -h 一看磁盘 100% 满了,du 一查祸首是 app.log——它悄悄涨到了几十 GB。复盘才意识到:我只关心了把日志记下来,却从没考虑日志写到哪、会涨多大、怎么清理;一…- 0
- 0
-
我在批处理循环里写了 try except pass,觉得出错就跳过别让程序崩很稳健,结果一批数据悄悄少处理了一半还谁都不知道,连 Ctrl+C 都按不停:一次裸 except 吞掉异常的深度复盘
我有个批处理循环处理一批数据,为了健壮给循环体包了 try: ... except: pass(出错就跳过继续)。可线上跑完对账发现处理结果悄悄少了一大半:本该 1 万条只成功几千条,另外几千条出错被 except: pass 静默吞掉跳过、没有任何日志和报警谁都不知道;更离谱的是跑的时候 Ctrl+C 想停居然按不停。查清才明白用裸 except + pass 的两宗罪:pass 把异常静默吞掉…- 0
- 0
-
服务突然大面积报错、写文件上传写库全线失败,登上机器 df 一看磁盘竟然满了:日志从上线起从没切割清理、悄悄撑爆整块磁盘的全线崩溃避坑复盘
这是一次让我印象极深的全线崩溃,它崩得又突然又广,广到我一度以为服务器中毒了。某天下午我们的服务毫无征兆地开始大面积报错,而且错误五花八门毫无规律:有的请求报写文件失败,有的报上传失败,甚至连数据库写入都开始报错,日志里 No space left on device 设备上没有剩余空间这行字疯狂刷屏。我懵了:这几个功能八竿子打不着怎么会同时出问题?直到我登上服务器敲下那个运维排查的第一反应命令 …- 0
- 0
-
被一个 catch 吃掉的异常:Java 异常处理里那些查到崩溃的坑
这个 bug 我查了整整三天,最折磨人的地方在于:日志里干干净净,什么都没有。线上偶尔有几笔订单金额对不上,概率很低、毫无规律,可一旦出现就是真金白银的差错。把整条链路的日志翻了个底朝天,期待看到一行报错、一段堆栈,结果一片祥和。直到逐个方法去读源码,才在一个不起眼的工具类里看到那行让我血压飙升的代码——一个空的 catch 块,把异常静悄悄咽了下去,程序若无其事地把错误金额写进了库。没有报错、没…- 0
- 0
-
日志打爆磁盘:一次 error.log 涨到 388G 的周末宕机复盘
周末凌晨核心服务集体宕机,报 No space left on device——磁盘被写满。罪魁是一个 ERROR 日志在异常风暴里疯狂打印,几小时灌满几百 G 磁盘。几天治理:配 totalSizeCap 总量上限、异步日志 neverBlock 保业务、异常日志限流、日志级别梳理、磁盘与 ERROR 速率三级告警。- 3
- 0
-
Elasticsearch 集群 50TB 治理:索引合并 + 冷热分层 + JVM 调优实录
ES 7.10 集群日增 800GB,3 个月 50TB,8000 索引 6w 分片,heap 90% Full GC,P99 8s,集群频繁 yellow/red。三周治理:索引合并按周 + mapping strict + JVM G1 + ILM 冷热分层 + search_after + slowlog 告警。P99 80ms,存储 18TB,成本 -56%。- 0
- 0
-
Elasticsearch 80 亿日志治理:P99 8s→200ms 磁盘 -60%
ES 7.17 集群 80 亿日志,搜索 P99 8s 写入打不住磁盘告警。一个月优化全实录:索引模板 strict + 分片设计 + ILM 冷热分离(hot/warm/cold) + bulk processor + JVM 调参 + 查询改写。P99 从 8s 降到 200ms,磁盘节约 60%。- 0
- 0
日志
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×