实战结合官方文档进行学习效果更佳,可以参考本人另一篇简书-官方文档-监控集群(Monitor)翻译。
Monitoring学习方法:在官方文档与源码阅读基础之上进行实战操作。
1 Monitoring原理讲解
Monitoring是elastic stack的监控模块,可以用来监控ELKB,监控信息存在es索引中,并且可以通过kibana进行可视化的展示。(收集监控数据的方式从6.5版本起由Collectors-Exporters模式逐步迁移到使用Metricbeat进行收集。)
a 官方文档
学习任何模块都可以从阅读官方文档开始,可以参考本人的官方文档翻译辅助学习。7.10版本官方文档结构如下:
b 源码阅读
旧版本的collector方式源码位于es源码之中,由于目前基于metricbeat方式收集数据维度仍比旧版本小,且二者原理都是调用ELKB提供的API收集,es源码也更具备学习价值,所以这里主要讨论旧版本的源码。
Monitoring的源码一共分为两部分:一部分位于xpack.core包中,主要是元数据信息类型代码;一部分位于xpack.monitoring中包,主要是数据收集、导出及索引生命周期策略等实操模块。
Monitor模块按组件分为四类,通过MonitoredSystem枚举区分,每条监控记录都是一条es文档,文档基类为MonitoringDoc,规定了监控记录的统一元数据信息部分(es的监控模块又分为集群,节点,索引,分片等模块,分别继承了MonitoringDoc类,每个单元都有自己独立的数据结构,具体后文详细分析),如下图所以:
实操模块源码包含以下单元:
- cleaner包:CleanerService实现了监控数据的生命周期管理,默认监控数据按天分索引保留七天,每天凌晨1点会进行全部索引的排查,统一删除过期索引。
- collector包:Collector类为es监控各个模块的收集器基类,每个模块都以一个独立Collector继承Collector类。主要实现方式是调用es系统提供的监控API获取response构造成对应的MonitoringDoc子类文档。
- exporter:exporter为数据的导出包,分为两类:导出到本地集群或者导出到专门的监控集群(http方式)。实现方式为es的bulk请求。
- 监控服务类:MonitoringService和Monitoring类为主要服务实现调度类。主要进行参数设置,收集器导出器配置,并采用单线程调度方式使每个收集器在收集周期(默认10s)内运行一次。
具体源码结构如下图:
c 具体实现
接下来我们具体看一下monitor索引内容以及kibana自带的监控功能。
- monitor索引
es的监控数据是以统一的索引模板构造的按天分区索引存储的,如下如所示:
默认索引只保留最近七天的数据,每隔10s会生成一个新的文档。
.monitoring-es模板mapping包含一些元数据信息如集群id、时间戳和hosts信息等,当前文档类型由type
字段标记。每类的数据都有自己独立的一些mapping,如索引信息汇总类数据indices_stats
具有主分片和总的数据量、存储占用以及加载查询数据量统计信息。如下图所示:
- kibana监控功能
kibana监控模块通过调用es索引存储的监控数据,制作了许多开箱即用报表供用户使用。主要分为集群层面、节点层面和索引层面。
kibana通过es索引中存储的数据计算出了许多指标报表,如上图所示包含了查询(加载)速率和查询(加载)延时,除此之外还有cpu、内存、存储以及负载占用等等许多指标。
2 kibana可视化实战
接下来我们具体分析上图的四个指标并通过kibana的TSVB(时间序列的可视化报表)实现这四个指标。
- 查询速率
对于单个索引,它是每秒的查询次数(分片级别,不是请求级别),也就意味着一次查询请求命中的分片数越多,值越大。对于多个索引,它是每个索引的搜索速率的总和。
(例:一个2分片1副本的索引,进行一个查询操作, 索引中的查询数量指标index_stats.total.search.query_total
增加2(与副本数量无关。只与分片数量有关)。Kibana监控界面10分钟间隔时间段内有20个统计点,每个统计点时间间隔为600s/20=30s,计算速度为:Total Shards:2/30=0.067/s)
- 加载速率
对于单个索引,它是每秒索引文档的数量;对于多个索引,它是每个索引的索引速率之和。
(例:一个3分片1副本的索引,加载三条数据入库, index_stats.primaries.indexing.index_total
会增加3条,index_stats.total.indexing.index_total
会增加6条。Kibana监控界面10分钟间隔时间段内有20个统计点,每个统计点时间间隔为600s/20=30s,计算速度为:Primary Shards:3/30=0.1/s Total Shards:6/30=0.2/s)
- 查询延时
查询的平均延时,为执行查询消耗的时间除以查询数量,考虑主副分片。
(例:index_stats.total.search.query_time_in_millis
增长2,index_stats.total.search.query_total
增长1,则计算结果为2/1=2,且由于query_time_in_millis和query_total可能在某段时间不变,所以图像不连续)
- 加载延时
加载延时,为执行加载消耗的时间除以文档数量,只考虑主分片。
(例:index_stats.primaries.indexing.index_time_in_millis
增长6,index_stats.primaries.indexing.index_total
增长5,则计算结果为6/5=1.2。且由于index_time_in_millis和index_total可能在某段时间不变,所以图像不连续)
通过TSVB进行报表实现索引级别四个指标报表:
- 首选选定报表需要使用的索引,以及时间序列使用的时间字段和统计时间间隔:
我们使用通配符匹配存储es监控数据的索引,并以时间戳为时间序列字段,每隔30s生成一个数据点。(Drop last bucket
含义为去掉最后一个统计点,因为es数据实时可见性具有一个延时refresh_interval
,所以可能造成最后一个统计点不准的问题,所以我们可以去掉最后一个统计点保证图像的可靠性。)
-
构造报表函数,通过上一章节对四个指标的分析,使用对应的指标项进行函数构造。
- 查询速率的构造是基于
index_stats.total.search.query_total
指标项,我们将其对时间进行求导得出的即为查询速率,将其结果进行按索引名分组,即可显示每个索引的查询速率。
- 查询速率的构造是基于
- 查询延时的构造是基于
index_stats.total.search.query_time_in_millis
和index_stats.total.search.query_total
两个指标,我们将其差值做比即可得到查询延时,将其结果进行按索引名分组,即可显示每个索引的查询查询。(除了差值Serial Difference
做比,求导Derivative
做比也同样可以获得结果)
加载速率和加载延时你是否可以自己做出?动手实现吧