Docker json-file 日志轮转未生效：从磁盘告警到恢复服务的排查实践
## 适用场景 Docker 默认使用 `json-file` 日志驱动。运行一段时间后，宿主机 `/var/lib/docker` 持续变大，最终出现磁盘告警，甚至应用写文件、创建临时目录或重启容器都失败。本文适用于单机 Docker、Docker Compose 以及未由集中日志系统完全接管容器标准输出的场景。
Tag
#Linux
包含这个标签的文章。
Linux conntrack 表满导致偶发网络超时：从现场确认到容量治理的排查实践
## 适用场景 业务运行在 Linux 主机、Docker 或 Kubernetes 节点上，经过 NAT、iptables/nftables 防火墙或四层负载均衡转发。某个时段开始出现 API 偶发超时、DNS 请求失败、容器无法访问外部服务，但主机 CPU、内存和带宽看起来都正常；重启网络或重启节点后短暂恢复。
Redis 延迟偶发飙升：从 Hot Key 与 Big Key 定位到分阶段治理实践
## 适用场景 业务使用 Redis 承载登录态、商品详情、计数器或排行榜。平时接口稳定，但在促销、定时任务或某些请求集中到来时，应用开始出现 Redis 超时；监控中 `instantaneous_ops_per_sec` 并不一定很高，CPU 也可能没有持续满载。 本文以单实例或主从架构为例，说明如何区分 **
Kubernetes 内部域名间歇解析超时：CoreDNS 缓存与上游 DNS 的排查实践
## 适用场景 集群中的应用偶发报出 `lookup xxx on 10.96.0.10:53: i/o timeout`、`SERVFAIL` 或连接外部服务失败；重试后又恢复。故障通常集中在业务高峰，Pod 重建、扩容或切换节点后更明显。本文适用于使用 CoreDNS 作为集群 DNS，且 CoreDNS 需要转
Nginx 间歇性 502：upstream keepalive 陈旧连接的排查与治理实践
# Nginx 偶发 502 且上游日志正常：upstream keepalive 陈旧连接的排查与治理 ## 适用场景 服务部署在 Nginx 反向代理之后，流量高峰或发布后偶发 `502 Bad Gateway`。Nginx 错误日志出现 `upstream prematurely closed connect
Docker 容器频繁 OOMKilled：从 cgroup 内存指标到限额配置的排查与治理实践
## 适用场景 服务容器偶发或持续重启，`docker ps -a` 显示退出码为 `137`，应用日志末尾没有 Java、Python 或 Go 自己抛出的异常。宿主机看起来还有可用内存，但容器仍被杀掉；或者一次流量高峰后多个容器同时不可用。 本文以 Docker / Docker Compose 部署的 API
Linux 磁盘空间充足却无法创建文件：inode 耗尽的排查与治理实践
## 适用场景 应用报出 `No space left on device`，但 `df -h` 显示磁盘使用率不高；Nginx 无法写入访问日志、容器无法创建临时文件、CI 构建失败，甚至 `touch` 一个空文件也失败。这通常不是字节空间耗尽，而是文件系统可分配的 inode 已经用完。 本文以 ext4/X
systemd-journald 限流导致关键日志丢失的排查与治理实践
## 适用场景 服务运行正常，但在故障窗口里 `journalctl` 中恰好缺少应用最关键的一段日志；常见于 Java、Python、Nginx/OpenResty、容器运行时或短时间大量报错的 systemd 服务。运维人员往往把它误判为程序没有输出，实际日志可能已经被 `systemd-journald` 的限
Docker overlay2 目录持续膨胀：从可写层定位到安全回收的排查实践
## 适用场景 Linux 宿主机的根分区或 Docker 数据盘持续告警，`/var/lib/docker/overlay2` 占用不断增加；但镜像和容器数量并不多，普通镜像清理也没有效果。本文给出 overlay2 的归属定位、止血和治理流程。 > 以下路径以 `/var/lib/docker` 为例。先用 `
Kubernetes HPA 不扩容：从 metrics-server 指标缺失到恢复弹性的排查实践
## 适用场景 部署在 Kubernetes 中的 Web、API 或消费服务在高峰期 CPU 已长期接近上限，但 HorizontalPodAutoscaler（HPA）始终保持原副本数；也可能在 `kubectl get hpa` 中看到 CPU 显示为 `<unknown>`。本文以基于 CPU 利用率的 HP