当我们谈论监控时，我们在谈论什么？

我们想像中的监控？

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

现实中的监控

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

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

种类多样的监控工具

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

监控的目的

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

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

故障排查过程

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

为什么不理想？

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

我们的结论

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

业务指标

响应时间

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

在线人数

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

吞吐率

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

实时服务监控

服务性能分析

• 多维度
• 实时
• 智能

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

web服务性能分析

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

mysql服务性能分析

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

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

时间窗口

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

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

有哪些使用场景

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

监控的终级目的

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