1.使用python操作ES
http://t.cn/RBzKP6H
2.使用Beats模块将日志和指标导入ES
http://t.cn/RdLtJJp
3.如何在生产环境中重启Elasticsearch集群
http://t.cn/RdL4oxk 

活动预告
1. 7月21日上海meetup演讲申请中
https://elasticsearch.cn/m/article/655 

编辑：sterne vencel
归档：https://elasticsearch.cn/article/700
订阅：https://tinyletter.com/elastic-daily

阅读本文前，请先阅读[ES内存分析](https://elasticsearch.cn/article/698)。
ES默认配置下，heap是存在超卖情况的。


| 类目 | 默认占比 | 是否常驻 | 淘汰策略(在控制大小情况下) | 控制参数 |
| --- | --- | --- | --- | --- |
| query cache | 10% | 是 | LRU | indices.queries.cache.size |
| request cache | 1% | 是 | LRU | indices.requests.cache.size |
| fielddata cache | 无限制 | 是 | LRU | indices.fielddata.cache.size |
| segment memory | 无限制 | 是 | 无 | 不能通过参数控制 |
| common space | 70% | 否 | GC | 通过熔断器 indices.breaker.total.limit 限制 |

common space(可GC)


| 子类目 | 默认占比 | 控制参数 |
| --- | --- | --- |
| indexing buffer | 10% | indices.memory.index_buffer_size |
| request agg data | 60% | indices.breaker.request.limit |
| in-flight data | 100% | network.breaker.inflight_requests.limit |

通过上表可知，segment memory是非常重要，而且是不可通过参数干预的内存空间，而cache部分则可以提升性能，可以被清除。common space 是运行时的动态空间，可以被GC。

综上所述，需要保证segment memory+cache+common space不超过100%。由于熔断器是按整个heap大小来计算的，所以如果segment memory 过大，仍然可能会导致OOM。为了减少这种情况的发生，需要预留足够空间给segment。
优化

1. 限制fielddata大小，fielddata是针对text类型进行排序、聚合才用到。正常应该避免这种情况发生。
   
2. 限制request agg data大小，这个参数会影响聚合使用的内存，如果触发熔断，业务需要进行优化。
   
   

   内存分配
   

   
   
   

   
    
      
        
        
        
      
      
        
          
          
          
        
        
          
          
          
        
        
          
          
          
        
        
          
          
          
        
        
          
          
          
        
        
          
          
          
        
        
          
          
        
      
    

   segment memory	预留10%
   fielddata cache	限制在20%
   query cache	限制10%
   request cache	限制1%
   indexing buffer	限制10%
   request agg data	限制1%	父熔断器配置30%，扣除fielddata,agg剩余的就是in-flight
   in-flight data	限制9%

   
   
   
   
   参数设置
   ```plain
   indices.fielddata.cache.size:1%--需要重启节点
   
   PUT _cluster/settings
   {
     "persistent": {
       "indices.breaker.fielddata.limit":"20%",
       "indices.breaker.request.limit":"1%",
       "indices.breaker.total.limit":"70%"
   
     }
   }
   ```
   

内存占用

ES的JVM heap按使用场景分为可GC部分和常驻部分。
可GC部分内存会随着GC操作而被回收；
常驻部分不会被GC，通常使用LRU策略来进行淘汰；
内存占用情况如下图：

common space包括了indexing buffer和其他ES运行需要的class。indexing buffer由indices.memory.index_buffer_size参数控制， 默认最大占用10%，当full up后，该部分数据被刷入磁盘对应的Segments中。这部分空间是可以被回收反复利用的。

queryCache 是node级别的filter过滤器结果缓存，大小由indices.queries.cache.size 参数控制，默认10%。使用LRU淘汰策略。

requestCache是shard级别的query result缓存，通常 only requests of size 0 such as aggregations, counts and suggestions will be cached。使用LRU淘汰策略。通过indices.requests.cache.size参数控制，默认1%。设置后整个NODE都生效。

fieldDataCache，针对text字段，没有docValues属性(相当于列存储)，当对text类型字段进行sort,agg时，需要将对应的字段内容全部加载到内存，这部分数据就放在fieldDataCache。通过indices.fielddata.cache.size 参数限制大小，默认不限制。这种情况下，占用内存会逐渐增多，直到触发熔断；新数据无法加载。

segmentsMemory ，缓存段信息，包括FST,Dimensional points for numeric range filters，Deleted documents bitset ，Doc values and stored fields codec formats等数据。这部分缓存是必须的，不能进行大小设置，通常跟index息息相关，close index、force merge均会释放部分空间。
可以通过命令
js<br /> GET _cat/nodes?v&h=id,ip,port,r,ramPercent,ramCurrent,heapMax,heapCurrent,fielddataMemory,queryCacheMemory,requestCacheMemory,segmentsMemory<br />

查看当前各块的使用情况。

熔断器

Elasticsearch 有一系列的断路器，它们都能保证内存不会超出限制：

• indices.breaker.fielddata.limit
  fielddata 断路器默认设置堆的 60% 作为 fielddata 大小的上限。
  
• indices.breaker.request.limit
  request 断路器估算需要完成其他请求部分的结构大小，例如创建一个聚合桶，默认限制是堆内存的 60%。它实际上是node level的一个统计值，统计的是这个结点上，各类查询聚合操作，需要申请的Bigarray的空间大小总和。 所以如果有一个聚合需要很大的空间，同时在执行的聚合可能也会被break掉。
  
• indices.breaker.total.limit
  父熔断，inflight、request(agg)和fielddata不会使用超过堆内存的 70%。
  
• network.breaker.inflight
  requests.limit 限制当前通过HTTP等进来的请求使用内存不能超过Node内存的指定值。这个内存主要是限制请求内容的长度。 默认100%。
  
• script.max_compilations_per_minute
  
• 限制script并发执行数，默认值为15。
  
  
  参考文档
  https://www.elastic.co/guide/e ... eaker
  https://www.elastic.co/guide/c ... .html
  http://zhengjianglong.leanote. ... %25AE
  

1.es与solr的15个不同点； 
http://t.cn/RdwtPxy 
2.ES熔断器了解一下； 
http://t.cn/Rd7tMFJ 
3.如何取消一个ES检索； 
http://t.cn/Rd7cdBi 
 
活动预告 
1. 7月21日上海meetup演讲申请中 
https://elasticsearch.cn/m/article/655 
 
编辑：wt 
归档：https://elasticsearch.cn/article/697
订阅：https://tinyletter.com/elastic-daily

今天介绍一下 Kibana 的里程碑插件的使用，这个是一个相对还比较新的可视化插件，可以用来对具有时间上下文相关的数据，以里程碑的方式来展现这些数据点在时间轴上的关联性。

这样说可能比较抽象，举个荔枝，你在 Elasticsearch 里面存的是服务器日志信息，然后有一天，老板说网站很慢，帮忙重启一下，（老板听说重启可以解决问题，反正他说他的笔记本重启之后就老快了），这个是一个已知的维护动作，所以你默默的在后台记录了重启的时间和是谁叫你重启的（这里是老板），到了月底的时候，老板让你把这个月的服务器运行数据给他看，然后问你为什么某一个时间服务器请求都为0，你打开 Kibana，指着其中一个时间点说，诺，这里，你让我重启了服务器。

是的，你可以对数据进行注解，用来解释数据和异常，这个是一个很好的场景，另外，还可以关联持续集成工具，每次谁代码提交了，你把这个作为一个事件，存到 es 里面，然后用里程碑可视化显示，那么这个提交造成的服务运行指标的变化，比如性能提升和下降，就会非常直观的关联到这次代码提交，同理，软件版本的发布也是一个里程碑事件，也可以展示并关联起来。然后，在使用的时候，还可以根据时间定位到感兴趣的地方，查看该段时间都发生了哪些自定义的事件和日志，方便分析。做安全方面的分析也可以用来跟踪和做入侵事后复盘的注解。

是不是，很多地方都能使用这个插件呢。

插件地址：[https://github.com/walterra/kibana-milestones-vis/](https://github.com/walterra/kibana-milestones-vis/)

演示截图：




关于如何使用，其实在该项目的 README 里面已经比较详细了。

1.首先找到对应的 Kibana 插件的版本，如果没有可能需要手动编译插件，有的话，直接找到下载地址。
[https://github.com/walterra/ki ... eases](https://github.com/walterra/ki ... leases)

2.使用 Kibana 的插件安装命令下载安装

```
➜ kibana-6.2.4-darwin-x86_64 bin/kibana-plugin install https://github.com/walterra/ki ... 4.zip
Found previous install attempt. Deleting...
Attempting to transfer from https://github.com/walterra/ki ... 4.zip
Transferring 1353656 bytes....................
Transfer complete
Retrieving metadata from plugin archive
Extracting plugin archive
Extraction complete
Optimizing and caching browser bundles...

```

3.启动 Kibana，然后进入 Visualize 面板，应该就能找到这个新的 Milestone 类型的可视化组件了。






加两个维护日志






和日志关联分析


4.还有一个隐藏的秘籍，就是可以支持图片作为标注




用图片代替文字，是不是更直观，如果你的数据是电影相关的，你可以放一个电影海报替代，如果你的是历史人物相关的，比如，可以换成人物头像，地点等等。

好了，是不是很炫，快去自己试试吧。

1.提升Elasticsearch查询性能的七个小贴士。
http://t.cn/RrkMzQn 
2.使用ELK分析Nginx日志实战。
http://t.cn/RBTxsci 
3.使用Kafka Streams和Elasticsearch 构建home feed。
http://t.cn/Rrk4z0S 

活动预告
1. 7月21日上海meetup演讲申请中
https://elasticsearch.cn/m/article/655 

编辑：叮咚光军
归档：https://elasticsearch.cn/article/695 
订阅：https://tinyletter.com/elastic-daily