管理Http ERROR的“圣剑”

做过运维的小伙伴都知道，管理Http ERROR是一个即耗时又耗力的痛苦过程，但是公司的老大们根本不会关注这些，他们只会不断的告诉你，” ××用户访问出问题啦，看看是啥问题？”，”最近系统怎么样，有没有什么报错？”。俺们总不能盯着日志瞅一天吧，阶段性读日志的时候，信息又太多，可读性很差。很多情况下，我们真是压力山大啊！ 

下面是我们的一个系统架构图(简图)，相信很多互联网公司都是使用类似的架构: 以前，我们定位一个问题的过程往往是这样的:首先需要查看nginx的error.log，如图所示：

如果根据ngix日志没有办法直接定位问题所在，还要再结合查看tomcat的error log分析有没有程序的问题。     

      

如果说，我们在日志中发现一个空指针类型的Error。想修复这个问题的话，俺们运维的人员可搞不定，还需要拿着日志找研发，再分析代码逻辑，最终才能修复这个问题。  

对我们运维来说，每次遇到这些问题，就说明我们“摊上事了，摊上大事了”，老大根本不会在乎你平时有多努力，多拼命，他只知道这事得找你搞定，搞不定的话，后果可想而知。所以，我们也想过的轻松一点，于是我们就“外事问谷歌，内事问百度”，然后再问问我们同行业的小伙伴们，最终开始关注APM的解决方案。其实，国内很有很多家做APM的公司，在经过对比分析以后，我们发现了一家公司OneAPM提供这项服务，选择他们主要就是因为他们的部署比较简单，另外就是成本也不高。当然，还有其他综合的原因。我们分享一下使用OneAPM的一点体会，仅供大家参考。

 使用OneAPM管理Http ERROR后，点击3下搞定问题:登陆OneAPM账号，就会看到监控的Application如图：

从图1.的地方，很容易的看到在08:00到14:00时间内Error发生的次数和占据的比例，点击”图2.事件”进入Error的详细页面：

进入到错误信息的页面，会看到08:00到14:00时间段内的每一次Error信息和trace列表。下方的列表中就展示了的最近的几个错误:uri发生了java.lang.NullPointerException，捕获到3次错误及发生该错误的Http请求。我们点击箭头指示的uri跟进对应的代码行信息，如下图：

然后，很轻松的就定位到2015年4约7日 11:50发生的这次Http ERROR，请求参数为URI://http-bio-b2bo-exec-5，在代码java：54出现了Error。迅速搞定！  

整体来讲，他们服务的效率是非常高的，使用也很简单、直观，给我们运维同学节省了老多的时间了，然后老大也不会整天盯着我们追问了，给我们帮了这么大的忙，必须夸他们两句：用OneAPM产品管理Http的Error的效率真的很高，传统的解决Http Error流程比较繁琐，需要通过逐行查看相关日志，去代码中追踪问题，过程比较缓慢。而且对于我们公司的CTO和开发人员也很有帮助，能够很直观的看到公司业务错误情况， 他们目前支持的语言也很多，包括java、python、.net、 Node.js、PHP、Ruby等等。不知道未来还不会支持其他的语言，但是一般的公司肯定是够用的。

欢迎大家有好的解决方案一起分享！