作者:焦振清
时间:2018-06-26
基于Google的监控方案,将ES监控归为两大类五个子类,分别是黑盒监控和白盒监控(四个黄金指标),详情可以参考书籍《SRE Google运维解密》第53页
黑盒监控
- 功能监控
- Health:Green
白盒监控
- 错误
- Active_shards_percent_as_number
- Number_of_pending_task
- index/bulk/search_rejected(thread_pool)
- Nodes_failed
- 延时
- Indexing Latency(ms)
- Search Latency(ms)
- slowlog
- 容量
- Disk Available
- JVM Heap
- Load_1m
- CPU_usage
- Active Shards:单实例20分片 * 节点数 (最高不超过一万个分片)
- index/bulk/search_queue(thread_pool)
- 流量
- Indexing Rate
- Search Rate
- Cluster_io_Write
- Cluster_io_read
- Cluster_net_in
- Cluster_net_out
风险提示 :上述指标大部分都是基于ES接口进行的采集,因此在ES故障期间,上述指标可能无法采集,因此,还需要通过服务监控(进程,端口,日志,机器)进行部分替代,避免是否复盘无数据可供参考和分析。
服务监控
- 进程监控
- JVM监控
- cpu/io/net(如无法采集可用机器相关指标替代)
- 语义监控
- 对ES端口进行Http返回内容校验而非仅判断端口是否打开
- 日志监控
- 针对WARN级别以上日志进行监控
- 机器监控
- server_load
指标说明:
1,Active Shards:不超过一万个分片。官方推荐,单个实例JVM内存不超过30GB,不超过600个分片。另外,分片是由Master来维护其状态的,而Master在任何集群规模下,有且仅有一个节点在工作,其余均为热备节点,因此分片数量越高,Master常态的压力越大,故障后恢复的耗时也越长。
2,功能监控,需要周期性检测ES集群能否创建索引,创建文档,读取文档,删除文档,删除索引。
3,Search和Indexing Rate,需要监控总量,但是需要采集主要index的数据,便于问题定位。例如哪个索引突增流量将集群压垮了?如果没有细化的index的相关数据采集,就只能通过index的体积来进行间接判断,延时也类似。
4,Active_shards_percent_as_number,监控该值,可以覆盖所有非正常的情况,而不必对每种异常情况进行监控,这样可能会有遗漏,常见的错误情况包括:Unassigned Shards ,Initializing Shards ,Relocating Shards,Delayed_unassigned_shards
5,Number_of_pending_task,反应了Master节点尚未执行的集群级别的更改任务(例如:创建索引,更新映射,分配分片)的列表。pending task的任务是分级别的(优先级排序:IMMEDIATE>URGENT>HIGH>NORMAL>LOW>LANGUID),只有当上一级别的任务执行完毕后才会执行下一级别的任务。
6,Nodes_failed,是从该接口获取,http://localhost/_cluster/stats?pretty
附:http://localhost/_cluster/health?pretty
"cluster_name" : "jdcloud-es",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 23,
"number_of_data_nodes" : 17,
"active_primary_shards" : 4022,
"active_shards" : 8044,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"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" : 100.0