MySQL 主从复制延迟持续扩大：从现场取证到并行复制治理的排查实践
## 适用场景 本文适用于 MySQL 8.0 或已启用 GTID 的 MySQL 5.7 主从/主备架构：监控显示 `Seconds_Behind_Source` 持续增长，报表、读库或故障切换的恢复点开始不可接受。目标是先确认延迟真实原因，再在不破坏复制一致性的前提下恢复追平。 ## 现象描述 一次订单促销后
Tag
#监控
包含这个标签的文章。
Linux 时间漂移导致 JWT 校验失败与 TLS 握手异常：从证据采集到 chrony 治理
## 适用场景 适用于运行在 Linux 虚拟机、物理机或容器节点上的 Web 服务。业务表现为同一版本在部分机器上间歇出现登录失效、JWT `token is not active` / `token expired`、HTTPS 握手失败或调用云 API 返回签名过期；重试、重启应用有时短暂恢复，但问题会再次出现
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 需要转
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` 的限
Kubernetes HPA 不扩容：从 metrics-server 指标缺失到恢复弹性的排查实践
## 适用场景 部署在 Kubernetes 中的 Web、API 或消费服务在高峰期 CPU 已长期接近上限，但 HorizontalPodAutoscaler（HPA）始终保持原副本数；也可能在 `kubectl get hpa` 中看到 CPU 显示为 `<unknown>`。本文以基于 CPU 利用率的 HP
Redis replication backlog 不足导致频繁全量同步的排查与治理实践
## 适用场景 Redis 采用主从复制，业务高峰时偶发写入延迟、主库 CPU 或网络突刺。日志中反复出现 `Full resync requested`、`Partial resynchronization not accepted`，从库短时间内加载 RDB，甚至与主库断开后很久才恢复。 本文适用于 Redis