博客园  :: 首页  :: 联系 :: 管理

ES Monitoring 整理笔记

Posted on 2023-02-05 16:02  天戈朱  阅读(661)  评论(0)  编辑  收藏  举报

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具有主分片和总的数据量、存储占用以及加载查询数据量统计信息。如下图所示：

 

二、如何正确监测Elasticsearch

  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）来衡量系统更改的影响，最终防止性能低下。

 

三、ES 监控与辅助工具

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(不在需要，删除索引)

 其它：

 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
  • Circuit Breakers
  • ES Threadpools
 YES

 

  • Circuit Breakers
  • ID Cache
  • Lucene memory
  • ES Threadpools
  • Percolator
OS and JVM Metrics YES (+)

 

  • JVM pool sizes
  • JVM pool utilization
 YES
Correlation of Metrics with Logs, Events, Alerts, and Anomalies YES

 

  • SPM and Logsene integration
  • Ability to ingest and chart arbitrary external Events
 NO

 

  • Cluster Pulse displays only Elasticsearch Events
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

 

  • via short links
  • vie embeds / iframe
  • via email
 NO
Machine Learning-based Anomaly Detection YES NO
Threshold based Alerts YES NO
Heartbeat Alerts YES NO
Forwarding Alerts to 3rd parties YES

 

  • E-Mail
  • PagerDuty
  • Nagios / Shinken
  • HipChat
  • Slack
  • Webhooks
 NO
Metrics Aggregation YES

 

  • Pre-aggregation at multiple granularity levels, including 1 min granularity.  Advantage: more efficient storage, scales better, faster for graphing performance over longer time periods at the expense of sub-minute precision.
 YES

 

  • Query-time aggregation. No write or query-time aggregation.
    Advantage: 10 second precision by default at the expense of storage size, write, and read performance and memory footprint.

 

五、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

 

参考资料