因为在微服务的架构下,我们对服务进行了拆分,所以用户的每次请求不再是由某一个服务独立完成了,而是变成了多个服务一起配合完成。这种情况下,一旦请求出现异常,我们必须得知道是在哪个服务环节出了故障,就需要对每一个服务,以及各个指标都进行全面的监控。
在微服务架构中,监控系统按照原理和作用大致可以分为三类(并非严格分类,仅从日常使用角度来看):
下面来分别对这三种常见的监控模式进行说明:
使用Beats(可选)在每台服务器上安装后,作为日志客户端收集器,然后通过Logstash进行统一的日志收集、解析、过滤等处理,再将数据发送给Elasticsearch中进行存储分析,最后使用Kibana来进行数据的展示。 当然还可以升级方案为:
这些方案都比较成熟,搭建起来也比较简单,除了用作监控系统以外,还可以作为日志查询系统使用,非常适用于做分析、以及问题调试使用。
一般我们做「监控系统」都是需要做分层式监控的,也就是说将我们要监控的对象进行分层,一般主要分为:
知道了监控的分层后,我们再来看一下监控的指标一般有哪些:
下面介绍几款目前业内比较流行的基于时间序列数据库的开源监控方案:
从看图的左下角可以看到,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来展示。
以上,就是对微服务架构中「 监控系统」的一些思考。