在2019-02-06 日下午,zabbix突然出现大量unreachable的告警。

处理过程如下(嫌长可以直接从第11开始看):
1.检查几个告警机器发现有不少断图;
2.检查队列发现有台proxy有大量积压,确认为单点proxy异常非server异常;
3.proxy服务器的CPU/内存全部正常;
4.检查proxy日志有大量“first network error, wait for 60 seconds” 报错;
5.怀疑可能proxy配置参数不够(以前的经验),根据服务器当前容量调大了proxy的部分cache并新增了部分poller数量。
6.第5部完成后重启proxy,观察10分钟,问题未解决。
7.重新思考,已确认的是因为队列积压导致断图,遂开始寻找队列积压原因;
8.检查proxy和server的数据库,负载正常,非数据库引发。
9.检查服务器的流量,发现从15:40开始proxy所在服务器的进/出口流量有陡降。确认是因为proxy无法将数据及时推送到server导致的大量队列积压。
10.netstat检查连接数正常。
11.查看 /var/log/messages 发现从15:40开始有大量“nf_conntrack: table full, dropping packet” 报错,时间吻合,定位原因。
12.修改net.nf_conntrack_max 与 net.netfilter.nf_conntrack_max 参数调整至262144。sysctl -p 后错误日志消失。(感谢eric大佬支持)
13.检查服务器流量,恢复正常,积压队列数量开始降低。
14.故障消失。

故障总结:
直接原因:net.nf_conntrack_max 配置不够,导致的服务器网络不稳定。
综合原因:
1.这台proxy本身配置较高,后面挂了3754个hosts,需要 1329.35的vps,所以本身有大量的链接。
2.linux nf_conntrack_max的默认值较小。



如果想赏钱,可以用微信扫描下面的二维码,一来能刺激我写博客的欲望,二来好维护云主机的费用; 另外再次标注博客原地址 itnotebooks.com 感谢!

CI/CD(五)Flink 应用部署

环境 代码托管:gitlab CI:tekton CD: tekton pipline/task: 阿里云 serverless容器(spot实例且按秒计费) 应用:K8S Flink 应用需要解决的是任务的灵活增...

阅读全文

CI/CD(四)VM 应用部署

环境 代码托管:gitlab CI:tekton CD: 代码自实现多批次部署 pipline/task: 阿里云 serverless容器(spot实例且按秒计费) 应用:ECS(ESS) 应用部署在弹性...

阅读全文

CI/CD(三)GPU 应用部署(k8s)

环境 代码托管:gitlab CI:tekton CD: ArgoCD pipline/task: 阿里云 serverless容器(spot实例且按秒计费) 应用:k8s GPU应用的特殊性在于单个镜像的大小在...

阅读全文

1 条评论

欢迎留言