微服务架构之「 监控系统 」

在微服务架构的系列文章中，前面已经经过文章分别介绍过了微服务的「服务注册 」、「服务网关 」、「配置中心 」，今天这篇文章咱们继续来聊一聊另一个重要模块：「 监控系统 」。

由于在微服务的架构下，咱们对服务进行了拆分，因此用户的每次请求再也不是由某一个服务独立完成了，而是变成了多个服务一块儿配合完成。这种状况下，一旦请求出现异常，咱们必须得知道是在哪一个服务环节出了故障，就须要对每个服务，以及各个指标都进行全面的监控。

1、什么是「 监控系统 」？

在微服务架构中，监控系统按照原理和做用大体能够分为三类（并不是严格分类，仅从平常使用角度来看）：

• 日志类（Log）

• 调用链类（Tracing）

• 度量类（Metrics）

下面来分别对这三种常见的监控模式进行说明：

1. 日志类（Log）

   日志类比较常见，咱们的框架代码、系统环境、以及业务逻辑中通常都会产出一些日志，这些日志咱们一般把它记录后统一收集起来，方便在须要的时候进行查询。

   日志类记录的信息通常是一些事件、非结构化的一些文本内容。日志的输出和处理的解决方案比较多，你们熟知的有 ELK Stack 方案（Elasticseach + Logstash + Kibana），如图：

   使用Beats（可选）在每台服务器上安装后，做为日志客户端收集器，而后经过Logstash进行统一的日志收集、解析、过滤等处理，再将数据发送给Elasticsearch中进行存储分析，最后使用Kibana来进行数据的展现。

   固然还能够升级方案为：

   这些方案都比较成熟，搭建起来也比较简单，除了用做监控系统之外，还能够做为日志查询系统使用，很是适用于作分析、以及问题调试使用。

2. 调用链类（Tracing）

   调用链类监控主要是指记录一个请求的所有流程。一个请求从开始进入，在微服务中调用不一样的服务节点后，再返回给客户端，在这个过程当中经过调用链参数来追寻全链路行为。经过这个方式能够很方便的知道请求在哪一个环节出了故障，系统的瓶颈在哪儿。

   这一类的监控通常采用 CAT 工具 来完成，通常在大中型项目较多用到，由于搭建起来有必定的成本。后面会有单独文章来说解这个调用链监控系统。

3. 度量类（Metrics）

   度量类主要采用 时序数据库 的解决方案。它是以事件发生时间以及当前数值的角度来记录的监控信息，是能够聚合运算的，用于查看一些指标数据和指标趋势。因此这类监控主要不是用来查问题的，主要是用来看趋势的。

   Metrics通常有5种基本的度量类型：Gauges（度量）、Counters（计数器）、 Histograms（直方图）、 Meters（TPS计算器）、Timers（计时器）。

   基于时间序列数据库的监控系统是很是适合作监控告警使用的，因此如今也比较流行这个方案，若是咱们要搭建一套新的监控系统，我也建议参考这类方案进行。

   所以本文接下来也会重点以时间序列数据库的监控系统为主角来描述。

2、「 监控系统 」关注的对象和指标都是什么？

通常咱们作「监控系统」都是须要作分层式监控的，也就是说将咱们要监控的对象进行分层，通常主要分为：

1. 系统层：系统层主要是指CPU、磁盘、内存、网络等服务器层面的监控，这些通常也是运维同窗比较关注的对象。

2. 应用层：应用层指的是服务角度的监控，好比接口、框架、某个服务的健康状态等，通常是服务开发或框架开发人员关注的对象。

3. 用户层：这一层主要是与用户、与业务相关的一些监控，属于功能层面的，大多数是项目经理或产品经理会比较关注的对象。

知道了监控的分层后，咱们再来看一下监控的指标通常有哪些：

1. 延迟时间：主要是响应一个请求所消耗的延迟，好比某接口的HTTP请求平均响应时间为100ms。

2. 请求量：是指系统的容量吞吐能力，例如每秒处理多少次请求（QPS）做为指标。

3. 错误率：主要是用来监控错误发生的比例，好比将某接口一段时间内调用时失败的比例做为指标。

3、基于时序数据库的「 监控系统 」有哪些？

下面介绍几款目前业内比较流行的基于时间序列数据库的开源监控方案：

• Prometheus

  Promethes是一款2012年开源的监控框架，其本质是时间序列数据库，由Google前员工所开发。

  Promethes采用拉的模式（Pull）从应用中拉取数据，并还支持 Alert 模块能够实现监控预警。它的性能很是强劲，单机能够消费百万级时间序列。

  架构以下：

  从看图的左下角能够看到，Prometheus 能够经过在应用里进行埋点后Pull到 Prometheus Server里，若是应用不支持埋点，也能够采用exporter方式进行数据采集。

  从图的左上角能够看到，对于一些定时任务模块，由于是周期性运行的，因此采用拉的方式没法获取数据，那么Prometheus 也提供了一种推数据的方式，可是并非推送到Prometheus Server中，而是中间搭建一个 Pushgateway，定时任务模块将metrics信息推送到这个Pushgateway中，而后Prometheus Server再依然采用拉的方式从Pushgateway中获取数据。

  须要拉取的数据既能够采用静态方式配置在Prometheus Server中，也能够采用服务发现的方式（即图的中间上面的Service discovery所示）。

  PromQL：是Prometheus自带的查询语法，经过编写PromQL语句能够查询Prometheus里面的数据。

  Alertmanager：是用于数据的预警模块，支持经过多种方式去发送预警。

  WebUI：是用来展现数据和图形的，可是通常大多数是与Grafana结合，采用Grafana来展现。

• OpenTSDB

  OpenTSDB是在2010年开源的一款分布式时序数据库，固然其主要用于监控方案中。

  OpenTSDB采用的是Hbase的分布式存储，它获取数据的模式与Prometheus不一样，它采用的是推模式（Push）。

  在展现层，OpenTSDB自带有WebUI视图，也能够与Grafana很好的集成，提供丰富的展现界面。

  但OpenTSDB并无自带预警模块，须要本身去开发或者与第三方组件结合使用。

  能够经过下图来了解一下OpenTSDB的架构：

• InfluxDB

  InfluxDB是在2013年开源的一款时序数据库，在这里咱们主要仍是用于作监控系统方案。它收集数据也是采用推模式（Push）。在展现层，InfluxDB也是自带WebUI，也能够与Grafana集成。

以上，就是对微服务架构中「 监控系统」的一些思考。

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。😊

本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思惟认知、我的成长、架构、大数据、Web技术 等。