Monitoring是elastic stack的监控模块，监控信息存在es索引中，并且可以通过kibana进行可视化的展示。(收集监控数据的方式从6.5版本起由Collectors-Exporters模式逐步迁移到使用Metricbeat进行收集)
一、原理及源码结构
Monitor模块按组件分为四类，通过MonitoredSystem枚举区分，每条监控记录都是一条es文档，文档基类为MonitoringDoc，规定了监控记录的统一元数据信息部分(es的监控模块又分为集群，节点，索引，分片等模块，分别继承了MonitoringDoc类，每个单元都有自己独立的数据结构)，主要监控模块：
- 集群（cluster)
- 节点（node)
- 索引（indices)
- 分片（shards)
源码单元：
- cleaner包：CleanerService 实现了监控数据的生命周期管理，默认监控数据按天分索引保留七天，每天凌晨1点会进行全部索引的排查，统一删除过期索引。
- collector包：Collector 类为es监控各个模块的收集器基类，每个模块都以一个独立Collector继承Collector类。主要实现方式是调用es系统提供的监控API获取response构造成对应的MonitoringDoc子类文档。
- exporter：exporter 为数据的导出包，分为两类：导出到本地集群或者导出到专门的监控集群(http方式)。实现方式为es的bulk请求。
- rest.action：MonitoringService 和 Monitoring类为主要服务实现调度类。主要进行参数设置，收集器导出器配置，并采用单线程调度方式使每个收集器在收集周期(默认10s)内运行一次。
源码结构图：
monitor索引：
es的监控数据是以统一的索引模板构造的按天分区索引存储的（默认索引只保留最近七天的数据），如下如所示：
.monitoring-es模板mapping包含一些元数据信息如集群id、时间戳和hosts信息等，当前文档类型由type字段标记。每类的数据都有自己独立的一些mapping，如索引信息汇总类数据indices_stats具有主分片和总的数据量、存储占用以及加载查询数据量统计信息。如下图所示：
1、Elasticsearch Monitoring Tools
- Elastic Monitoring（以前称为Marvel）和 ElasticHQ 等工具：是方便实时查看性能指标和处理集群任务的合适选项，Marvel基于Kibana的UI中提供了Elasticsearch指标的详细可视化
- ElasticCurator 是另一种直观的产品，可用于管理Elasticsearch索引和快照。
2、Elasticsearch Monitoring Plugins
3、Important Elasticsearch Metrics
- Elasticsearch APIs ：在任何时候都能有效地捕获性能指标，而集群运行状况和搜索/节点/索引性能等数据点都是其运行状态的关键指标。通过密切关注这些指标，您将自动更好地了解Elasticsearch。
4、Performance Testing
- Rally ：Elasticsearch的基准测试工具（Rally）来衡量系统更改的影响，最终防止性能低下。
1、Elastic Monitoring（以前称为Marvel） -- U
处理不断增长的集群可能是一项挑战，并占用大量资源。Marvel是一个与主动监控直接相关的工具，它允许您通过集群、索引和节点度量轻松地实时查看性能。Marvel可以让用户关注一段时间内的内存使用情况（而不仅仅是在一个时间点），因为它可以可视化集群行为，从而更容易发现影响环境的趋势。通过Marvel以交互方式探索数据和简化API的能力使工作流程更加高效，而且它是一个免费工具，这一事实使它变得更好！Marvel基于Kibana的UI中提供了Elasticsearch指标的详细可视化
2、ElasticHQ -- 待研究
ElasticHQ通常用作Elasticsearch集群的托管按需监控工具。ElasticHQ可以选择作为插件安装，也可以在本地下载/运行，它可以监控各个集群节点，并深入了解运行时指标和配置。全集群管理、搜索和查询以及无需安装软件是ElasticHQ的主要优势，它的灵活性为您的监控工作增添了更多动力。可以同时监视和管理多个群集
3、Cerebro（kopf的升级版本） --P
Cerebro是一个集群管理工具，比Kibana轻量很多，很适用与生产和测试等环境的es集群管理。它是kopf的升级版本，更改了个名字，包含kopf的功能(监控工具，并包含head插件的部分功能，可图形化的进行新建索引等操作。现在kopf已经不再更新，只对cerebro进行维护。
特性及界面Portal,参见：开源可视化工具cerebro功能强化
4、Curator
Curator是一个用来管理Elasticsearch索引的工具，使用它可以管理需要删除或保留的索引数据,被Elastic收编的历史
- curator最早被称为clearESindices.py。 它的唯一功能是删除索引。
- 而后重命名：logstash_index_cleaner.py，它在logstash存储库下作用：过期日志清理。
- 此后不久，原作者加入Elastic，它成为了Elasticsearch Curator
Curator功能包含：
- 为别名(Alias)添加或移除索引
- 创建索引
- 删除索引
- 关闭索引
- 删除快照
- 打开已经关闭的索引
- 更改分片路由配置
- 强制合并索引
- 重建索引(包括从远程的集群)
- 更改索引每个分片的副本数量
- 为索引创建快照
- 从快照还原
- rollover indices(当某个别名指向的实际索引过大的时候，自动将别名指向下一个实际索引)
rollover indices：
Rollover 滚动过渡。可以通过配置索引的时间段、文档数量、索引大小满足条件则自动过渡到新索引。当rollover 触发时，将通过目标索引的命名规则生成新的索引。
作用：比如有些索引数据只需要保存前几个月的数据，之前的可以删除或者压缩做为冷索引，不再更新索引，很少查询。信息仍然需要可搜索。ES定义索引有4个生命周期：
- Hot(一般常用的生命周期，活跃更新与搜索)
- Warm(只读模式，可以搜索)
- Cold(也是可以搜索但是比Warm搜索速度要慢，即将删除)
- Delete(不在需要，删除索引)
其它：
- 下载： https://github.com/elastic/curator
- 文档：https://www.elastic.co/guide/en/elasticsearch/client/curator/current/actions.html
6、sematext SPM
四、Elasticsearch Monitoring: SPM vs. Marvel
重要特性：
对比表格：
| Feature | SPM by Sematext | Marvel by Elasticsearch |
| Supported Applications | Elasticsearch, Hadoop, Spark, Kafka, Storm, Cassandra, HBase, Redis, Memcached, NGINX(+), Apache, MySQL, Solr, AWS CloudWatch, JVM, … | Elasticsearch |
| Agent deployment mode | in- and out-of-process (out-of-process allows for seamless updates without requiring Elasticsearch restarts) |
in-process (as Elasticsearch plug-in; updates require Elasticsearch restarts) |
| Predefined dashboard graphs organized in groups | YES | YES |
| Saving Individual Dashboards | Each user can store multiple dashboards, mixing charts from all applications, including both metrics and logs. | Current view can be saved, reset to defaults possible. These changes are global. |
| API for Custom Metrics and Business KPIs | YES | NO |
| Extra Elasticsearch Metrics |
|
YES
|
| OS and JVM Metrics | YES (+)
|
YES |
| Correlation of Metrics with Logs, Events, Alerts, and Anomalies | YES
|
NO
|
| Deployment model | SaaS or On Premises | On Premises |
| Security/User Roles & Permissions |
YES | NO |
| Easy & Secure Sharing of Reports with internal and external organizations | YES
|
NO |
| Machine Learning-based Anomaly Detection | YES | NO |
| Threshold based Alerts | YES | NO |
| Heartbeat Alerts | YES | NO |
| Forwarding Alerts to 3rd parties | YES
|
NO |
| Metrics Aggregation | YES
|
YES
|
五、Elastic Monitoring
kibana监控模块通过调用es索引存储的监控数据，制作了许多开箱即用报表供用户使用。主要分为集群层面、节点层面和索引层面，如下图：
指标说明：
1、Search Rate(/s) ： 检索速率
-
查询速率：对于单个索引，它是每秒的查询次数(分片级别，不是请求级别)，也就意味着一次查询请求命中的分片数越多，值越大。对于多个索引，它是每个索引的搜索速率的总和。
-
例：一个2分片1副本的索引，进行一个查询操作， 索引中的查询数量指标index_stats.total.search.query_total 增加2（与副本数量无关。只与分片数量有关），Kibana监控界面10分钟间隔时间段内有20个统计点，每个统计点时间间隔为600s/20=30s，计算速度为：Total Shards：2/30=0.067/s
2、Indexing Rate(/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
3、Search Latency(ms)：检索延时
- 查询延时：查询的平均延时，为执行查询消耗的时间除以查询数量，考虑主副分片。
- 例：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可能在某段时间不变，所以图像不连续
4、Indexing Latency(ms)：写入延时
-
加载延时：为执行加载消耗的时间除以文档数量，只考虑主分片。
- 例：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可能在某段时间不变，所以图像不连续
Flag:
- ElasticHQ：关注多个群集的同时监控与管理
- rollover indices：自动索引拆分与冷热迁移
- sematext：关注全技术栈监控
- 关注对比 Curator VS Head
参考资料
- https://www.ngui.cc/el/1834592.html?action=onClick
- https://www.datadoghq.com/blog/collect-elasticsearch-metrics/
- https://www.cnblogs.com/WCFGROUP/p/8144629.html
- https://www.opsview.com/resources/elasticsearch/blog/elasticsearch-monitoring-tools
- https://thenewstack.io/properly-monitor-elasticsearch/
- https://sematext.com/blog/elasticsearch-monitoring-marvel-alternative/
- https://medium.com/@dionnis/elasticsearch-monitoring-and-maintenance-tools-research-18c5fb45a747