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