运维经验谈在vultr日本机房死了 情况下的日志分析与根因定位

1. 概述：事件背景与影响范围

发生时间：2025-03-12 03:08 — 多台 VPS 在 Vultr 日本（Tokyo/NRT）机房出现“死机/不可达”。
影响对象：应用层不可达（HTTP 504、TCP 握手超时），部分实例能够 SSH 但响应极慢。
影响规模：客户报告约 35 台实例出现不同程度的网络中断或高丢包。
影响业务：网站卡顿、API 超时、用户连接大量失败。
初步假设：可能是网络层（上游/交换机/防火墙）或主机内核资源耗尽（conntrack/NETfilter/OOM）。

2. 日志抓取与初步排查步骤

从可达实例拉取日志：/var/log/messages、dmesg、journalctl、nginx/access/error、iptables、sar。
网络状态检查：ip addr、ip link、ethtool eth0、ss -s、netstat -an | grep SYN。
内核日志重点：dmesg | egrep -i "conntrack|nf_conntrack|table full|drop|oom"。
资源监控：top/htop、vmstat、iostat、sar -n DEV 1 5，收集 1 分钟粒度数据。
流量抓包：tcpdump -n -s 96 -w /tmp/cap.pcap 'tcp port 80 or tcp port 443'（注意抓包会增加负载，谨慎使用）。

3. 真实日志片段与关键证据

dmesg 关键行示例（原文摘录）：
[ 123.456789] nf_conntrack: table full, dropping packet.
[ 123.457012] nf_conntrack: overflow, consider raising conntrack hashsize.
[ 125.002345] NETDEV WATCHDOG: eth0: transmit queue 0 timed out
ss 与 netstat 输出示例：
Netid Recv-Q Send-Q Local Address:Port Peer Address:Port State
tcp 0 4096 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 1 10.0.0.5:80 1.2.3.4:56789 SYN_RECV
以上日志指向 conntrack 表满导致新连接被丢弃，进而出现大量 SYN_RECV（半开连接）。

4. 案例实例与服务器配置示例

真实客户节点示例（局部脱敏）：
操作系统：Debian 11 (kernel 5.10.0-20)；虚拟化：KVM/QEMU (Vultr)。
实例配置：2 vCPU / 4 GB RAM / 50 GB NVMe / 公网 IP (eg. 138.XXX.XXX.XX)。
运行服务：nginx 1.18 + PHP-FPM + 自研 API；并未使用 CDN 或上游 DDoS 代理。
观察到的运行指标（故障时）：平均负载 2.6、conntrack_count=65534 (max=65536)、netstat TIME_WAIT 大量堆积。

5. 数据表：故障前后关键指标对比

指标	故障前	故障时	处置后
conntrack_count	12,432	65,534	18,215
平均响应时间 (nginx)	120 ms	>5,000 ms	150 ms
SYN_RECV 连接	~50	>20,000	80
丢包率（外部监控）	0.2%	>15%	0.5%

6. 根因定位与技术分析

证据汇总：内核提示 conntrack 表满 + 大量 SYN_RECV + 外部监控显示短时流量峰值。
直接根因：遭受基于连接耗尽（SYN 风暴/应用层短连接高并发）的攻击，导致 nf_conntrack 表被快速耗尽。
诱发条件：实例未使用上游 CDN 或 Vultr DDoS 防护、默认 conntrack 限制偏低（net.netfilter.nf_conntrack_max=65536）。
次要问题：应用长时间保持大量短连接，TIME_WAIT 积压，内核参数未调优，未开启 SYN cookies 与合适的 tcp_backlog 设置。
综合结论：属于典型的连接耗尽型事件（资源限制 + 外部攻击/流量异常共同作用）。

7. 修复措施、缓解与长效方案

紧急缓解（立即生效）：临时增大 conntrack：sysctl -w net.netfilter.nf_conntrack_max=200000；清空 conntrack（慎用）：conntrack -F。
内核调优：sysctl 设置建议：net.netfilter.nf_conntrack_max=200000、net.ipv4.tcp_syncookies=1、net.core.somaxconn=4096、net.ipv4.tcp_max_syn_backlog=4096。
防护策略：部署 CDN 或云端 DDoS 防护（将源站隐藏在 CDN 之后），在边界启用速率限制与黑名单。
iptables/nftables 协同：加入 SYN 限速规则（例如：-m connlimit、-m limit、--limit-burst），并使用 fail2ban 或 ipset 快速拉黑源 IP 段。
运维建议：建立 conntrack 报警（Prometheus + node_exporter conntrack_exporter），常态化压测并设限，定期演练流量激增场景。

来源：运维经验谈在vultr日本机房死了 情况下的日志分析与根因定位