记一次线上问题及反思

背景介绍

咱们团队是作程序化广告的，我所在小组主要作 DSP 方向，对接外部 ADX，提供广告检索服务（对广告系统不熟悉的不要着急，后面有时间会给你们分享广告相关的文章）

10 月 21 日上线了一个支持头条的需求，其实主要就是在展现和点击监控连接中增长了一个宏，好比请求 url 为：xxx.com/n/d/?fid=aaa&h_oaid={OAID}，当咱们的广告竞价成功后通常就会展现到头条上，当广告展现后，头条会给咱们发送展现通知，若是用户点击后，也会给咱们发送点击通知，这样咱们就能够根据这些回调进行计费。但当我晚上上完线后，陆续收到了线上报警，广告曝光比前一天同时刻降低超过 50 % 的报警。觉得是上线波动致使，就继续上线了，半夜十二点左右报警愈来愈频繁 ......

排查过程

10 月 21 日 半夜

经过看监控平台，发现获胜数据是正常的，只是展现和点击出了问题，而后看业务日志（其实咱们排查的过程有问题，应该先看 tomcat 请求日志的），发现头条的展现和点击回调没有请求过来，但此次需求只是在 url 中增长了 h_oaid={OAID}的宏呀，难道是它影响了？

此时能够回滚的，但是回滚比较麻烦，咱们采起的方式是把本次上线的宏去掉后从新上了一版，发现问题解决了，至少止损了，先睡觉吧，次日再排查

10 月 22 日

22 号到了公司开始联系头条方但愿可以一块儿排查下，由于咱们怀疑是连接中新增长了宏，可能头条方没有给咱们发起回调，咱们给对方提供了一些惟一请求标识，通过一段时间的排查和沟通，发现头条确实给咱们发了回调请求，可是他们没有把宏给替换，因此返回的 url 请求中依然带着 {OAID} 这个宏，并且咱们返回的状态码是 400，重点来了。咱们猜想难道是特殊字符 { 和 }影响了？（这里也暴露了一些知识点的匮乏），赶忙查看 tomcat 的日志，果不其然，日志早就已经说明了问题，只是一直没关注系统系统，光看业务日志了。

经过异常信息，咱们能够知道是特殊字符违反了 RFC 规范，因此咱们把 {OAID} 去掉后解决了问题，正常应该是头条帮咱们把宏替换掉的，这样就不会有违反规范的特殊字符，请求也就能够正常响应了

解决过程

经过查资料，咱们发现 tomcat 的一些版本仍是容许请求 url 中带有 |，{，} 这三个特殊字符的，只是须要修改下配置文件，以下

tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}

该配置在 tomcat 一下版本生效

- 8.5.x for 8.5.12 onwards
- 8.0.x for 8.0.42 onwards
- 7.0.x for 7.0.76 onwards

咱们线上的 tomcat 版本是符合的，只是咱们没有采起这种修改配置文件的方法，只是先把宏给去掉了，等头条上线最新的替换宏的代码，咱们再次上线

固然后面咱们从运维团队要到了出问题时间段的 nginx 请求日志，过滤出有问题的请求，而后从新跑数计算影响了多少数据，这个从新跑数的过程也须要扎实的 linux 基础和对业务的深刻理解，由于最开始对业务理解不足，跑的数据是有问题的。

反思

前面说的有些啰嗦了，其实就是请求 url 中带有特殊字符，违反了 RFC 规范，致使返回 400 状态码，这暴露出该知识点处在个人知识盲区，并且应该早些查看 tomcat 系统日志，而不是一直关注业务日志，毕竟请求进入到 tomcat 后，才会有业务日志。

通过此次线上问题，总结下个人反思

1.必定要敬畏线上报警短信，既然报警必定是有缘由的
2.自测的时候，多测试一些 bad case ，固然这也取决于本身的知识点和经验
3.排查问题，不能太依赖业务日志，要遵循一些流程，从根源查找问题缘由
4.在对接外部系统时，必定要沟通好，考虑全面些
5.不断完善本身的知识库，固然这也须要不断踩坑的经验积累
6.要对业务深刻理解才能写出正确的代码
7.团队的力量是强大的，期间很是感谢个人队友们的支持

欢迎关注公众号 【天天晒白牙】，获取最新文章，咱们一块儿交流，共同进步！