“ 本片主要通过两个API讲解Elasticsearch集群监控的指标说明”
Elasticsearch版本:6.2.4
一、集群健康
一个Elasticsearch
集群至少包括一个节点和一个索引。或者它 可能有一百个数据节点、三个单独的主节点,以及一小打客户端节点——这些共同操作一千个索引(以及上万个分片)。
不管集群扩展到多大规模,你都会想要一个快速获取集群状态的途径。Cluster Health API
充当的就是这个角色。你可以把它想象成是在一万英尺的高度鸟瞰集群。它可以告诉你安心吧一切都好,或者警告你集群某个地方有问题。
让我们执行一下cluster-health API
然后看看响应体是什么样子的:
GET _cluster/health
和Elasticsearch
里其他API
一样,cluster-health
会返回一个JSON
响应。这对自动化和告警系统来说,非常便于解析。响应中包含了和你集群有关的一些关键信息:
{
cluster_name: "elasticsearch",
status: "yellow",
timed_out: false,
number_of_nodes: 3,
number_of_data_nodes: 3,
active_primary_shards: 13,
active_shards: 30,
relocating_shards: 0,
initializing_shards: 0,
unassigned_shards: 4,
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: 88.23529411764706
}
响应信息中最重要的一块就是status
字段。状态可能是下列三个值之一:
green
所有的主分片和副本分片都已分配。你的集群是
100%
可用的。yellow
所有的主分片已经分片了,但至少还有一个副本是缺失的。不会有数据丢失,所以搜索结果依然是完整的。不过,你的高可用性在某种程度上被弱化。如果更多的分片消失,你就会丢数据了。把
yellow
想象成一个需要及时调查的警告。red
至少一个主分片(以及它的全部副本)都在缺失中。这意味着你在缺少数据:搜索只能返回部分数据,而分配到这个分片上的写入请求会返回一个异常。
green
/yellow
/red
状态是一个概览你的集群并了解眼下正在发生什么的好办法。剩下来的指标给你列出来集群的状态概要:
number_of_nodes
和number_of_data_nodes
这个命名完全是自描述的,代表ElasticSearch
节点数量。active_primary_shards
指出你集群中所有索引的活跃的主分片数量。active_shards
是涵盖了所有索引的所有活跃分片的汇总值,也包括副本分片。relocating_shards
显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0,不过在Elasticsearch
发现集群不太均衡时,该值会上涨。比如说:添加了一个新节点,或者下线了一个节点。initializing_shards
是刚刚创建的分片的个数。比如,当你刚创建第一个索引,分片都会短暂的处于initializing
状态。这通常会是一个临时事件,分片不应该长期停留在initializing
状态。你还可能在节点刚重启的时候看到initializing
分片:当分片从磁盘上加载后,它们会从initializing
状态开始。unassigned_shards
是已经在集群状态中存在的分片,但是实际在集群里又找不着(未分配)。通常未分配分片的来源是未分配的副本。比如,一个有 5 分片和 1 副本的索引,在单节点集群上,就会有 5 个未分配副本分片。如果你的集群是red
状态,也会长期保有未分配分片(因为缺少主分片)。active_shards_percent_as_number
代表所有索引的活跃分片占总分片的百分比。
二、集群指标统计
集群统计API可以通过如下命令执行:
GET _cluster/stats
1. 索引部分
indices: {
count: 3,
shards: {
total: 30,
primaries: 13,
replication: 1.3076923076923077,
index: {...}
},
docs: {
count: 3,
deleted: 0
},
store: {
size_in_bytes: 35195
},
count
代表索引数量shards.total
代表集群中所有活跃的分片数量,也包括副本分片shard.primaries
代表集群中所有活跃的主分片数量docs
展示节点内存有多少文档,包括还没有从segments
里清除的已删除文档数量store
显示集群索引耗用了多少物理存储。这个指标包括主分片和副本分片在内
"fielddata": {
"memory_size_in_bytes": 0,
"evictions": 0
}
field_data
显示fielddata
使用的内存,用以聚合、排序等等。这里也有一个驱逐计数。这里的驱逐计数是很有用的:这个数应该或者至少是接近于0
。因为fielddata
不是缓存,任何驱逐都消耗巨大,应该避免掉。如果你在这里看到驱逐数,你需要重新评估你的内存情况,fielddata
限制,请求语句,或者这三者。
segments: {
count: 5,
memory_in_bytes: 8492,
terms_memory_in_bytes: 5945,
stored_fields_memory_in_bytes: 1560,
term_vectors_memory_in_bytes: 0,
norms_memory_in_bytes: 640,
points_memory_in_bytes: 7,
doc_values_memory_in_bytes: 340,
index_writer_memory_in_bytes: 0,
version_map_memory_in_bytes: 0,
fixed_bit_set_memory_in_bytes: 0,
max_unsafe_auto_id_timestamp: -1,
file_sizes: { }
}
segments
会展示这个节点目前正在服务中的Lucene
段的数量。这是一个重要的数字。大多数索引会有大概50–150
个段,哪怕它们存有TB
级别的数十亿条文档。段数量过大表明合并出现了问题(比如,合并速度跟不上段的创建)。注意这个统计值是节点上所有索引的汇聚总数。记住这点。memory
统计值展示了Lucene
段自己用掉的内存大小。这里包括底层数据结构,比如倒排表,字典,和布隆过滤器等。太大的段数量会增加这些数据结构带来的开销,这个内存使用量就是一个方便用来衡量开销的度量值。
2. 操作系统和进程部分
os: {
available_processors: 6,
allocated_processors: 6,
names: [
{
name: "Linux",
count: 3
}
],
mem: {
total_in_bytes: 24558551040,
free_in_bytes: 850542592,
used_in_bytes: 23708008448,
free_percent: 3,
used_percent: 97
}
},
process: {
cpu: {
percent: 0
},
open_file_descriptors: {
min: 201,
max: 221,
avg: 213
}
}
OS
和Process
部分基本是自描述的,不会在细节中展开讲解。它们列出来基础的资源统计值,比如CPU
和负载。OS
部分描述了整个操作系统,而Process
部分只显示Elasticsearch
的JVM
进程使用的资源情况。
这些都是非常有用的指标,不过通常在你的监控技术栈里已经都测量好了。统计值包括下面这些:
CPU
负载
内存使用率
Swap 使用率
打开的文件描述符
3. JVM部分
jvm: {
max_uptime_in_millis: 89144412,
versions: [
{
version: "1.8.0_151",
vm_name: "Java HotSpot(TM) 64-Bit Server VM",
vm_version: "25.151-b12",
vm_vendor: "Oracle Corporation",
count: 3
}
],
mem: {
heap_used_in_bytes: 516307208,
heap_max_in_bytes: 3168927744
},
threads: 111
}
max_uptime_in_millis
显示Elasticsearch
集群运行的时长heap_used_in_bytes
/heap_max_in_bytes
代表heap_used_percent
heap_used_percent
指标是值得关注的一个数字。Elasticsearch
被配置为当 heap达到 75% 的时候开始GC。如果你的节点一直>= 75%,你的节点正处于内存压力状态。这是个危险信号,不远的未来可能就有慢GC
要出现了。如果
heap
使用率一直>=85%
,你就麻烦了。Heap
在90–95%
之间,则面临可怕的性能风险,此时最好的情况是长达10–30s
的GC
,最差的情况就是内存溢出(OOM)异常。threads
代表已配置的线程数量
三、参考链接
集群健康:https://www.elastic.co/guide/cn/elasticsearch/guide/current/_cluster_health.html
监控单个节点:https://www.elastic.co/guide/cn/elasticsearch/guide/current/_monitoring_individual_nodes.html
长按下方二维码,关注更多精彩内容
如果感觉本文对您有帮助,请点击右下角‘好看’支持一下,您的支持是我坚持写作最大的动力,谢谢!
如果您有疑问,可点击阅读全文进行评论,作者会第一时间回复。