免费注册
帮助文档(华北一、二)
  • 集群健康是对集群的所有信息进行高度概述,而节点统计值 API 提供一个让人眼花缭乱的统计数据的数组,包含集群的每一个节点统计值。

    节点统计值 API 可以通过如下命令执行:

     

    GET /_nodes/stats


    在输出内容的开头,我们可以看到集群名称和我们的第一个节点:

     

    {

        "_nodes": {

            "total": 3,

            "successful": 3,

            "failed": 0

        },

        "cluster_name": "ues-qwerty",

        "nodes": {

            "cZabQfdFTVCOdh9Zxrjocg": {

                "timestamp": 1515997798238,

                "name": "ues-qwerty-01",

                "transport_address": "192.168.1.1:9300",

                "host": "192.168.1.1",

                "ip": "192.168.1.1:9300",

                "roles": [

                    "master",

                    "data",

                    "ingest"

                ],

                "indices": {

    ...

    节点是排列在一个哈希里,以节点的 UUID 作为键名。还显示了节点网络属性的一些信息,这些值对调试诸如节点未加入集群这类自动发现问题很有用。通常你会发现是端口用错了,或者节点绑定在错误的 IP 地址/网络接口上了。

    索引部分

    索引(indices)部分列出了这个节点上所有索引的聚合过的统计值 :

     
    "indices": {        
      "docs": {            
        "count": 0,            
        "deleted": 0        
      },         
      "store": {            
        "size_in_bytes": 0,            
        "throttle_time_in_millis": 0         
      },

    ● docs 展示节点内存有多少文档,包括还没有从段里清除的已删除文档数量。

    ● store 部分显示节点耗用了多少物理存储。这个指标包括主分片和副本分片在内。如果限流时间很大,那可能表明你的磁盘限流设置得过低。

     
    "indexing": {                     
      "index_total": 2,                     
      "index_time_in_millis": 146,                     
      "index_current": 0,                     
      "index_failed": 0,                     
      "delete_total": 1,                     
      "delete_time_in_millis": 6,                     
      "delete_current": 0,                     
      "noop_update_total": 0,                     
      "is_throttled": false,                       
      "throttle_time_in_millis": 0                 
    },                 
    "get": {                     
      "total": 2,                     
      "time_in_millis": 7,                     
      "exists_total": 2,                     
      "exists_time_in_millis": 7,                     
      "missing_total": 0,                     
      "missing_time_in_millis": 0,                     
      "current": 0                 
    },                 
    "search": {                     
      "open_contexts": 0,                     
      "query_total": 50,                     
      "query_time_in_millis": 74,                     
      "query_current": 0,                     
      "fetch_total": 40,                     
      "fetch_time_in_millis": 25,                     
      "fetch_current": 0,                     
      "scroll_total": 0,                     
      "scroll_time_in_millis": 0,                     
      "scroll_current": 0,                     
      "suggest_total": 0,                     
      "suggest_time_in_millis": 0,                    
      "suggest_current": 0                 
    },                 
    "merges": {                     
      "current": 0,                     
      "current_docs": 0,                     
      "current_size_in_bytes": 0,                     
      "total": 0,                     
      "total_time_in_millis": 0,                     
      "total_docs": 0,                     
      "total_size_in_bytes": 0,                     
      "total_stopped_time_in_millis": 0,                     
      "total_throttled_time_in_millis": 0,                     
      "total_auto_throttle_in_bytes": 104857600                 
    },

    ● indexing 显示已经索引了多少文档。这个值是一个累加计数器,在文档被删除时,数值不会下降,在发生文档更新等内部索引操作时,值会增加。此外还列出了索引操作耗费的时间,正在索引的文档数量,以及删除操作的类似统计值。

    ● get 显示通过 ID 获取文档的接口相关的统计值。包括对单个文档的 GET 和 HEAD 请求。

    ● search 描述在活跃中的搜索(open_contexts)数量、查询的总数量、以及自节点启动以来在查询上消耗的总时间。用 query_time_in_millis / query_total 计算的比值,可以用来粗略的评价你的查询有多高效。比值越大,每个查询花费的时间越多,你应该要考虑调优了。

    ● fetch 统计值展示了查询处理的后一半流程(query-then-fetch 里的 fetch)。如果 fetch 耗时比 query 还多,说明磁盘较慢,或者获取了太多文档,或者可能搜索请求设置了太大的分页(比如,size: 10000)。

    ● merges 包括了 Lucene 段合并相关的信息。它会告诉你目前在运行几个合并,合并涉及的文档数量,正在合并的段的总大小,以及在合并操作上消耗的总时间。

    ● 在你的集群写入压力很大时,合并统计值非常重要。合并要消耗大量的磁盘 I/O 和 CPU 资源。如果你的索引有大量的写入,同时又发现大量的合并数,一定要去阅读索引性能技巧。

     
    "filter_cache": {            
      "memory_size_in_bytes": 48,            
      "evictions": 0         
    },         
    "fielddata": {            
      "memory_size_in_bytes": 0,            
      "evictions": 0         
    },         
    "segments": {            
      "count": 319,            
      "memory_in_bytes": 65812120         
    },         
    ...

    ● filter_cache 展示了已缓存的过滤器位集合所用的内存数量,以及过滤器被驱逐出内存的次数。过多的驱逐数 可能 说明你需要加大过滤器缓存的大小,或者你的过滤器不太适合缓存(比如它们因为高基数而在大量产生,就像是缓存一个 now 时间表达式)。

    ● 不过,驱逐数是一个很难评定的指标。过滤器是在每个段的基础上缓存的,而从一个小的段里驱逐过滤器,代价比从一个大的段里要廉价的多。有可能你有很大的驱逐数,但是它们都发生在小段上,也就意味着这些对查询性能只有很小的影响。把驱逐数指标作为一个粗略的参考。如果你看到数字很大,检查一下你的过滤器,确保他们都是正常缓存的。不断驱逐着的过滤器,哪怕都发生在很小的段上,效果也比正确缓存住了的过滤器差很多。

    ● field_data 显示 fielddata 使用的内存, 用以聚合、排序等等。这里也有一个驱逐计数。和 filter_cache 不同的是,这里的驱逐计数是很有用的:这个数应该或者至少是接近于 0。因为 fielddata 不是缓存,任何驱逐都消耗巨大,应该避免掉。如果你在这里看到驱逐数,你需要重新评估你的内存情况,fielddata 限制,请求语句,或者这三者。

    ● segments 会展示这个节点目前正在服务中的 Lucene 段的数量。 这是一个重要的数字。大多数索引会有大概 50–150 个段,哪怕它们存有 TB 级别的数十亿条文档。段数量过大表明合并出现了问题(比如,合并速度跟不上段的创建)。注意这个统计值是节点上所有索引的汇聚总数。

    ● memory 统计值展示了 Lucene 段自己用掉的内存大小。 这里包括底层数据结构,比如倒排表,字典,和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销,这个内存使用量就是一个方便用来衡量开销的度量值。

    操作系统和进程部分

    OS Process 部分基本是自描述的,不会在细节中展开讲解。它们列出来基础的资源统计值,比如 CPU 和负载。OS 部分描述了整个操作系统,而 Process 部分只显示 Elasticsearch 的 JVM 进程使用的资源情况。

    这些都是非常有用的指标,不过通常在你的监控技术栈里已经都测量好了。统计值包括下面这些:

    ● CPU

    ● 负载

    ● 内存使用率

    ● Swap 使用率

    ● 打开的文件描述符

    JVM部分

    jvm部分包括了运行 Elasticsearch 的 JVM 进程一些很关键的信息。最重要的,它包括了垃圾回收的细节,这对你的 Elasticsearch 集群的稳定性有着重大影响。

     
    "jvm": {                  
      "timestamp": 1515997798245,                 
      "uptime_in_millis": 1704518268,                 
      "mem": {                     
        "heap_used_in_bytes": 143523960,                     
        "heap_used_percent": 3,                     
        "heap_committed_in_bytes": 4277534720,                     
        "heap_max_in_bytes": 4277534720,                     
        "non_heap_used_in_bytes": 95476824,                     
        "non_heap_committed_in_bytes": 102416384,

    线程池部分

    Elasticsearch 在内部维护了线程池。这些线程池相互协作完成任务,有必要的话相互间还会传递任务。通常来说,你不需要配置或者调优线程池,不过查看它们的统计值有时候还是有用的,可以洞察你的集群表现如何。

    这有一系列的线程池,但以相同的格式输出: 

     
    "index": {      
    "threads": 1,      
    "queue": 0,      
    "active": 0,      
    "rejected": 0,      
    "largest": 1,      
    "completed": 1   
    }

    每个线程池会列出已配置的线程数量(threads),当前在处理任务的线程数量(active),以及在队列中等待处理的任务单元数量(queue)。

    如果队列中任务单元数达到了极限,新的任务单元会开始被拒绝,你会在 rejected 统计值上看到它反映出来。这通常是你的集群在某些资源上碰到瓶颈的信号。因为队列满意味着你的节点或集群在用较高的速度运行,但依然跟不上工作的蜂拥而入。

    值得关注的线程池部分有:

    ● indexing

    普通的索引请求的线程池

    ● bulk

    批量请求,和单条的索引请求不同的线程池

    ● get

    Get-by-ID 操作

    ● search

    所有的搜索和查询请求

    ● merging

    专用于管理 Lucene 合并的线程池

    文件系统和网络部分

    继续向下阅读 /_node/stats API,你会看到一串和你的文件系统相关的统计值:可用空间,数据目录路径,磁盘 I/O 统计值,等等。如果你没有监控磁盘可用空间的话,可以从这里获取这些统计值。磁盘 I/O 统计值也很方便,不过通常那些更专门的命令行工具(比如 iostat )会更有用些。

    显然,Elasticsearch 在磁盘空间满的时候很难运行——所以请确保不会这样。

    还有两个跟网络统计值相关的部分:

     
    "transport": {                  
      "server_open": 26,                 
      "rx_count": 8834703,                 
      "rx_size_in_bytes": 19706396482,                 
      "tx_count": 8834702,                 
      "tx_size_in_bytes": 18212792172             
    },             
    "http": {                 
      "current_open": 3,                 
      "total_opened": 153             
    },

    ● transport 显示和 传输地址 相关的一些基础统计值。包括节点间的通信(通常是 9300 端口)以及任意传输客户端或者节点客户端的连接。如果看到这里有很多连接数不要担心;Elasticsearch 在节点之间维护了大量的连接。

    ● http 显示 HTTP 端口(通常是 9200)的统计值。如果你看到 total_opened 数很大而且还在一直上涨,这是一个明确信号,说明你的 HTTP 客户端里有没启用 keep-alive 长连接的。持续的 keep-alive 长连接对性能很重要,因为连接、断开套接字是很昂贵的(而且浪费文件描述符)。请确认你的客户端都配置正确。

    断路有

    fielddata 断路器相关的统计值: 

     
    "fielddata": {                     
      "limit_size_in_bytes": 2566520832,                     
      "limit_size": "2.3gb",                     
      "estimated_size_in_bytes": 0,                     
      "estimated_size": "0b",                     
      "overhead": 1.03,                     
      "tripped": 0                 
    },

    这里你可以看到断路器的最大值(比如,一个请求申请更多的内存时会触发断路器)。这个部分还会让你知道断路器被触发了多少次,以及当前配置的间接开销。间接开销用来铺垫评估,因为有些请求比其他请求更难评估。

    主要需要关注的是 tripped 指标。如果这个数字很大或者持续上涨,这是一个信号,说明你的请求需要优化,或者你需要添加更多内存(单机上添加,或者通过添加新节点的方式)。

文档是否已解决您的问题?

  已解决   未解决

如您有其它疑问,您也可以与我们技术专家联系探讨。

联系技术专家