日志用的es集群平时基本上只提供kibana给人查日志用，grafana上有个别图表也会用到
但是因为grafana上配置了这个es的数据源，有人有权限可以看到ES地址，也不保证有人直接通过程度连接ES的可能。
最近看监控，经常不定期的会有一波所有节点old gc数量突然增多，有时候是突然所有节点cpu升高的情况。
但是在慢查日志里，并没有发现有用时特别长的查询，也没发现有和平时不一样的查询(也有可能混在大量的查询里我没有发现)
怎么样能比较有效的发现是哪个查询导致了这种情况呢，或者如果不是查询的话，还有哪些原因可能导致这种现象。有什么好的查问题的手段吗？
另外延伸出来的话题就是怎么对kibana进行管控，比如限制查询的时间范围，限制查询中设置的size过大，限制查询的频率(因为越慢的查询有人越等不及多刷新好几次)等等。
但是因为grafana上配置了这个es的数据源，有人有权限可以看到ES地址，也不保证有人直接通过程度连接ES的可能。
最近看监控，经常不定期的会有一波所有节点old gc数量突然增多，有时候是突然所有节点cpu升高的情况。
但是在慢查日志里，并没有发现有用时特别长的查询，也没发现有和平时不一样的查询(也有可能混在大量的查询里我没有发现)
怎么样能比较有效的发现是哪个查询导致了这种情况呢，或者如果不是查询的话，还有哪些原因可能导致这种现象。有什么好的查问题的手段吗？
另外延伸出来的话题就是怎么对kibana进行管控，比如限制查询的时间范围，限制查询中设置的size过大，限制查询的频率(因为越慢的查询有人越等不及多刷新好几次)等等。
2 个回复
匿名用户
赞同来自:
1首先要考虑并发查询的量,如果量非常的大,是很大可能造成CPU和load飙升.
2如果查询量很小,那看看是否存在重型的聚合查询,(基于10亿数据的聚合),又存在一定量的并发,非常非常大的几率造成cpu和load飙升.
3系统的某些参数,也会造成load负载飙高.比如虚拟内存相关的配置.
4linux 系统如果配置的不好,也会出现问题
5ES集群瞬间删除大量(可能是几百个索引或者几百GB)的索引,短时间内io操作频繁,会引起load标高
访问限制问题
1高版本已经有权限的控制了
2可以利用linux防火墙,将es,kibana等封起来,只对外暴露一个URL.比如nginx代理服务器
3利用nginx可以对访问的url进行重写,过滤掉一些非法的操作和参数
4也可以修改kibana和es源码进行请求的校验
ES 是一个高消耗硬件资源(非常消耗硬件资源),并且无法无限制的横向扩展,问题非常多(BUG特别多,问题特别多,还没有什么解决方案)的开源的全文检索引擎.
Within - just do it
赞同来自: