「微服务系列 11」微服务系统监控分层

监控是微服务治理的一个重要环节，监控系统的完善程度直接影响到我们微服务质量的好坏，我们的微服务在线上运行的时候有没有一套完善的监控体系能去了解到它的健康情况，对整个系统的可靠性和稳定性是非常重要。

一个比较完善的微服务监控体系需要涉及到哪些层次，如下图，大致可以划分为五个层次的监控

最底层基础设施监控

一般是由运维人员进行负责，涉及到的方面比较接近硬件体系，例如网络，交换机，路由器等低层设备，这些设备的可靠性稳定性就直接影响到上层服务应用的稳定性，所以需要对网络的流量，丢包情况，错包情况，连接数等等这些基础设施的核心指标进行监控。

系统层监控

涵盖了物理机，虚拟机，操作系统这些都是属于系统级别监控的方面，对几个核心指标监控，如cpu使用率，内存占用率，磁盘IO和网络带宽情况

应用层监控

涉及到方面就跟服务紧密相关，例如对url访问的性能，访问的调用数，访问的延迟，还有对服务提供性能进行监控，服务的错误率，对sql也需要进行监控，查看是否有慢sql，对与cache来说，需要监控缓存的命中率和性能，每个服务的响应时间和qps等等

业务监控

比方说一个典型的交易网站，需要关注它的用户登录情况，注册情况，下单情况，支付情况，这些直接影响到实际触发的业务交易情况，这个监控可以提供给运营和公司高管他们需需要关注的数据，直接可能对公司战略产生影响。

端用户体验监控

一个应用程序可能通过app，h5，pc端的方式交付到用户的手上，用户通过浏览器，客户端打开练到到我们的服务，那么在用户端用户的体验是怎么样，用户端的性能是怎么样，有没有产生错误，这些信息也是需要进行监控并记录下来，如果没有监控，有可能用户的因为某些原因出错或者性能问题造成体验非常的差，而我们并没有感知，这里面包括了，监控用户端的使用性能，返回码，在哪些城市地区他们的使用情况是怎么样，还有运营商的情况，包括电信，联通用户的连接情况。我们需要进一步去知道是否有哪些渠道哪些用户接入的时候存在着问题，包括我们还需要知道客户端使用的操作系统浏览器的版本。

简单来说，这个就是我们成体系化的监控分层，每一个层次都非常的重要，一般情况下，一个问题发现的情况下，比较大概率会先暴露在用户端或业务层，比如来说，我们的订单量下降了，业务人员和开发人员会先从上到下去逐层检查是在哪一个层出现了问题，先确定是否哪个接口调用比较慢，哪个服务调用出现延时，再看是否哪个机器负载过高了，然后再进一步往下一个层去看，是否是网络调用不稳定导致。所以一个好的监控体系，在每一个层次都非常的重要。

刚说的是从层级方面去进行监控，下面继续来看下，哪一些要点可以进行监控

五个点：

1. 日志监控
2. Metrics监控
3. 调用链监控
4. 报警系统
5. 健康检查

典型主流的监控架构

在微服务运行的体系下，我们一般把监控的agent分散到各个服务身边，agent分别是收集机器和服务的metrics，发送到后台监控系统，一般来说，我们的服务量非常大，在收集的过程中，会加入队列，一般来说用kafka，用消息队列有个好处就是两边可以进行解耦，还好就是可以起到庞大的日志进行一个缓存的地带，并在mq可以做到高可用，保证消息不会丢失。

日志收集目前比较流行的是ELK的一套解决方案，（Elasticsearch，Logstash，Kibana），Elasticsearch 分布式搜索引擎，Logstash 是一个日志收集的agent，Kibana 是一个查询的日志界面。

metrice会采用一个时间序列的数据库，influxDB是最近比较主流时间数据库。

微服务的agent例如springboot也提供了健康检查的端点，可以检查cpu使用情况，内存使用情况，jvm使用情况，这些需要一个健康检查机制，能够定期对服务的健康和机器的健康进行check，比较常见的是nagios,zabbix等，这些开源平台能够定期去检查到各个微服务的检查程序并能够进行告警给相关人员，在服务未奔溃之前就可以进行提前的预先接入。

博客地址：「微服务系列 11」微服务系统监控分层

转载于:https://juejin.im/post/5cde87076fb9a07f050a36c8