监控目标
1. 在elasticsearch配置文件上添加慢查询日志和慢索引配置
2. 使用kibana监测elasticsearch慢查询日志的生成,使用logstash抽取日志的方式,有慢查询日志生成,就以邮件告警的方式提醒。
3. 使用zabbix分别监控集群的状态、CPU、进程数、磁盘读写性能、JVM使用。同时还要监控elasticsearch中分片的状态。达到某个临界值,就以邮件告警的方式提醒。
4. 通过zabbix对es进行监控,当es挂掉后,以邮件告警的方式提醒。
通过kibana对慢查询日志的监控和zabbix对集群参数的监控。两个邮件告警方式在相差不大的时间发送邮件告警。可以快速找到问题所在。
优化方案
优化的主要目标是通过对分片和副本的设定、GC大小的设置、内存的分配进而加快查询的速度。
1. 分片和副本的分配
每个分片本质上就是一个Lucene索引,因此会消耗相应的文件权柄、内存和CPU资源。每个搜索请求会调度到索引的每个分片中,如何分片分散在不同的节点上问题还不大,但当分片竞争相同的硬件资源时,性能会逐步下降。
ES使用词频统计来计算相关性. 当然这些统计也会分配到各个分片上. 如果在大量分片上只维护了很少的数据, 则将导致最终的文档相关性较差。
通常认为随着业务的增长,他们的数据量也会相应的增加,所以很有必要为此做长期规划。很多人相信他们将会遇到暴发性增长(尽管大多数甚至都没有遇到过峰值),当然也希望避免重新分片并减少可能的停机时间。
Elastic官方建议一个node最好不要多于3个shards。
担心数据量增长,可以对elasticsearchJVM堆空间进行限制:最大推荐的是30-32G,所以每个分片的最大容量限制为30G
elasticsearch慢查询监控优化策略
最新推荐文章于 2024-05-25 22:02:26 发布