Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

浅谈服务监控

  有股票就得有证监会,有银行就得有银监会,有保险就得有保监会,缺乏监管会就变得越来越奇怪。同样的,有服务就得有监控!要不然你怎么放心让它在外面跑?怎么知道它挂了没?如果一个服务不仅不能保证自己的运行状态,甚至连服务挂了都没人知道,那这样的服务谁敢用?
  服务监控是一个很大的领域,各种监控、报表、报警,这一大堆东西很少有哪个服务有完美的实现。很多监控方案都是把具体需要监控的指标通过 SDK 的形式耦合到代码中,我觉得这样并不好。因为代码是人写的,人类是不可信的。代码本身都可以有 Bug,更何况是代码中的监控呢?所以我觉得,非侵入式的监控才更靠谱。
  通常服务间的通信都是走 Socket,而且服务提供的接口和服务所依赖的接口都是已知的通信协议,如果我们劫持网络流量,根据它的通信协议来分析它到底做了哪些事情,这样就可以对服务的调用进行全面监控了。这个饼虽然画得挺圆,但实现成本比较高,可能需要额外的硬件资源,而且可能增加服务的风险(其实侵入式的监控也同样有风险,应该说任何监控都有风险)。
  如果只对服务的调用做监控,我们可能会看到某个服务的调用突然掉底,因为服务挂掉了。等到服务挂掉后再去解决问题就太晚了,所以除了监控服务的调用外,还得对服务器资源本身做监控。监控服务器的 CPU 使用、内存使用、硬盘空间等。如果是物理机,可能还需要监控到温度之类的层面。这样在服务器快扛不住时我们就能提前知道,提前对其扩容。
  如果服务是混部的,也就是一台服务器上部署了一大堆应用,那么对机器资源的监控就会很困难。因为可能是某个服务的故障导致了某种资源被消耗殆尽,然后扩容就要在新的服务器上把其实根本用不了那么多服务器的服务也一并扩容。甚至有时候混部的服务器出了问题都不知道是哪个应用引起的,给 Debug 也带来困难。所以我觉得只有先避免服务混部才可以真正做好监控。
  我对监控这个领域的认知还是非常粗浅的,上面两个切入点算是我目前觉得比较重要的吧。如果大家有什么更好的见解,欢迎分享。
网名:
3.84.186.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^