聊聊后端服务监控

研究haproxy过程中，发现自带一个监控后端服务宕机并邮件报警功能，感觉挺实用，有点小遗憾的是发邮件的邮件服务器必须关闭用户认证，163，qq等大众邮箱是不可能使用的，只能自己搭建邮件服务器。之前在用nginx的时候也想过邮件报警功能，可惜没发现nginx自带，估计是要自己写模块了。在与群友的交流中，感慨其实能做监控并报警的地方有很多，就看你怎么理解了。大部分的应用架构中，一般是一个前端负载拖着若干个后端服务。监控并报警的功能可以有3种实现场景：

1.独立第三方监控

  很多公司的首选，如果是物理机房交流的比较多就是zabbix，如果是云主机，国内的比如阿里云，可以用他们自带的监控。第三方监控一般都有图形化的界面，看起来很直观。这也许就是很多公司首选的原因。唯一有点遗憾的就是监控必需和后端主机在同一个局域网内，才能保证监控报警的准确性。如果跨地域监控，网络抖动引起的误报也是很头疼的。曾亲身经历过主机架设在新加坡，监控点放在香港，因为网络延迟较大，产生大量误报。

2.负载层面的监控

   用过nginx与haproxy，他们都能对后端服务做监控，当后端一台主机宕机的时候，能自动将请求转发到其他主机，这个时候如果直接报警，肯定比第三方监控判定的下线故障时间更加精确。但是业务不影响，因为请求都转发到其他正常的主机了。因为监控是附带的功能，不可能有专业的图形化界面。

3.后端服务本身的监控

    前面说的两种都是从外部对后端服务进行监控，大部分情况下完全够用了，有极小概率会产生误报。后端服务到底挂没挂，严格来说从内部去分析会更加合理。线上跑java服务的时候，经常会因为OutOfMemoryError，导致服务宕了。这个时候可以在程序启动的时候挂个hook，一旦OutOfMemoryError，直接发报警邮件更加精确。但是并不是所有导致服务挂了的error都能在hook中处理。