-
我的服务跑了几个月一直好好的,某天突然各种 No space left on device,数据写不进、健康检查失败,连同节点上别的服务一起遭殃,排查发现是日志文件没配轮转涨到了几十 G 把磁盘撑满了的深度复盘
我的服务一直把日志写到一个文件 app.log,平稳跑了好几个月。某天毫无征兆地一堆故障同时爆发:报 No space left on device、数据写不进、健康检查失败被重启,连同节点上别的服务也跟着遭殃。登机器 df -h 一看磁盘 100% 满了,du 一查祸首是 app.log——它悄悄涨到了几十 GB。复盘才意识到:我只关心了把日志记下来,却从没考虑日志写到哪、会涨多大、怎么清理;一…- 0
- 0
-
一个调用下游接口后忘了关闭连接的服务,在下游主动断开后留下了一大堆 CLOSE_WAIT,把文件描述符耗尽、再也建不了新连接:一次 CLOSE_WAIT 堆积的深度复盘
服务跑一段时间后大量报 too many open files、建不了新连接,netstat 一看成千上万个 CLOSE_WAIT 只增不减、把 fd 耗尽。根因是调下游接口后没正确 Close 响应体/连接:下游处理完主动关闭它那端发来 FIN,我方收到后进入 CLOSE_WAIT(等我方 close),而代码没 close(异常路径漏关、忘了 defer),连接就永远停在 CLOSE_WAIT…- 2
- 0
-
一个没有配置日志轮转的服务,把一个几十 GB 的日志文件一路写到磁盘爆满,然后整台机器上的服务集体瘫痪:一次磁盘写满的深度复盘
半夜告警:一台机器上彼此不相关的几个服务同时报错崩溃,有的报无法写文件、数据库报无法写入。df -h 一看磁盘 100%、No space left on device,du 顺藤摸瓜揪出一个几十 GB 的日志文件。根因是这个服务的日志从上线起就一直往同一个文件追加、从没配过轮转,跑大半年把磁盘写满;而磁盘是整机共享资源,一旦写满,同机器所有要写盘的服务、数据库、系统全遭殃。本文讲透日志轮转与磁盘…- 0
- 0
-
我的服务平稳跑了整整三个月却突然全线崩溃,排查到最后发现根因竟是磁盘被一个日志文件写满了,我对着日志轮转和磁盘监控告警排查了大半天的复盘
一个深夜,上线后稳稳跑了三个月、我几乎忘了它存在的服务毫无征兆全线崩溃:数据库写失败、日志写不进、临时文件创建失败、健康检查全红。我顺着这些表面错误查数据库、网络、代码,折腾大半天毫无头绪,直到登服务器敲了 df -h 看到刺眼的 100%——磁盘满了,而把它撑满的是一个从没人管、一直疯长的日志文件(单文件 98G)。根因是日志默认只往末尾追加、从不轮转就无限增长,加上线上开了 DEBUG、打全量…- 0
- 0
-
服务突然大面积报错、写文件上传写库全线失败,登上机器 df 一看磁盘竟然满了:日志从上线起从没切割清理、悄悄撑爆整块磁盘的全线崩溃避坑复盘
这是一次让我印象极深的全线崩溃,它崩得又突然又广,广到我一度以为服务器中毒了。某天下午我们的服务毫无征兆地开始大面积报错,而且错误五花八门毫无规律:有的请求报写文件失败,有的报上传失败,甚至连数据库写入都开始报错,日志里 No space left on device 设备上没有剩余空间这行字疯狂刷屏。我懵了:这几个功能八竿子打不着怎么会同时出问题?直到我登上服务器敲下那个运维排查的第一反应命令 …- 0
- 0
-
凌晨全站报证书错误:HTTPS 证书过期避坑复盘
那是一个毫无征兆的清晨,监控告警在凌晨突然炸响:所有客户端访问我们的服务全线失败,APP 报网络错误,网页打开是一个大大的红色警告页 NET::ERR_CERT_DATE_INVALID。可我们的服务器明明好好地跑着,代码一行没动数据库也正常,后端日志甚至没什么异常——服务活着,可外面所有人都进不来。盯着那个错误看了几秒,一个被遗忘已久的念头猛地窜上来后背瞬间发凉:证书过期了。我们网站的 HTTP…- 7
- 0
-
日志撑爆磁盘服务全线崩:磁盘写满避坑复盘
一个安静的凌晨告警把我从睡梦炸醒:核心服务全线挂了,不是某个接口慢而是所有功能一起瘫痪,下单失败、查询报错、连健康检查都过不了。迷迷糊糊登上服务器想看日志,第一条命令就当头一棒:cannot create temp file: No space left on device,磁盘满了,df -h 一看根分区赫然 100% 一个字节空闲都没有。可这台机器磁盘几百 G 平时用量才三十几,怎么一夜就被塞…- 0
- 0
-
手动好用 cron 却出空备份:定时任务避坑全复盘
一次例行回滚演练,我胸有成竹去拿前一晚的备份,打开目录却整个人凉了:最近好几天的备份文件全是 0 字节空壳,而这段时间监控没有一条告警,cron 的退出码忠实地记录着"成功"。第一反应是脚本坏了,可拷到终端手动一跑,几百兆数据稳稳生成——同一个脚本,我手动跑就好,cron 跑就出空文件。盯着 crontab 看了半天才回过味:问题不在脚本逻辑,而在 cron 把它丢进了一个和登…- 0
- 0
-
一次发布把服务全杀了:K8s 健康检查与滚动更新的坑
一次寻常的版本上线,滚动更新刚启动,Pod 就一个接一个跳进 CrashLoopBackOff,可用副本像退潮一样往下掉。可 exec 进容器手动 curl 健康接口明明是 200——没有一行业务代码出错,凶手是一段从别处抄来、从没认真理解的健康检查 YAML。从这次"配置杀人"事故出发,这篇文章把 liveness/readiness/startup 三种探针的区别、探针阈值…- 3
- 0
-
Nginx 反向代理完全指南:从一次"灰度发布把会话切串了"看懂 proxy_pass 的尾斜杠为什么这么重要
2023 年我维护一个内部 API 服务用 Nginx 做反向代理前面挂着多个上游应用上线一年多一直很稳直到某次产品要做个大功能上线灰度需要按用户 ID 把 10% 的流量切到新版本服务我心里很笃定 Nginx 配置嘛简单加几个 upstream 加个 split_clients 切流量就行可等真把这套上线一串问题冒了出来第一种最先把我打懵新版本上线后旧版本依然有零星 504 客户端报 upstr…- 6
- 0
-
Nginx 反向代理与负载均衡完全指南:从一次"后端挂了一台、用户每三次请求就撞一次 502"看懂代理层
2022 年我给一个后端服务加了 Nginx 做负载均衡。原本服务只有一台机器扛不住量我加到三台前面挂一个 Nginx 分流。第一版我做得很省事写一个 upstream 把三台后端的地址填进去 location 里 proxy_pass 一指完事。本地一测真香请求轮着打到三台机器负载看着挺均匀。我心里很踏实负载均衡嘛不就是 upstream 里写几个后端地址 Nginx 自动帮我分流。可等它真正上…- 0
- 0
-
SSH 免密配了却还要密码:一次 Linux SSH 排查与加固复盘
SSH 免密配完一登录还是要密码,公钥内容反复核对没错,问题竟在 .ssh 目录权限上。排查梳理:免密的公私钥原理、ssh-copy-id 标准流程、SSH 拒绝过松权限的安全铁律、ssh -v 看穿握手、~/.ssh/config 管理多机,以及禁 root/禁密码/改端口/fail2ban 安全加固。- 0
- 0
-
页面间歇性 502:一次 Nginx 配置排查的复盘
上线后页面间歇性打不开、随机 502/504,后端监控却一切正常。问题在最前面那层平时没人碰的 Nginx:upstream 残留死节点、超时参数误判、缓冲区过小。几天梳理 Nginx 配置:502/504 排查、location 匹配优先级、文件上传 413、性能安全加固、监控告警。- 6
- 0
-
日志打爆磁盘:一次 error.log 涨到 388G 的周末宕机复盘
周末凌晨核心服务集体宕机,报 No space left on device——磁盘被写满。罪魁是一个 ERROR 日志在异常风暴里疯狂打印,几小时灌满几百 G 磁盘。几天治理:配 totalSizeCap 总量上限、异步日志 neverBlock 保业务、异常日志限流、日志级别梳理、磁盘与 ERROR 速率三级告警。- 3
- 0
-
生产服务器 Too many open files:文件描述符与连接泄漏排查实录
API 网关周一早高峰刷屏 Too many open files,机器上堆了 5.2w 个 TIME_WAIT、3.8w 个 CLOSE_WAIT,fd 被占满。一周治理:ulimit 三层调优 + TIME_WAIT 内核参数 + 连接池长连接复用 + somaxconn 队列调优 + arthas 定位 close 泄漏。4 实例扛住 3 倍流量再没复发。- 0
- 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
-
Linux Page Cache 实战:日志服务 p99 从 200ms 降到 8ms
日志服务每天 200GB,半年后 IO util 95% p99 200ms。本文讲透 Linux Page Cache / Dirty Page / fsync / O_DIRECT / mmap / io_uring 底层机制 + iostat/iotop/blktrace 诊断 + 批量缓冲 + 内核参数调优 + posix_fadvise,p99 降到 8ms。- 0
- 0
-
线上 TCP CLOSE_WAIT 堆积排查实录:5 个方法定位到应用层 bug
网关 8 小时后 CLOSE_WAIT 几万个、接口大量超时。本文讲透 TCP 状态机 + 5 种诊断方法(ss/lsof/arthas/tcpdump/bpftrace)+ Apache HttpClient / Jedis / Tomcat / Netty 4 个真实泄漏案例 + 内核参数误解辟谣 + 监控告警 + 预防 checklist。- 2
- 0
-
线上服务周期性 Too many open files:fd 泄漏完整排查实录
服务跑 7 天集体崩,日志全是 Too many open files。本文写实记录排查:/proc/fd + lsof + ss + bpftrace + arthas + heapdump 定位到第三方 SDK 没 close,每天泄漏 9000 个 fd。附 Java/Go 4 种泄漏模式 + 系统层防御 + CI 检测规范。- 0
- 0
运维
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×