1. solr以及es的相似度解析 http://t.cn/EfLLxzD

2.搭建ES集群全步骤 http://t.cn/EfLWeSG

3. 用ElasticSearch实现漏斗用户旅程跟踪服务(自备梯子） http://t.cn/EfLHsOM

• 编辑：bsll

• 归档：https://elasticsearch.cn/article/6396

• 订阅：https://tinyletter.com/elastic-daily

ELK Tips 主要介绍一些 ELK 使用过程中的小技巧，内容主要来源为 Elastic 中文社区。

一、Logstash

1、Logstash 性能调优主要参数

• pipeline.workers：设置启动多少个线程执行 fliter 和 output；当 input 的内容出现堆积而 CPU 使用率还比较充足时，可以考虑增加该参数的大小；
• pipeline.batch.size：设置单个工作线程在执行过滤器和输出之前收集的最大事件数，较大的批量大小通常更高效，但会增加内存开销。输出插件会将每个批处理作为一个输出单元。；例如，ES 输出会为收到的每个批次发出批量请求；调整 pipeline.batch.size 可调整发送到 ES 的批量请求（Bulk）的大小；
• pipeline.batch.delay：设置 Logstash 管道的延迟时间， 管道批处理延迟是 Logstash 在当前管道工作线程中接收事件后等待新消息的最长时间（以毫秒为单位）；简单来说，当 pipeline.batch.size 不满足时，会等待 pipeline.batch.delay 设置的时间，超时后便开始执行 filter 和 output 操作。

2、'reader' unacceptable character ' ' (0x0)

logstash 执行使用 Jdbc input plugin 后报错：

[main]-pipeline-manager] ERROR logstash.agent - Pipeline aborted due to error {
:exception=>#<Psych::SyntaxError: (): 'reader' unacceptable character ' ' (0x0) special characters are not allowed in "'reader'", 
position 0 at line 0 column 0>, :backtrace=>["org/jruby/ext/psych/PsychParser.java:232:in parse'"

解决方案：删除 $USER_HOME/.logstash_jdbc_last_run 文件即可。

二、Elasticsearch

1、TermsQuery 与多个 TermQuery 的区别

当 terms 的个数较少的时候，TermsQuery 等效为 ConstantScoreQuery 内部包含多个 TermQuery：

Query q1 = new TermInSetQuery(new Term("field", "foo"), new Term("field", "bar"));
// 等效为下面的语句
BooleanQuery bq = new BooleanQuery();
bq.add(new TermQuery(new Term("field", "foo")), Occur.SHOULD);
bq.add(new TermQuery(new Term("field", "bar")), Occur.SHOULD);
Query q2 = new ConstantScoreQuery(bq);

当 terms 较多的时候，它将使用匹配的文档组合成一个位集，并在该位集上进行评分；此时查询效率比普通的 Bool 合并要更加高效。

当 terms 的个数较多时，TermsQuery 比多个 TermQuery 组合的查询效率更高。

2、ES 借助 nginx 配置域名

upstream /data/ {
    server 192.168.187.xxx:9200;
    keepalive 300 ;
}

server {
    listen 80;
    server_name testelk.xx.com;
    keepalive_timeout 120s 120s;
    location /data {
        proxy_pass http://data/;
        proxy_http_version 1.1;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass_header remote_user 
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header Host $http_host;
        proxy_set_header X-Nginx-Proxy true;
    }
}

3、ES Reindex 时如何不停止写入服务

方案一：kennywu76

ES 的 reindex 在索引有实时的 update/delete 的情况下，即使借助 alias，也没有办法实现真正的 zero down time。

增加新文档比较好办，通过 alias 切换写入到新索引，同时 reindex 做旧->新索引的数据传输即可；但是 update/delete 操作针对的文档如果还未从旧索引传输过来，直接对新索引操作会导致两个索引数据不一致。

我能够想到的（一个未经实际验证）的方案，前提是数据库里的文档有一个类似 last_update_time 字段记录文档最后更新的时间，用作写入 ES 文档的版本号，然后数据写入新索引的时候，url 里带上下面这样的参数:version_type=external_gt&version=xxxxxx。

其中 version_type=external_gt 表示写入文档的版本号大于已有的文档版本号，或者文档不存在，写入才会成功，否则会抛版本冲突的异常。另外 delete 操作都要转换成 index 操作，index 的内容可以是一个空文档。

这样实时数据写入新索引和 reindex 可以同时进行，实时写入的数据应该具有更高的版本，总是能够成功，reindex 如果遇到版本冲突，说明该文档被实时部分更新过了，已经过时，可以直接放弃跳过。

该方案的缺陷:

• 要求数据源里的数据具有版本信息，可能因为各种局限，不太容易更改；
• delete 操作必须转化为写入一个空文档，delete 实际上是一个标记文档，并且本身也有版本信息。但是如果后端发生了 segment merge，delete 可能会被合并以后物理清除。这样 delete 和对应的版本信息丢失，之后 reindex 如果写入了旧版本的文档，仍然会有一致性问题；但是空文档会增加索引文件的大小，有额外的消耗，一个可能的缓解办法是在 reindex 全部做完以后，再做一次空文档的删除。

改进方案：the_best

重建索引步骤如下：

1. 保证 delete 操作都要转换成 index 操作，index 的内容可以是一个空文档；
2. 对老索引 old_index（业务上的别名还是挂在老索引上）进行重索引操作（version_type=external）；

   curl -X POST 'http://<hostname>:9200/_reindex'
   {
   "conflicts": "proceed",
   "source": {
       "index": "old_index",
       "size": 1000
   },
   "dest": {
       "index": "new_index",
       "version_type": "external"
   }
   }

3. 将别名切到 newIndex；
4. 将重索引时间段内 old_index 产生的热数据，再捞一次到 new_index 中（conflicts=proceed&version_type=external）；

   curl -X POST /_reindex
   {
   "conflicts": "proceed",
   "source": {
       "index": "old_index"
       "query": {
           "constant_score" : {
               "filter" : {
                   "range" : {
                       "data_update_time" : {
                           "gte" : <reindex开始时刻前的毫秒时间戳>
                       }
                   }
               }
           }
       }
   },
   "dest": {
       "index": "new_index",
       "version_type": "external"
   }
   }

5. 手动做一次空文档的删除。

这种方式取决于重索引期间产生的数据量大小（会影响步骤4的用时），不过我们可以视具体业务情况灵活操作。比如说数据量比较大重索引我们用了10个小时（这10个小时内新产生了200多万的数据），在切别名前，我们可以按步骤（4）的调用方式，把近10个小时的数据再捞一遍到新索引中，如此迭代个几次，直到别名切完后，我们能保证最后一次的步骤（4）可以在较短时间内完成。

4、ES 节点通讯配置

http.port: 9200
http.bind_host: 127.0.0.1
transport.tcp.port: 9300
transport.bind_host: 127.0.0.1

5、把 Lucene 的原生 query 传给 ES

SearchRequest searchRequest = new SearchRequest(indexName);
searchRequest.types(typeName);
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
sourceBuilder.from(0);
sourceBuilder.size(10);
sourceBuilder.timeout(new TimeValue(60, TimeUnit.SECONDS));

//q为Lucene检索表达式, 直接输入关键词匹配_all或者*字段, 字段匹配user:kimchy, 
//多字段匹配user:kimchy AND message:Elasticsearch
QueryStringQueryBuilder queryStringQueryBuilder = QueryBuilders.queryStringQuery(q); 
sourceBuilder.query(queryStringQueryBuilder);
searchRequest.source(sourceBuilder);
SearchResponse searchResponse = restHighLevelClient.search(searchRequest);
SearchHits searchHits = searchResponse.getHits();

6、ES 文档字段个数限制

ES 文档默认不允许文档字段超过 1000，超过 1000 会报如下错误：

failed to put mappings on indices [[[nfvoemspm/srjL3cMMRUqa7DgOrYqX-A]]], type [log]
java.lang.IllegalArgumentException: Limit of total fields [1000] in index [xxx] has been exceeded

可以通过修改索引配置来修改字段个数限制，不过还是推荐从业务上进行优化：

修改settings
{
  "index.mapping.total_fields.limit": 2000
}

7、将 DSL 字符串转换为 QueryBuilder

## wrapper 案例
GET /_search
{
    "query" : {
        "wrapper": {
            "query" : "eyJ0ZXJtIiA6IHsgInVzZXIiIDogIktpbWNoeSIgfX0=" 
        }
    }
}

## RestClient
QueryBuilders.wrapperQuery("{\"term\": {\"field\":\"value\"}}")

8、ES 集群重启后 Slice Scroll 速度变慢

重启机器之后，pagecache 都没有了，所有数据都要重新从磁盘加载。

9、ES 开启索引新建删除日志

PUT _cluster/settings
{
  "persistent": {
    "logger.cluster.service": "DEBUG"
  }
}

10、慢日志全局级别设定

1. 对已经存在的索引可以通过 PUT _settings 做存量设置
2. 对之后新增的索引，可以使用类似于下面的template

   PUT _template/global-slowlog_template
   {
   "order": -1,
   "version": 0,
   "template": "*",
   "settings": {
       "index.indexing.slowlog.threshold.index.debug" : "10ms",
       "index.indexing.slowlog.threshold.index.info" : "50ms",
       "index.indexing.slowlog.threshold.index.warn" : "100ms",
       "index.search.slowlog.threshold.fetch.debug" : "100ms",
       "index.search.slowlog.threshold.fetch.info" : "200ms",
       "index.search.slowlog.threshold.fetch.warn" : "500ms",
       "index.search.slowlog.threshold.query.debug" : "100ms",
       "index.search.slowlog.threshold.query.info" : "200ms",
       "index.search.slowlog.threshold.query.warn" : "1s"
   }
   }

11、TCP 设置多个端口的用途

transport.tcp.port 这个参数不写，默认为 9300-9399，开放那么多 端口有用么？

• 如果设置一个端口，假设这个端口占用了程序就无法正常启动；
• 如果设置多个端口，一个端口占用会寻找下一个端口，直至找到可用端口。

12、ES 临时重启，设置分片延迟分配策略

PUT _all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

三、Kibana

1、kibana 图表自定义标注

可以用 TSVB，支持标注。

Kibana TSVB 注解的使用：https://elasticsearch.cn/article/701

2、Kibana discover 导出 csv 文件

请参考文章：如何快速把 Kibana Discover 页的 Document Table 导出成 CSV

3、修改 kibana 的默认主页

https://elasticsearch.cn/article/6335

四、社区文章精选

• Elasticsearch 6.6 Index Lifecycle Management 尝鲜
• Hive 与 ElasticSearch 的数据交互

Any Code，Code Any！

扫码关注『AnyCode』，编程路上，一起前行。

1月29日，Elastic Stack 迎来 6.6 版本的发布，该版本带来很多新功能，比如：

• Index Lifecycle Management
• Frozen Index
• Geoshape based on Bkd Tree
• SQL adds support for Date histograms
• ......

在这些众多功能中，Index Lifecycle Management(索引生命周期管理，后文简称 ILM) 是最受社区欢迎的。今天我们从以下几方面来快速了解下该功能：

1. 为什么索引会有生命？什么是索引生命周期？
2. ILM 是如何划分索引生命周期的？
3. ILM 是如何管理索引生命周期的？
4. 实战

1. Index Lifecycle 索引生命周期

先来看第一个问题：

为什么索引有生命？

索引(Index)是 Elasticsearch 中数据组织的一个逻辑概念，是具有相同或相似字段的文档组合。它由众多分片(Shard)组成，比如 book、people都可以用作索引名称，可以简单类比为关系型数据库的表(table)。

所谓生命，即生与死；索引的生与死便是创建与删除了。

在我们日常使用 Elasticsearch 的时候，索引的创建与删除似乎是很简单的事情，用的时候便创建，不用了删除即可，有什么好管理的呢？

这就要从 Elasticsearch 的应用场景来看了。

在业务搜索场景，用户会将业务数据存储在 Elasticsearch 中，比如商品数据、订单数据、用户数据等，实现快速的全文检索功能。像这类数据基本都是累加的，不会删除。一般删除的话，要么是业务升级，要么是业务歇菜了。此种场景下，基本只有生，没有死，也就不存在管理一说。

而在日志业务场景中，用户会将各种日志，如系统、防火墙、中间件、数据库、web 服务器、应用日志等全部实时地存入 Elasticsearch 中，进行即席日志查询与分析。这种类型的数据都会有时间维度，也就是时序性的数据。由于日志的数据量过大，用户一般不会存储全量的数据，一般会在 Elasticsearch 中存储热数据，比如最近7天、30天的数据等，而在7天或者30天之前的数据都会被删除。为了便于操作，用户一般会按照日期来建立索引，比如 nginx 的日志索引名可能为 nginx_log-2018.11.12、nginx_log-2018.11.13等，当要查询或删除某一天的日志时，只需要针对对应日期的索引做操作就可以了。那么在该场景下，每天都会上演大量索引的生与死。

一个索引由生到死的过程，即为一个生命周期。举例如下：

• 生：在 2019年2月5日 创建 nginx_log-2019.02.05的索引，开始处理日志数据的读写请求
• 生：在 2019年2月6日 nginx_log-2019.02.05 索引便不再处理写请求，只处理读请求
• 死：在 2019年3月5日 删除 nginx_log-2018.02.05的索引

其他的索引，如 nginx_log-2019.02.06 等也会经过相同的一个生命周期。

2. ILM 是如何划分索引生命周期的？

我们现在已经了解何为生命周期了，而最简单的生命周期只需要生与死两个阶段即可。但在实际使用中生命周期是有多个阶段的，我们来看下 ILM 是如何划分生命周期的。

ILM 一共将索引生命周期分为四个阶段(Phase)：

1. Hot 阶段
2. Warm 阶段
3. Cold 阶段
4. Delete 阶段

如果我们拿一个人的生命周期来做类比的话，大概如下图所示：

Hot 阶段

Hot 阶段可类比为人类婴儿到青年的阶段，在这个阶段，它会不断地进行知识的输入与输出(数据读写)，不断地长高长大(数据量增加)成有用的青年。

由于该阶段需要进行大量的数据读写，因此需要高配置的节点，一般建议将节点内存与磁盘比控制在 32 左右，比如 64GB 内存搭配 2TB 的 SSD 硬盘。

Warm 阶段

Warm 阶段可类比为人类青年到中年的阶段，在这个阶段，它基本不会再进行知识的输入(数据写入)，主要进行知识输出(数据读取)，为社会贡献价值。

由于该阶段主要负责数据的读取，中等配置的节点即可满足需求，可以将节点内存与磁盘比提高到 64~96 之间，比如 64GB 内存搭配 4~6TB 的 HDD 磁盘。

Cold 阶段

Cold 阶段可类别比为人类中年到老年的阶段，在这个阶段，它退休了，在社会有需要的时候才出来输出下知识(数据读取)，大部分情况都是静静地待着。

由于该阶段只负责少量的数据读取工作，低等配置的节点即可满足要求，可以将节点内存与磁盘比进一步提高到 96 以上，比如128，即 64GB 内存搭配 8 TB 的 HDD 磁盘。

Delete 阶段

Delete 阶段可类比为人类寿终正寝的阶段，在发光发热之后，静静地逝去，Rest in Peace~

ILM 对于索引的生命周期进行了非常详细的划分，但它并不强制要求必须有这个4个阶段，用户可以根据自己的需求组合成自己的生命周期。

3. ILM 是如何管理索引生命周期的？

所谓生命周期的管理就是控制 4 个生命阶段转换，何时由 Hot 转为 Warm，何时由 Warm 转为 Cold，何时 Delete 等。

阶段的转换必然是需要时机的，而对于时序数据来说，时间必然是最好的维度，而 ILM 也是以时间为转换的衡量单位。比如下面这张转换的示意图，即默认是 Hot 阶段，在索引创建 3 天后转为 Warm 阶段，7 天后转为 Cold 阶段，30 天后删除。这个设置的相关字段为 min_age，后文会详细讲解。

ILM 将不同的生命周期管理策略称为 Policy，而所谓的 Policy 是由不同阶段(Phase)的不同动作(Action)组成的。

Action是一系列操作索引的动作，比如 Rollover、Shrink、Force Merge等，不同阶段可用的 Action 不同，详情如下：

• Hot Phase
  • Rollover 滚动索引操作，可用在索引大小或者文档数达到某设定值时，创建新的索引用于数据读写，从而控制单个索引的大小。这里要注意的一点是，如果启用了 Rollover，那么所有阶段的时间不再以索引创建时间为准，而是以该索引 Rollover 的时间为准。
• Warm Phase
  • Allocate 设定副本数、修改分片分配规则(如将分片迁移到中等配置的节点上)等
  • Read-Onlly 设定当前索引为只读状态
  • Force Merge 合并 segment 操作
  • Shrink 缩小 shard 分片数
• Cold Phase
  • Allocate 同上
• Delete Phase
  • Delete 删除

从上面看下来整体操作还是很简单的，Kibana 也提供了一套 UI 界面来设置这些策略，如下所示：

从上图看下来 ILM 的设置是不是一目了然呢？

当然，ILM 是有自己的 api 的，比如上面图片对应的 api 请求如下：

PUT /_ilm/policy/test_ilm2
{
    "policy": {
        "phases": {
            "hot": {
                "actions": {
                    "rollover": {
                        "max_age": "30d",
                        "max_size": "50gb"
                    }
                }
            },
            "warm": {
                "min_age": "3d",
                "actions": {
                    "allocate": {
                        "require": {
                            "box_type": "warm"
                        },
                        "number_of_replicas": 0
                    },
                    "forcemerge": {
                        "max_num_segments": 1
                    },
                    "shrink": {
                        "number_of_shards": 1
                    }
                }
            },
            "cold": {
                "min_age": "7d",
                "actions": {
                    "allocate": {
                        "require": {
                            "box_type": "cold"
                        }
                    }
                }
            },
            "delete": {
                "min_age": "30d",
                "actions": {
                    "delete": {}
                }
            }
        }
    }
}

这里不展开讲了，感兴趣的同学可以自行查看官方手册。

现在管理策略(Policy)已经有了，那么如何应用到索引(Index)上面呢？

方法为设定如下的索引配置：

• index.lifecycle.name 设定 Policy 名称，比如上面的 test_ilm2
• index.lifecycle.rollover_alias 如果使用了 Rollover，那么还需要指定该别名

修改索引配置可以直接修改(`PUT index_name/_settings)或者通过索引模板(Index Template)来实现。

我们这里不展开讲了，大家参考下面的实战就明白了。

4. 实战

下面我们来实际演练一把！

目标

现在需要收集 nginx 日志，只需保留最近30天的日志，但要保证最近7天的日志有良好的查询性能，搜索响应时间在 100ms 以内。

为了让大家可以快速看到效果，下面实际操作的时候会将 30天、7天 替换为 40秒、20秒。

ES 集群架构

这里我们简单介绍下这次实战所用 ES 集群的构成。该 ES 集群一共有 3个节点组成，每个节点都有名为 box_type 的属性，如下所示：

GET _cat/nodeattrs?s=attr
es01_hot  172.24.0.5 172.24.0.5 box_type          hot
es02_warm 172.24.0.4 172.24.0.4 box_type          warm
es03_cold 172.24.0.3 172.24.0.3 box_type          cold

由上可见我们有 1 个 hot 节点、1 个 warm 节点、1 个 cold 节点，分别用于对应 ILM 的阶段，即 Hot 阶段的索引都位于 hot 上，Warm 阶段的索引都位于 warm 上，Cold 阶段的索引都位于 cold 上。

创建 ILM Policy

根据要求，我们的 Policy 设定如下：

• 索引名以 nginx_logs 为前缀，且以每10个文档做一次 Rollover
• Rollover 后 5 秒转为 Warm 阶段
• Rollover 后 20 秒转为 Cold 阶段
• Rollover 后 40 秒删除

API 请求如下：

PUT /_ilm/policy/nginx_ilm_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_docs": "10"
          }
        }
      },
      "warm": {
        "min_age": "5s",
        "actions": {
          "allocate": {
            "include": {
              "box_type": "warm"
            }
          }
        }
      },
      "cold": {
        "min_age": "20s",
        "actions": {
          "allocate": {
            "include": {
              "box_type": "cold"
            }
          }
        }
      },
      "delete": {
        "min_age": "40s",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

创建 Index Template

我们基于索引模板来创建所需的索引，如下所示：

PUT /_template/nginx_ilm_template
{
  "index_patterns": ["nginx_logs-*"],                 
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0,
    "index.lifecycle.name": "nginx_ilm_policy",      
    "index.lifecycle.rollover_alias": "nginx_logs",
    "index.routing.allocation.include.box_type": "hot"
  }
}

上述配置解释如下：

• index.lifecycle.name 指明该索引应用的 ILM Policy
• index.lifecycle.rollover_alias 指明在 Rollover 的时候使用的 alias
• index.routing.allocation.include.box_type 指明新建的索引都分配在 hot 节点上

创建初始索引 Index

ILM 的第一个索引需要我们手动来创建，另外启动 Rollover 必须以数值类型结尾，比如 nginx_logs-000001。索引创建的 api 如下：

PUT nginx_logs-000001
{
  "aliases": {
    "nginx_logs": {
      "is_write_index":true
    }
  }
}

此时索引分布如下所示：

修改 ILM Polling Interval

ILM Service 会在后台轮询执行 Policy，默认间隔时间为 10 分钟，为了更快地看到效果，我们将其修改为 1 秒。

PUT _cluster/settings
{
  "persistent": {
    "indices.lifecycle.poll_interval":"1s"
  }
}

开始吧

一切准备就绪，我们开始吧！

首先执行下面的新建文档操作 10 次。

POST nginx_logs/_doc
{
  "name":"abbc"
}

之后 Rollover 执行，新的索引创建，如下所示:

5 秒后，nginx_logs-000001 转到 Warm 阶段

15 秒后(20 秒是指距离 Rollover 的时间，因为上面已经过去5秒了，所以这里只需要15秒)，nginx_logs-00001转到 Cold 阶段

25 秒后，nginx_logs-00001删除

至此，一个完整的 ILM Policy 执行的流程就结束了，而后续 nginx_logs-000002 也会按照这个设定进行流转。

总结

ILM 是 Elastic 团队将多年 Elasticsearch 在日志场景领域的最佳实践进行的一次总结归纳和落地实施，极大地降低了用好 Elasticsearch 的门槛。掌握了 ILM 的核心概念，也就意味着掌握了 Elasticsearch 的最佳实践。希望本文能对大家入门 ILM 有所帮助。

在线研讨会

一篇文章所能承载的信息量和演示效果终究是有限的，2月份我们会针对 ILM 做一次线上研讨会，感兴趣的同学可以点击下面的链接注册报名。

https://jinshuju.net/f/TjBbvx

为了提高研讨会的质量，我们本次引入了审核机制，报名的同学请耐心等待，待我们审核通过后，您会收到我们的邮件邀请。

参考资料：

1. https://www.elastic.co/guide/en/elasticsearch/reference/6.6/index-lifecycle-management.html
2. https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

 Caused by: org.elasticsearch.discovery.MasterNotDiscoveredException: ClusterBlockException[blocked by: [SERVICE_UNAVAILABLE/1/state not recovered / initialized];]
                at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction$4.onTimeout(TransportMasterNodeAction.java:213) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.cluster.ClusterStateObserver$ContextPreservingListener.onTimeout(ClusterStateObserver.java:317) [elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:244) [elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.cluster.service.ClusterApplierService$NotifyTimeout.run(ClusterApplierService.java:578) [elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:568) [elasticsearch-6.1.3.jar:6.1.3]
                at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_181]
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_181]
                at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
        Caused by: org.elasticsearch.cluster.block.ClusterBlockException: blocked by: [SERVICE_UNAVAILABLE/1/state not recovered / initialized];
                at org.elasticsearch.cluster.block.ClusterBlocks.indexBlockedException(ClusterBlocks.java:182) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.action.admin.indices.create.TransportCreateIndexAction.checkBlock(TransportCreateIndexAction.java:64) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.action.admin.indices.create.TransportCreateIndexAction.checkBlock(TransportCreateIndexAction.java:39) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction.doStart(TransportMasterNodeAction.java:135) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.action.support.master.TransportMasterNodeAction$AsyncSingleAction.start(TransportMasterNodeAction.java:127) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.action.support.master.TransportMasterNodeAction.doExecute(TransportMasterNodeAction.java:105) ~[elasticsearch-6.1.3.jar:6.1.3]
                at org.elasticsearch.action.support.master.TransportMasterNodeAction.doExecute(TransportMasterNodeAction.java:55) ~[elasticsearch-6.1.3.jar:6.1.3]

1. 使用ELK实时展示python日志(自备梯子） http://t.cn/EtnXpxL

2.使用logstash的grok自定义数据格式(自备梯子） http://t.cn/Etna8mi

3. docker部署ELK监控日志 http://t.cn/EtnTn3O

• 编辑：bsll

• 归档：https://elasticsearch.cn/article/6355

• 订阅：https://tinyletter.com/elastic-daily