[整理] 微服务系统监控分层和治理核心
前言 -
“监控”是微服务治理的一个重要环节，监控系统的完善程度直接影响到我们微服务质量的好坏，我们的微服务在线上运行时，有没有一套完善的监控体系能去了解到它的健康情况，这对整个系统的可靠性和稳定性非常重要。
微服务监控体系的层级架构 -
1、五个层级的监控
一个比较完善的微服务监控体系需要涉及到哪些层级？如下图所示，大致可以划分为五个层级的监控：
2、最底层基础设施监控
这层一般由运维人员负责，涉及到的方面比较接近硬件体系，例如网络，交换机，路由器等低层设备，这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性，所以需要对网络的流量，丢包情况、错包情况，连接数等等这些基础设施的核心指标进行监控。
3、系统层监控
这层涵盖了物理机、虚拟机、操作系统等，这些都是属于系统级别监控的方面，主要对几个核心指标进行监控，如cpu使用率、内存占用率，磁盘IO和网络带宽情况。
4、应用层监控
这层涉及到方面和服务紧密相关，例如对url访问的性能，访问的调用数，访问的延迟，还有对服务提供性能进行监控，服务的错误率等，同时对sql也需要进行监控，查看是否有慢sql。对于cache来说，需要监控缓存的命中率和性能，每个服务的响应时间和qps等等。
5、业务监控
业务监控具体指什么？
举个例子，比如说一个典型的交易网站，需要关注它的用户登录情况、注册情况、下单情况、支付情况等等，这些直接影响到实际触发的业务交易情况，这层监控可以提供给运营和公司高管们，提供他们需要关注的数据，直接以数据支撑公司在战略层面的决策和方向。
6、端用户体验监控
一个应用程序可能通过app、h5、pc端的方式交付到用户的手上，用户通过浏览器，客户端打开连到我们的服务，那么在用户端，用户的体验是怎么样？用户端的性能是怎么样？以及有没有产生错误等等……
这些信息都需要进行监控并记录下来，如果没有监控，有可能因为某些BUG或者性能问题，造成用户体验非常差，而我们并没有感知。
其中包括监控用户端的使用性能、返回码，在哪些城市地区，他们的使用情况是怎么样，还有运营商的情况，包括三大运营商不同用户的连接情况。我们需要进一步知道，是否有哪些渠道哪些用户接入的时候存在着问题，我们还需要知道客户端使用的操作系统浏览器的版本。
简单来说，这就是我们体系化的监控分层，每一个层级都非常重要。
一般情况下，当一个问题出现时，较大概率会先暴露在用户端或业务层。
比如说，我们的订单量下降了，业务人员和开发人员会先从上到下去逐层检查是在哪里出现了问题，先确定是否哪个接口调用比较慢，哪个服务调用出现延时，再看是否哪个机器负载过高了，然后再进一步往下一个层去看，是否是网络调用不稳定导致。
所以，一个好的监控体系，在每个层级都非常重要。
微服务监控的要点
1、五个监控要点
上文讲解的是从层级方面进行监控，接下来，我们来看看哪些要点可以进行监控：
简单来说，可以分为以下五个点：
- 日志监控
- Metrics监控
- 调用链监控
- 报警系统
- 健康检查
2、典型主流的监控架构
在微服务运行的体系下，我们一般把监控的agent分散到各个服务身边，agent分别是收集机器和服务的metrics，发送到后台监控系统，一般来说，我们的服务量非常大，在收集的过程中，会加入队列。一般来说用kafka等消息队列有个好处，两边可以进行解耦，可以起到庞大的日志进行一个缓存的地带，并且可以做到高可用，保证消息不会丢失。
日志收集目前比较流行的是ELK的一套解决方案（Elasticsearch，Logstash，Kibana），Elasticsearch 分布式搜索引擎，Logstash 是一个日志收集的agent，Kibana 是一个查询的日志界面。
metrice会采用一个时间序列的数据库，influxDB是最近比较主流时间数据库。
微服务的agent。例如springboot也提供了健康检查的端点，可以检查cpu使用情况、内存使用情况、jvm使用情况，这些需要一个健康检查机制，能够定期对服务的健康和机器的健康进行check，比较常见的是nagios、zabbix等，这些开源平台能够定期去检查到各个微服务的检查程序并能够进行告警给相关人员，在服务未崩溃之前就可以进行提前的预先接入。
