我报名参加金石计划1期应战——瓜分10万奖池，这是我的第3篇文章，点击检查活动概况
一次惊险的线上事端记载
起因：
最近上线了一版关于灵敏内容过滤的一个需求，深夜上线时，全部正常，but….在第二天正午时段，突然报警并有线上反应相关功用有问题，查elk日志显现相关接口耗时很大，并且有部分连接都超时了（包括redis mysql 以及部分调用外部的http请求也是，体系呼应巨慢，往常几毫秒十几毫秒的接口，突然变的无比的慢）本来是午饭午休时刻，可是看到这些问题，瞬间我就清醒了，吓得我浑身哆嗦。
排查
说清这次排查，因为是线上，所以没有直接dump线程文件啥的，而是先看日志，看监控表盘，能够说监控表盘已经很明显了。 因为是事后补稿子，所以这儿象征性找几张其时截下来的图片看看
看监控仪表盘检测体系各项目标
-
cpu tcp 相关状态图
-
文件描述符相关监控图：
-
内存与线程状态图：
-
一些说明：
- 首先其时上线后，问题不是立马就呈现的，说明体系有一段时刻是在 “蓄积”，其实许多连接 cpu 或许关于gc的问题都会这样，会有一个蓄积的过程，直到到达某个点或许某个规模，影响开始可视化！！
- 从以上三张图能够看到，文件描述符运用很高，线程许多timed_waiting ，cpu内存等都不太正常，可能有些不正常是因为受某个不正常因素的间接影响导致，总归我们知道体系存在问题就对了。
- 在7月9号正午左右，我们重启了下服务，发现异常现象比方：文件描述符，cpu,线程，tcp一些不正常的目标直接就降下来了。然后在10号清晨发布了bugfix版本
剖析elk中相关功用的日志
- 因为看日志这儿涉及到隐私，而且其时内容没截取全，所以这儿不贴图了，简略文字描述下：
一、大致逻辑如下： 1:拿到要检测的内容->2:(运用腾讯 sdk)构建调用目标（cosClient）->3:调用腾讯灵敏检测相关接口->4:回来。
二、而经过观察日志发现在（2）处用时好久，大约占整个接口的90%乃至更多 ，所以我赶紧看了看这块的代码。 三、代码很简略，便是构建cosCleint目标，来调用对应的api(sdk形式调用) ，我一步步跟了进去，发现里边做了许多作业。四、时刻原因 详细细节我也没一点点debug，所以我把希望转向了腾讯的文档，翻开文档无意间我发现有这么一段描述：
处理发现的问题
看完这段我终于理解哪里出了问题，所以赶紧将每次都new一个调用目标改成单例的（fuck…..没想到是因为这个疏忽。。。。正符合了那句话：大意失荆州啊！我没想到会在这块上绊倒）
在bugfix版本中，我将new目标改成如下这段代码：
Singleton.get(XXX.class, yyy, zzz);
发版后问题得到处理。回家睡觉！
总结
- 经过本次线上事端，我理解了四点：
- 日志，监控体系以及打印精准有用的日志是多么的重要！
- 体系上线后要有段观察期，不能说其时检验没问题就全部ok了。
- 与外部对接的东西，一定要仔细阅读对接或接口文档，保证无遗失。
- 敬畏每一行代码，对每一行代码都有考虑！！！
