美文网首页Elaticsearch进阶
Elasticsearch 系列文章(四):ElasticSea

Elasticsearch 系列文章(四):ElasticSea

作者: zhisheng_blog | 来源:发表于2018-04-22 14:27 被阅读7次
    image

    集群健康监控是对集群信息进行高度的概括,节点统计值 API 提供了集群中每个节点的统计值。节点统计值很多,在监控的时候仍需要我们清楚哪些指标是最值得关注的。

    集群健康监控可以参考这篇文章:ElasticSearch 集群监控

    节点信息 Node Info :

    curl -XGET 'http://localhost:9200/_nodes'
    

    执行上述命令可以获取所有 node 的信息

    _nodes: {
      total: 2,
      successful: 2,
      failed: 0
    },
    cluster_name: "elasticsearch",
    nodes: {
        MSQ_CZ7mTNyOSlYIfrvHag: {
        name: "node0",
        transport_address: "192.168.180.110:9300",
        host: "192.168.180.110",
        ip: "192.168.180.110",
        version: "5.5.0",
        build_hash: "260387d",
        total_indexing_buffer: 103887667,
        roles:{...},
        settings: {...},
        os: {
          refresh_interval_in_millis: 1000,
          name: "Linux",
          arch: "amd64",
          version: "3.10.0-229.el7.x86_64",
          available_processors: 4,
          allocated_processors: 4
        },
        process: {
          refresh_interval_in_millis: 1000,
          id: 3022,
          mlockall: false
        },
        jvm: {
          pid: 3022,
          version: "1.8.0_121",
          vm_name: "Java HotSpot(TM) 64-Bit Server VM",
          vm_version: "25.121-b13",
          vm_vendor: "Oracle Corporation",
          start_time_in_millis: 1507515225302,
          mem: {
          heap_init_in_bytes: 1073741824,
          heap_max_in_bytes: 1038876672,
          non_heap_init_in_bytes: 2555904,
          non_heap_max_in_bytes: 0,
          direct_max_in_bytes: 1038876672
          },
          gc_collectors: [],
          memory_pools: [],
          using_compressed_ordinary_object_pointers: "true",
          input_arguments:{}
        }
        thread_pool:{
          force_merge: {},
          fetch_shard_started: {},
          listener: {},
          index: {},
          refresh: {},
          generic: {},
          warmer: {},
          search: {},
          flush: {},
          fetch_shard_store: {},
          management: {},
          get: {},
          bulk: {},
          snapshot: {}
        }
        transport: {...},
        http: {...},
        plugins: [],
        modules: [],
        ingest: {...}
     }
    

    上面是我已经简写了很多数据之后的返回值,但是指标还是很多,有些是一些常规的指标,对于监控来说,没必要拿取。从上面我们可以主要关注以下这些指标:

    os, process, jvm, thread_pool, transport, http, ingest and indices
    

    节点统计 nodes-statistics

    节点统计值 API 可通过如下命令获取:

    GET /_nodes/stats
    

    得到:

    _nodes: {
      total: 2,
      successful: 2,
      failed: 0
    },
    cluster_name: "elasticsearch",
    nodes: {
      MSQ_CZ7mTNyOSlYI0yvHag: {
        timestamp: 1508312932354,
        name: "node0",
        transport_address: "192.168.180.110:9300",
        host: "192.168.180.110",
        ip: "192.168.180.110:9300",
        roles: [],
        indices: {
          docs: {
               count: 6163666,
               deleted: 0
            },
          store: {
               size_in_bytes: 2301398179,
               throttle_time_in_millis: 122850
            },
          indexing: {},
          get: {},
          search: {},
          merges: {},
          refresh: {},
          flush: {},
          warmer: {},
          query_cache: {},
          fielddata: {},
          completion: {},
          segments: {},
          translog: {},
          request_cache: {},
          recovery: {}
      },
      os: {
        timestamp: 1508312932369,
        cpu: {
          percent: 0,
          load_average: {
            1m: 0.09,
            5m: 0.12,
            15m: 0.08
          }
        },
        mem: {
          total_in_bytes: 8358301696,
          free_in_bytes: 1381613568,
          used_in_bytes: 6976688128,
          free_percent: 17,
          used_percent: 83
        },
        swap: {
          total_in_bytes: 8455712768,
          free_in_bytes: 8455299072,
          used_in_bytes: 413696
        },
        cgroup: {
          cpuacct: {},
          cpu: {
            control_group: "/user.slice",
            cfs_period_micros: 100000,
            cfs_quota_micros: -1,
            stat: {}
          }
      }
    },
    process: {
      timestamp: 1508312932369,
      open_file_descriptors: 228,
      max_file_descriptors: 65536,
      cpu: {
        percent: 0,
        total_in_millis: 2495040
      },
      mem: {
        total_virtual_in_bytes: 5002465280
      }
    },
    jvm: {
      timestamp: 1508312932369,
      uptime_in_millis: 797735804,
      mem: {
        heap_used_in_bytes: 318233768,
        heap_used_percent: 30,
        heap_committed_in_bytes: 1038876672,
        heap_max_in_bytes: 1038876672,
        non_heap_used_in_bytes: 102379784,
        non_heap_committed_in_bytes: 108773376,
      pools: {
        young: {
          used_in_bytes: 62375176,
          max_in_bytes: 279183360,
          peak_used_in_bytes: 279183360,
          peak_max_in_bytes: 279183360
        },
        survivor: {
          used_in_bytes: 175384,
          max_in_bytes: 34865152,
          peak_used_in_bytes: 34865152,
          peak_max_in_bytes: 34865152
        },
        old: {
          used_in_bytes: 255683208,
          max_in_bytes: 724828160,
          peak_used_in_bytes: 255683208,
          peak_max_in_bytes: 724828160
        }
      }
      },
      threads: {},
      gc: {},
      buffer_pools: {},
      classes: {}
    },
      thread_pool: {
        bulk: {},
        fetch_shard_started: {},
        fetch_shard_store: {},
        flush: {},
        force_merge: {},
        generic: {},
        get: {},
        index: {
           threads: 1,
           queue: 0,
           active: 0,
           rejected: 0,
           largest: 1,
           completed: 1
        }
        listener: {},
        management: {},
        refresh: {},
        search: {},
        snapshot: {},
        warmer: {}
      },
      fs: {},
      transport: {
        server_open: 13,
        rx_count: 11696,
        rx_size_in_bytes: 1525774,
        tx_count: 10282,
        tx_size_in_bytes: 1440101928
      },
      http: {
        current_open: 4,
        total_opened: 23
      },
      breakers: {},
      script: {},
      discovery: {},
      ingest: {}
    }
    

    节点名是一个 UUID,上面列举了很多指标,下面讲解下:

    索引部分 indices

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

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

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

    • indexing 显示已经索引了多少文档。这个值是一个累加计数器。在文档被删除的时候,数值不会下降。还要注意的是,在发生内部 索引操作的时候,这个值也会增加,比如说文档更新。

      还列出了索引操作耗费的时间,正在索引的文档数量,以及删除操作的类似统计值。

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

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

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

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

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

      不过,驱逐数是一个很难评定的指标。过滤器是在每个段的基础上缓存的,而从一个小的段里驱逐过滤器,代价比从一个大的段里要廉价的多。有可能你有很大的驱逐数,但是它们都发生在小段上,也就意味着这些对查询性能只有很小的影响。

      把驱逐数指标作为一个粗略的参考。如果你看到数字很大,检查一下你的过滤器,确保他们都是正常缓存的。不断驱逐着的过滤器,哪怕都发生在很小的段上,效果也比正确缓存住了的过滤器差很多。

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

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

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

    操作系统和进程部分

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

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

    • CPU
    • 负载
    • 内存使用率 (mem.used_percent)
    • Swap 使用率
    • 打开的文件描述符 (open_file_descriptors)

    JVM 部分

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

    jvm: {
      timestamp: 1508312932369,
      uptime_in_millis: 797735804,
      mem: {
        heap_used_in_bytes: 318233768,
        heap_used_percent: 30,
        heap_committed_in_bytes: 1038876672,
        heap_max_in_bytes: 1038876672,
        non_heap_used_in_bytes: 102379784,
        non_heap_committed_in_bytes: 108773376,
      }
    }
    

    jvm 部分首先列出一些和 heap 内存使用有关的常见统计值。你可以看到有多少 heap 被使用了,多少被指派了(当前被分配给进程的),以及 heap 被允许分配的最大值。理想情况下,heap_committed_in_bytes 应该等于 heap_max_in_bytes 。如果指派的大小更小,JVM 最终会被迫调整 heap 大小——这是一个非常昂贵的操作。如果你的数字不相等,阅读 堆内存:大小和交换 学习如何正确的配置它。

    heap_used_percent 指标是值得关注的一个数字。Elasticsearch 被配置为当 heap 达到 75% 的时候开始 GC。如果你的节点一直 >= 75%,你的节点正处于 内存压力 状态。这是个危险信号,不远的未来可能就有慢 GC 要出现了。

    如果 heap 使用率一直 >=85%,你就麻烦了。Heap 在 90–95% 之间,则面临可怕的性能风险,此时最好的情况是长达 10–30s 的 GC,最差的情况就是内存溢出(OOM)异常。

    线程池部分

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

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

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

    这里的一系列的线程池,大多数你可以忽略,但是有一小部分还是值得关注的:

    • indexing 普通的索引请求的线程池
    • bulk 批量请求,和单条的索引请求不同的线程池
    • get Get-by-ID 操作
    • search 所有的搜索和查询请求
    • merging 专用于管理 Lucene 合并的线程池

    网络部分

    • transport 显示和 传输地址 相关的一些基础统计值。包括节点间的通信(通常是 9300 端口)以及任意传输客户端或者节点客户端的连接。如果看到这里有很多连接数不要担心;Elasticsearch 在节点之间维护了大量的连接。
    • http 显示 HTTP 端口(通常是 9200)的统计值。如果你看到 total_opened 数很大而且还在一直上涨,这是一个明确信号,说明你的 HTTP 客户端里有没启用 keep-alive 长连接的。持续的 keep-alive 长连接对性能很重要,因为连接、断开套接字是很昂贵的(而且浪费文件描述符)。请确认你的客户端都配置正确。

    参考资料

    1、nodes-info

    2、nodes-stats

    3、ES监控指标

    最后:

    转载请注明地址:http://www.54tianzhisheng.cn/2017/10/18/ElasticSearch-nodes-metrics/

    image

    相关文章

      网友评论

        本文标题:Elasticsearch 系列文章(四):ElasticSea

        本文链接:https://www.haomeiwen.com/subject/tuqclftx.html