Forwarded From: https: //blog.csdn.net/majianxiong_lzu/article/details/90437559
The main indicators of sort
- Cluster Health – Nodes and Shards
- Search Performance – Request Latency and
- Search Performance – Request Rate
- Indexing Performance – Refresh Times
- Indexing Performance – Merge Times
- Node Health – Memory Usage
- Node Health - Disk I / O
- Node Health – CPU
- JVM Health – Heap Usage and Garbage Collection
- JVM health – JVM Pool Size
Elasticsearch versatile, scalable and practical features, the cluster infrastructure must satisfy the above characteristics. Reasonable cluster architecture that can support data storage and concurrent demand response. On the contrary, unreasonable cluster infrastructure and cluster configuration error may cause performance degradation, the cluster can not respond to even a cluster crash. Operation node cluster health, JVM performance status, performance index, retrieval performance monitoring system, etc., in real-time to identify problems before they occur.
Monitoring Tools
The actual business scenarios, if the company conditions permit, the X-Pack- preferred, with data security and alarm monitoring and other functions, with the assured.
Free tools are recommended: Elastic-HQ , Cerebro monitoring.
1, the health dimension nodes: memory, disk and CPU indicators
On each node runs the physical hardware, the system needs to access memory, disk storage and CPU cycles to manage their data under control of the cluster in response to the request.
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，有些指标与原文不同，根据不同版本返回结果会有变化。
节点运行的重要指标：
- disk.total ：总磁盘容量。节点主机上的总磁盘容量。
- disk.used：总磁盘使用量。节点主机上的磁盘使用总量。
- avail disk：可用磁盘空间总量。
- disk.avail disk.used_percent：使用的磁盘百分比。已使用的磁盘百分比。
- ram：当前的RAM使用情况。当前内存使用量（测量单位）。
- percent ram：RAM百分比。正在使用的内存百分比。
- max : 最大RAM。 节点主机上的内存总量
- cpu：中央处理器。正在使用的CPU百分比。
2、JVM运行状况维度：堆，GC和池大小
作为基于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运行的重要指标如下：
- mem：内存使用情况。堆和非堆进程和池的使用情况统计信息。
- threads：当前使用的线程和最大数量。
- gc：垃圾收集。算和垃圾收集所花费的总时间。
3、集群健康维度：分片和节点
分片数的多少对集群性能的影响至关重要。分片数量设置过多或过低都会引发一些问题。
分片数量过多，则批量写入/查询请求被分割为过多的子写入/查询，导致该索引的写入、查询拒绝率上升；
对于数据量较大的索引，当分片数量过小时，无法充分利用节点资源，造成机器资源利用率不高或不均衡，影响写入/查询的效率。
通过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 }集群运行的重要指标：
- Status：状态群集的状态。红色：部分主分片未分配。黄色：部分副本分片未分配。绿色：所有分片分配ok。
- Nodes：节点。包括群集中的节点总数，并包括成功和失败节点的计数。 Count of Active
- Shards：活动分片计数。集群中活动分片的数量。 Relocating - Shards：重定位分片。由于节点丢失而移动的分片计数。
- Initializing Shards：初始化分片。由于添加索引而初始化的分片计数。 - Unassigned Shards。未分配的分片。尚未创建或分配副本的分片计数。
4、搜索性能维度：请求率和延迟
我们可以通过测量系统处理请求的速率和每个请求的使用时间来衡量集群的有效性。
当集群收到请求时，可能需要跨多个节点访问多个分片中的数据。系统处理和返回请求的速率、当前正在进行的请求数以及请求的持续时间等核心指标是衡量集群健康重要因素。
请求过程本身分为两个阶段：
- 第一是查询阶段（query phase），集群将请求分发到索引中的每个分片（主分片或副本分片）。
- 第二个是获取阶段（fetch phrase），查询结果被收集，处理并返回给用户。
通过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 },请求检索性能相关的重要指标如下：
- query_current：当前正在进行的查询数。集群当前正在处理的查询计数。
- fetch_current：当前正在进行的fetch次数。集群中正在进行的fetch计数。
- query_total：查询总数。集群处理的所有查询的聚合数。
- query_time_in_millis：查询总耗时。所有查询消耗的总时间（以毫秒为单位）。
f- etch_total：提取总数。集群处理的所有fetch的聚合数。
f- etch_time_in_millis：fetch所花费的总时间。所有fetch消耗的总时间（以毫秒为单位）。
5、索引性能维度：刷新(refresh)和合并(Merge)时间
文档的增、删、改操作，集群需要不断更新其索引，然后在所有节点上刷新它们。所有这些都由集群负责，作为用户，除了配置 refresh interval 之外，我们对此过程的控制有限。
增、删、改批处理操作，会形成新段（segment）并刷新到磁盘，并且由于每个段消耗资源，因此将较小的段合并为更大的段对于性能非常重要。同上类似，这由集群本身管理。
监视文档的索引速率（ indexing rate ）和合并时间（merge time）有助于在开始影响集群性能之前提前识别异常和相关问题。将这些指标与每个节点的运行状况并行考虑，这些指标为系统内的潜问题提供重要线索，为性能优化提供重要参考。
Can _nodes / stats performance index acquired by the GET /, and can be summarized in the nodes, the index level or slice.
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 },Index performance dimensions related key indicators:
- refresh.total: total refresh count. Counting the total number of refresh.
- refresh.total_time_in_millis: Refresh the total time. Refresh summary of all spent time (measured in milliseconds units).
- merges.current_docs: The current merger. Merge is currently being processed.
- merges.total_docs: The total number of merger. Counting the total number of combined.
- merges.total_stopped_time_in_millis. The total time it takes to merge. All combined polymerization time period.