Elasticsearch具有通用性、可扩展性和实用性的特点,集群的基础架构必须满足如上特性。合理的集群架构能支撑其数据存储及并发响应需求。相反,不合理的集群基础架构和错误配置可能导致集群性能下降、集群无法响应甚至集群崩溃。监控系统的节点运行情况、集群健康、JVM性能状况、索引性能、检索性能等,实时发现问题,防患于未然。
实际业务场景中,如果公司条件允许,X-pack是首选,具备数据安全和监控告警等功能,用的放心。
免费工具推荐使用:Elastic-HQ, cerebro监控。
每个节点都运行物理硬件上,需要访问系统内存,磁盘存储和CPU周期,以便管理其控制下的数据并响应对集群的请求。
Elasticsearch是一个严重依赖内存 以实现性能的系统,因此密切关注内存使用情况与每个节点的运行状况和性能相关。改进指标的相关配置更改也可能会对内存分配和使用产生负面影响,因此记住从整体上查看系统运行状况非常重要。
监视节点的CPU使用情况并查找峰值有助于识别节点中的低效进程或潜在问题。CPU性能与Java虚拟机(JVM)的垃圾收集过程密切相关。
磁盘高读写可能导致系统性能问题。由于访问磁盘在时间上是一个“昂贵”的过程,因此应尽可能减少磁盘I/O。
通过如下命令行可以实现节点级别度量指标,并反映运行它的实例或计算机的性能。
GET _cat/nodes?v&h=id,disk.total,disk.used,disk.avail,disk.used_percent,ram.current,ram.percent,ram.max,cpu&format=json&pretty
[
{
"id" : "yrVc",
"disk.avail" : "17.7gb",
"ram.current" : "2.6gb",
"ram.percent" : "56",
"ram.max" : "4.6gb",
"cpu" : "0"
}
]
注意:本文验证时采用的版本为ES 5.4.0,有些指标与原文不同,根据不同版本返回结果会有变化。
节点运行的重要指标:
作为基于Java的应用程序,Elasticsearch在Java虚拟机(JVM)中运行。JVM在其“堆”分配中管理其内存,并通过garbage collection进行垃圾回收处理。
如果应用程序的需求超过堆的容量,则应用程序开始强制使用连接的存储介质上的交换空间。虽然这可以防止系统崩溃,但它可能会对集群的性能造成严重破坏。监视可用堆空间以确保系统具有足够的容量对于集群的健康至关重要。
JVM内存分配给不同的内存池。您需要密切注意这些池中的每个池,以确保它们得到充分利用并且没有被超限利用的风险。
垃圾收集器(GC)很像物理垃圾收集服务。我们希望让它定期运行,并确保系统不会让它过载。理想情况下,GC性能视图应类似均衡波浪线大小的常规执行。尖峰和异常可以成为更深层次问题的指标。
可以通过GET /_nodes/stats 命令检索JVM度量标准。
GET /_nodes/stats
"jvm" : {
"timestamp" : 1557588707194,
"uptime_in_millis" : 22970151,
"mem" : {
"heap_used_in_bytes" : 843509048,
"heap_used_percent" : 40,
"heap_committed_in_bytes" : 2077753344,
"heap_max_in_bytes" : 2077753344,
"non_heap_used_in_bytes" : 156752056,
"non_heap_committed_in_bytes" : 167890944,
"pools" : {
"young" : {
"used_in_bytes" : 415298464,
"max_in_bytes" : 558432256,
"peak_used_in_bytes" : 558432256,
"peak_max_in_bytes" : 558432256
},
"survivor" : {
"used_in_bytes" : 12178632,
"max_in_bytes" : 69730304,
"peak_used_in_bytes" : 69730304,
"peak_max_in_bytes" : 69730304
},
"old" : {
"used_in_bytes" : 416031952,
"max_in_bytes" : 1449590784,
"peak_used_in_bytes" : 416031952,
"peak_max_in_bytes" : 1449590784
}
}
},
"threads" : {
"count" : 116,
"peak_count" : 119
},
"gc" : {
"collectors" : {
"young" : {
"collection_count" : 260,
"collection_time_in_millis" : 3463
},
"old" : {
"collection_count" : 2,
"collection_time_in_millis" : 125
}
}
},
JVM运行的重要指标如下:
分片数的多少对集群性能的影响至关重要。分片数量设置过多或过低都会引发一些问题。
分片数量过多,则批量写入/查询请求被分割为过多的子写入/查询,导致该索引的写入、查询拒绝率上升;
对于数据量较大的索引,当分片数量过小时,无法充分利用节点资源,造成机器资源利用率不高或不均衡,影响写入/查询的效率。
通过GET _cluster/health
监视群集时,可以查询集群的状态、节点数和活动分片计数的信息。还可以查看重新定位分片,初始化分片和未分配分片的计数。
GET _cluster/health
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 127,
"active_shards" : 127,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 120,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 51.417004048582996
}
集群运行的重要指标:
我们可以通过测量系统处理请求的速率和每个请求的使用时间来衡量集群的有效性。
当集群收到请求时,可能需要跨多个节点访问多个分片中的数据。系统处理和返回请求的速率、当前正在进行的请求数以及请求的持续时间等核心指标是衡量集群健康重要因素。
请求过程本身分为两个阶段:
通过GET {index}/_stats查看对应目标索引状态。
GET {index}/_stats
"search" : {
"open_contexts" : 0,
"query_total" : 10,
"query_time_in_millis" : 0,
"query_current" : 0,
"fetch_total" : 1,
"fetch_time_in_millis" : 0,
"fetch_current" : 0,
"scroll_total" : 5,
"scroll_time_in_millis" : 15850,
"scroll_current" : 0,
"suggest_total" : 0,
"suggest_time_in_millis" : 0,
"suggest_current" : 0
},
请求检索性能相关的重要指标如下:
文档的增、删、改操作,集群需要不断更新其索引,然后在所有节点上刷新它们。所有这些都由集群负责,作为用户,除了配置 refresh interval 之外,我们对此过程的控制有限。
增、删、改批处理操作,会形成新段(segment)并刷新到磁盘,并且由于每个段消耗资源,因此将较小的段合并为更大的段对于性能非常重要。同上类似,这由集群本身管理。
监视文档的索引速率( indexing rate )和合并时间(merge time)有助于在开始影响集群性能之前提前识别异常和相关问题。将这些指标与每个节点的运行状况并行考虑,这些指标为系统内的潜问题提供重要线索,为性能优化提供重要参考。
可以通过GET /_nodes/stats 获取索引性能指标,并可以在节点,索引或分片级别进行汇总。
GET /_nodes/stats
"merges" : {
"current" : 0,
"current_docs" : 0,
"current_size_in_bytes" : 0,
"total" : 245,
"total_time_in_millis" : 58332,
"total_docs" : 1351279,
"total_size_in_bytes" : 640703378,
"total_stopped_time_in_millis" : 0,
"total_throttled_time_in_millis" : 0,
"total_auto_throttle_in_bytes" : 2663383040
},
"refresh" : {
"total" : 2955,
"total_time_in_millis" : 244217,
"listeners" : 0
},
"flush" : {
"total" : 127,
"periodic" : 0,
"total_time_in_millis" : 13137
},
索引性能维度相关重要指标: