[Curator](https://www.elastic.co/guide/e ... x.html) 是elasticsearch 官方的一个索引管理工具，可以通过配置文件的方式帮助我们对指定的一批索引进行创建/删除、打开/关闭、快照/恢复等管理操作。

场景

比如，出于读写性能的考虑，我们通常会把基于时间的数据按时间来创建索引。

当数据量到达一定量级时，为了节省内存或者磁盘空间，我们往往会根据实际情况选择关闭或者删除一定时间之前的索引。通常我们会写一段脚本调用elasticsearch的api，放到crontab中定期执行。这样虽然可以达到目的，但是脚本多了之后会变得难以维护。

Curator是如何解决这类问题的呢？我们一步一步来：

安装

首先，Curator是基于python实现的，我们可以直接通过pip来安装，这种方式最简单。

bash<br /> pip install elasticsearch-curator<br />

基本配置

接下来，需要为 Curator 配置es连接:

```yaml

~/.curator/curator.yml

client:
hosts:

• 127.0.0.1
  port: 9200
  
  logging:
  loglevel: INFO
  ```
  
  其中hosts 允许配置多个地址，但是只能属于同一个集群。
  
  这边只列举了最基本的配置，[官方文档](https://www.elastic.co/guide/e ... e.html)中包含了更详细的配置。
  
  
  
  

  动作配置
  

  
  然后需要配置我们需要执行的动作，每个动作会按顺序执行：
  
  ```yaml
  

  /etc/curator/actions/maintain_log.yml
  

  
  actions:
  1:
  

  创建第二天的索引
  

  action: create_index
  description: "create new time-based index for log-*"
  options:
  name: '<log-{now/d+1d}>'
  2:
  

  删除3天前的索引
  

  action: delete_indices
  description: "delete outdated indices for log-*"
  filters:
  

• filtertype: pattern
  kind: prefix
  value: log
  
• filtertype: age
  source: name
  direction: older
  timestring: '%Y.%m.%d'
  unit: days
  unit_count: 3
  ```
  
  action 定义了需要执行的动作，curator支持十多种动作，可以在[官方文档](https://www.elastic.co/guide/e ... s.html)查看完整的动作列表。
  
  options 定义了执行动作所需的参数，不同动作的参数也不尽相同，具体文档中都有写明。
  
  filters 定义了动作的执行对象，通过设置filter，可以过滤出我们需要操作的索引。同一个action下的filter之间是且的关系。比如在上面的定义中，delete_indices下定义了两个filters：
  
  
  • 模式匹配：匹配前缀为log的索引
    
  • “年龄”匹配：根据索引名中“%Y.%m.%d”时间格式，过滤出3天以前的索引
    
    curator支持十多种filter，可以在[官方文档](https://www.elastic.co/guide/e ... s.html)查看完整列表。
    
    
    
    

    执行
    

    
    最后，我们通过curator命令行工具来执行：
    
    <br /> curator --config /etc/curator/curator.yml /etc/curator/actions/maintain_log.yml<br />
    
    得到命令行输出：
    
    <br /> 2018-08-30 12:31:26,829 INFO Preparing Action ID: 1, "create_index"<br /> 2018-08-30 12:31:26,841 INFO Trying Action ID: 1, "create_index": create new time-based index for log-*<br /> 2018-08-30 12:31:26,841 INFO "<log-{now/d+1d}>" is using Elasticsearch date math.<br /> 2018-08-30 12:31:26,841 INFO Creating index "<log-{now/d+1d}>" with settings: {}<br /> 2018-08-30 12:31:27,049 INFO Action ID: 1, "create_index" completed.<br /> 2018-08-30 12:31:27,050 INFO Preparing Action ID: 2, "delete_indices"<br /> 2018-08-30 12:31:27,058 INFO Trying Action ID: 2, "delete_indices": delete outdated indices for log-*<br /> 2018-08-30 12:31:27,119 INFO Deleting selected indices: ['log-2018.08.24', 'log-2018.08.25', 'log-2018.08.27', 'log-2018.08.26', 'log-2018.08.23']<br /> 2018-08-30 12:31:27,119 INFO ---deleting index log-2018.08.24<br /> 2018-08-30 12:31:27,120 INFO ---deleting index log-2018.08.25<br /> 2018-08-30 12:31:27,120 INFO ---deleting index log-2018.08.27<br /> 2018-08-30 12:31:27,120 INFO ---deleting index log-2018.08.26<br /> 2018-08-30 12:31:27,120 INFO ---deleting index log-2018.08.23<br /> 2018-08-30 12:31:27,282 INFO Action ID: 2, "delete_indices" completed.<br /> 2018-08-30 12:31:27,283 INFO Job completed.<br />
    
    从日志中可以看到，我们已经成功创建了隔天的索引，并删除了28号以前的索引。
    
    
    
    

    定时执行
    

    
    配置好curator后，还需要配置定时任务
    
    使用crontab -e编辑crontab，
    
    添加一行：
    
    bash<br /> 0 23 * * * /usr/local/bin/curator --config /root/.curator/curator.yml /etc/curator/actions/maintain_log.yml >> /var/curator.log 2>&1<br />
    
    crontab配置中的第一段是执行的周期，6个值分别是“分 时 日 月 周”，*表示全部。所以这段配置的含义是在每天23点执行我们的这段脚本。
    
    
    
    

    单个执行
    

    
    除了定时任务，我们也可以在不依赖action配置文件的情况下用curator执行一些临时的批量操作。curator提供了curator_cli的命令来执行单个action，比如我们想对所有log开头的索引做快照，使用一条命令即可完成：
    
    bash<br /> curator_cli snapshot --repository repo_name --filter_list {"filtertype": "pattern","kind": "prefix", "value": "log"}<br />
    
    是不是特别方便？
    
    
    
    

    执行流程
    

    
    

    
    

    
    在命令执行过程中，Curator 会进行以下几步操作：
    
    

    1. 从ES拉取所有的索引信息
       
    2. 根据设置的过滤条件过滤出需要操作的索引
       
    3. 对过滤后的索引执行指定的动作
       
       
       
       

       复杂需求
       

       
       实际生产中，会有一些更复杂的需求，简单的action和filter组合并不能满足我们的业务。Curator还提供了[python包](https://curator.readthedocs.io/en/latest/)，方便我们自己写脚本时调用它提供的actions和filters，减少我们的开发工作量。
       
       
       
       以上通过一个实际的场景向大家介绍了Curator的使用方式，但是只用到了它一小部分的功能。大家可以通过文中的链接查看官方文档，发掘出更多的使用姿势。希望对大家有所帮助！
       
       

在 Elasticsearch 中处理字符串类型的数据时，如果我们想把整个字符串作为一个完整的 term 存储，我们通常会将其类型 type 设定为 keyword。但有时这种设定又会给我们带来麻烦，比如同一个数据再写入时由于没有做好清洗，导致大小写不一致，比如 apple、Apple两个实际都是 apple，但当我们去搜索 apple时却无法返回 Apple的文档。要解决这个问题，就需要 Normalizer出场了。废话不多说，直接上手看！

1. 上手

我们先来重现一下开篇的问题

```json
PUT test_normalizer
{
"mappings": {
"doc":{
"properties": {
"type":{
"type":"keyword"
}
}
}
}
}

PUT test_normalizer/doc/1
{
"type":"apple"
}

PUT test_normalizer/doc/2
{
"type":"Apple"
}

查询一

GET test_normalizer/_search
{
"query": {
"match":{
"type":"apple"
}
}
}

查询二

GET test_normalizer/_search
{
"query": {
"match":{
"type":"aPple"
}
}
}
``<br /> <br /> 大家执行后会发现查询一返回了文档1，而查询二`没有文档返回，原因如下图所示：


1. Docs写入 Elasticsearch时由于 type是 keyword,分词结果为原始字符串
   
2. 查询 Query 时分词默认是采用和字段写时相同的配置，因此这里也是 keyword，因此分词结果也是原始字符
   
3. 两边的分词进行匹对，便得出了我们上面的结果
   
   
   
   

   2. Normalizer
   

   
   normalizer是 keyword的一个属性，可以对 keyword生成的单一 Term再做进一步的处理，比如 lowercase，即做小写变换。使用方法和自定义分词器有些类似，需要自定义，如下所示：
   
   ```json
   DELETE test_normalizer
   

   自定义 normalizer
   

   PUT test_normalizer
   {
   "settings": {
   "analysis": {
   "normalizer": {
   "lowercase": {
   "type": "custom",
   "filter": [
   "lowercase"
   ]
   }
   }
   }
   },
   "mappings": {
   "doc": {
   "properties": {
   "type": {
   "type": "keyword"
   },
   "type_normalizer": {
   "type": "keyword",
   "normalizer": "lowercase"
   }
   }
   }
   }
   }
   
   
   PUT test_normalizer/doc/1
   {
   "type": "apple",
   "type_normalizer": "apple"
   }
   
   
   PUT test_normalizer/doc/2
   {
   "type": "Apple",
   "type_normalizer": "Apple"
   }
   

   查询三
   

   GET test_normalizer/_search
   {
   "query": {
   "term":{
   "type":"aPple"
   }
   }
   }
   
   

   查询四
   

   GET test_normalizer/_search
   {
   "query": {
   "term":{
   "type_normalizer":"aPple"
   }
   }
   }
   ``<br /> <br /> 我们第一步是自定义了名为lowercase的 normalizer，其中filter类似自定义分词器中的filter，但是可用的种类很少，详情大家可以查看官方文档。然后通过normalizer属性设定到字段type_normalizer中，然后插入相同的2条文档。执行发现，查询三无结果返回，查询四`返回2条文档。
   
   问题解决了！我们来看下是如何解决的
   
   
   
   

4. 文档写入时由于加入了 normalizer,所有的 term都会被做小写处理
   
5. 查询时搜索词同样采用有 normalizer的配置，因此处理后的 term也是小写的
   
6. 两边分词匹对，就得到了我们上面的结果
   
   
   

   3. 总结
   

   
   本文通过一个实例来给大家讲解了 Normalizer的实际使用场景，希望对大家有所帮助！