当我们谈论监控时,我们在谈论什么?

我们想像中的监控?

我们想像中监控无所不能,是个超人。需要什么数据,它就能给我们什么数据;需要找到故障根源,它就能及时告知我们故障根源。

现实中的监控

可事实上并非如此,我们对监控寄予了太多,想到的就加上去,导致它越来越胖,越来越臃肿,但似乎并未解决我们的问题。

目前的监控平台和工具都很多,开源的、商业的、甚至我们自己开发的,但都真正的解决了我们的问题吗?

种类多样的监控工具

所以,多并不意味着好,或者说多并不意味着有用。真正解决问题即可,而不是将有用的没用的监控一股脑的全部搞出来,这样只会扰乱你的视线,分散你的注意力,影响你分析和梳理故障原因和性能瓶颈。

监控的目的

我们监控的目的到底是什么?一个好的监控需要帮助我们解决以下问题。

  • 掌握系统健康状况
  • 查找故障根源
  • 系统瓶颈诊断
  • 性能调优
  • 排查安全隐患

故障排查过程

故障发生时,我们查CPU、内存、进程、网络等等,同时还要对日志进行问题排查,php日志、apache/nginx日志、负载均衡及数据库的日志,很多时候我们排查日志还是在使用shell命令与脚本,对故障时间点日志进行过滤,整个处理过程都是回溯状态,无法做到实时,显得手忙脚乱还无法让我们尽快发现问题。另外,所有这些都是单点IT资源的问题排查,我们需要将各种监控联系起来分析考虑。 在微服务架构时代,这些单点资源的监控已经无法满足我们的需求。

为什么不理想?

  • 维度单一、排查点太多
  • 无法有效建立联系
  • 日志处理困难
  • 不实时
  • 依赖经验

我们的结论

监控必然面临着以上几个进化,从基础到业务、从静态到动态、从表象到本质。 面向业务的监控不仅仅关注技术层面的单点资源,而是关注整个业务系统的健康状态。 在实际场景中,使用业务监控可以替代技术监控,而且更加简单容易理解。 大量微服务如何同时监控?CPU?负载?显然不是这样。 同时又是我们平台上服务自动伸缩的依据。

业务指标

响应时间

指负载均衡将请求发给后端服务节点,经过处理后,再由后端节点返回给负载均衡的时间。这个值可以有效评估当前服务节点的处理能力并结合吞吐率了解当前前端访问的压力大小。单位是毫秒(ms)。

在线人数

指10分钟内访问你的网站或服务的人数,通过此监控项可以直观了解到在线用户数。

吞吐率

指1分钟内你的网站或服务的总访问次数。

实时服务监控

服务性能分析

  • 多维度
  • 实时
  • 智能

多维度使我们能够从广意上来全盘考虑,不再计较单一的资源情况,再好的把握多种监控数据之间的联系。 实时让我们更快速的了解当前的系统状态,而不是再回溯历史。 智能体现在对数据的处理排序上,抓住影响最大的关键点。

web服务性能分析

对过去5分钟耗时最多的URL进行排行,分析一个web服务当前影响性能的最关键点。

mysql服务性能分析

从我们的经验来说,对于解决数据库的故障问题,查找slowlog并不是最有效的方法,因为不一定最慢的是影响最大的,有些SQL是很慢,但数量并不多,也许1分钟1条,但有些SQL的耗时并不大,可是数量巨大,对性能影响就非常高,而且并不出现在slowlog中,所以综合耗时是关键。

通过服务性能分析可以直观的看到当时的问题url与问题sql,对排查故障根源非常有效。

时间窗口

对于动态实时的监控有一个很重要的概念就是时间窗口

简单来说就是一个 滑动窗口。固定好一个时间窗口对数据进行查询统计。 因为数据流是持续不断的,在对业务进行监控的时候,我们不会对所有的数据感兴趣,而是对“最近五分钟平均响应时间”、“最近十分钟URL排行”以及“当前在线人数”这类问题更关心,要得到这些数据,通过时间窗口对数据的查询计算即可解决我们的问题。

有哪些使用场景

  • 故障提前预知
  • 压力测试
  • 性能调优

监控的终级目的

现在我们回过头来再看看前文中说过的监控目的,这些目的其实都是一个“中间过程”,还停留在“把事儿给办了”的阶段,其实监控的终级目的或者说重要意义是“价值”。 我们不是为了监控而监控,是通过监控产生价值,产出利润。对我们的业务提供帮助,让业务来创造更多的价值。 所以我们不要将问题复杂化,要让复杂变得简单,才是我们的根本。

原文发布于微信公众号 - 好雨云(goodrain-cloud)

原文发表时间:2016-01-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Rainbond开源「容器云平台」

好雨云帮一周问答集锦(11.21-11.27)

1063
来自专栏NetCore

C/S结构和b/s结构的比较

随着软件系统的规模和复杂性的增加 ,软件体系结构的选择成为比数据结构和算法的选择更为重要的因素 ,三层客户/服务器体系结构为企业资源规划的整合提供了良好的框架 ...

2549
来自专栏斑斓

系统架构 | 软件架构的一致性

在Brooks的力作《设计原本(The Design of Design)》一书中,提及“一致性”对软件的重要性。他认为:“一致性应该是所有质量原则的根基。好的...

4257
来自专栏BestSDK

谁说开发APP一定要写代码?有了这些SDK/API想做啥就做啥!

针对行业痛点,国内外涌现出众多APP开发工具,开发者只要有相关的HTML5、CSS和JavaScript知识,便可以轻松快速的开发出属于自己的APP,基于开发工...

3979
来自专栏JAVA高级架构

微服务和传统服务架构

单块架构应用:功能集中,代码和数据中心化,一个发布包部署后运行在同一个进程中的应用程序 单块架构的优势: 1)易于开发 2)易于测试 3)易于部署 4)易于水平...

3898
来自专栏云计算D1net

公有云服务选择八大评测标准

说到选择一家公有云提供商,成本往往是首要因素。但是虚拟机迁移、存储和自动扩展等其他因素也应该加以考虑。 随着许多企业组织迁移到公有云或混合云,它们免不了要选择一...

3896
来自专栏屈定‘s Blog

如何学习一门新技术

最简单的是找一个上手视频,因为视频是非常直观的展示了技术的使用.先学会用是最根本的,对于没有视频的技术的话,就可以搜索XX上手教程,XX学习记录之类的关键词,很...

1943
来自专栏hadoop学习

从零开始学习hadoop之发行版选择

经常会看到这样的问题:零基础学习hadoop难不难?有的人回答说:零基础学习hadoop,没有想象的那么难,也没有想象的那么容易。看到这样的答案不免觉得有些尴尬...

1425
来自专栏机器之心

即将放弃Python 2.7的不止有Numpy,还有pandas和这些工具

36713
来自专栏IT大咖说

华为多年实践:ServiceComb在Service Mesh的探索与思考

内容来源:2018 年 6 月 27 日,华为微服务架构师田晓亮在“LC3微服务Workshop | 深入解读ServiceComb”进行《ServiceCom...

2744

扫码关注云+社区