es实战-Monitoring原理讲解及kibana可视化实战

实战结合官方文档进行学习效果更佳，可以参考本人另一篇简书- 官方文档-监控集群(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进行报表实现索引级别四个指标报表：

1. 首选选定报表需要使用的索引，以及时间序列使用的时间字段和统计时间间隔：

我们使用通配符匹配存储es监控数据的索引，并以时间戳为时间序列字段，每隔30s生成一个数据点。（

Drop last bucket

含义为去掉最后一个统计点，因为es数据实时可见性具有一个延时

refresh_interval

，所以可能造成最后一个统计点不准的问题，所以我们可以去掉最后一个统计点保证图像的可靠性。）

1. 构造报表函数，通过上一章节对四个指标的分析，使用对应的指标项进行函数构造。
   • 查询速率的构造是基于

     index_stats.total.search.query_total

     指标项，我们将其对时间进行求导得出的即为查询速率，将其结果进行按索引名分组，即可显示每个索引的查询速率。

• 查询延时的构造是基于

  index_stats.total.search.query_time_in_millis

  和

  index_stats.total.search.query_total

  两个指标，我们将其差值做比即可得到查询延时，将其结果进行按索引名分组，即可显示每个索引的查询查询。(除了差值

  Serial Difference

  做比，求导

  Derivative

  做比也同样可以获得结果)

加载速率和加载延时你是否可以自己做出？动手实现吧