记一次线上超时的分析、排查过程
在上一篇文章问题解决了，我却不知道原因中提到，近从性能、监控方面对引擎进行优化，这不，监控刚上了，就发现了一个很严重的问题--超时。
今天，借助此文，分享下该问题的发现、排查以及解决过程！
业务背景
在广告业务中，分为效果广告、KA广告以及三方广告等。效果广告和KA广告一般都仅限于内网，也就是说在内网中通过RPC进行访问，而三方广告，则需要访问外网，因为外网环境以及每家三方广告主的处理能力不同，导致性能不同。本次的超时就是针对的某个三方广告主。
本次针对三方的业务监控中，包括对三方广告主的请求数、返回数、qps、rt等指标。
收到报警
增加了监控的业务上线后，根据引擎监控系统来查看三方的基础数据监控，如下：
通过上述图表，看了下平均rt等业务指标，一切正常。开始着手配置超时等监控报警指标。鉴于业务的重要性，配置了邮件告警和短信告警两种，配置完成后，一键生效。结果，过了没几分钟，就收到了告警。
看到超时这么多，时间先ping下，看看网络间耗时咋样，结果如下：
64 bytes from 114.67.237.131: icmp_seq=1 ttl=49 time=7.13 ms
64 bytes from 114.67.237.131: icmp_seq=2 ttl=49 time=6.37 ms
64 bytes from 114.67.237.131: icmp_seq=3 ttl=49 time=6.10 ms
64 bytes from 114.67.237.131: icmp_seq=4 ttl=49 time=6.07 ms
64 bytes from 114.67.237.131: icmp_seq=5 ttl=49 time=6.04 ms
64 bytes from 114.67.237.131: icmp_seq=6 ttl=49 time=6.07 ms
64 bytes from 114.67.237.131: icmp_seq=7 ttl=49 time=6.03 ms
64 bytes from 114.67.237.131: icmp_seq=8 ttl=49 time=6.09 ms
64 bytes from 114.67.237.131: icmp_seq=9 ttl=49 time=6.11 ms
64 bytes from 114.67.237.131: icmp_seq=10 ttl=49 time=6.03 ms
64 bytes from 114.67.237.131: icmp_seq=11 ttl=49 time=6.07 ms
相关文章