ELK日志分析、索引、切片、生命周期等

1.elk的背景介绍与应用场景
在项目应用运行的过程中，往往会产生大量的日志，我们往往需要根据日志来定位分析我们的服务器项目运行情况与BUG产生位置。一般情况下直接在日志文件中tailf、 grep、awk 就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量过大、文本搜索太慢、如何多维度查询。这就需要对服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。

一般大型系统往往是一种分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，所以构建一套集中式日志系统，可以提高定位问题的效率。一个完整的集中式日志系统，需要包含以下几个主要特点：
收集－能够采集多种来源的日志数据，服务日志与系统日志。
传输－能够稳定的把日志数据传输到中央系统
存储－如何存储日志数据，持久化数据。
分析－可以支持 UI 分析，界面化定制查看日志操作。

ELK提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。是目前主流的一种日志系统。
2.ELK简介
ELK是三个开源软件的缩写，分别表示：Elasticsearch（搜索）、Logstash（收集与分析）、Kibana（展示）,他们都是开源软件。后来新增了一个FileBeat

区别
Filebeat：轻量级数据收集引擎。早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、CPU、io等资源消耗比较高。如果用它来对服务器进行日志收集，将加重服务器的负载。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计，所以filebeat作为一个轻量级的日志收集处理工具(Agent)，它可以用来替代Logstash，由于其占用资源少，所以更适合于在各个服务器上搜集日志后传输给Logstash，这也是官方推荐的一种做法。【收集日志】

Logstash：数据收集处理引擎。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储以供后续使用。【对日志进行过滤、分析】
Logstash的三种模块
input ： 此模块是负责收集日志、可以从文件读取、从Redis读取或者开启端口让产生日志的业务体系直接写入到logstash
output : 此模块是负责将过滤后的日志输出到elasticsearch或者文件、redis等
filter ： 此模块是负责过滤到日志、并根据过滤后对日志定义显示字段

Elasticsearch：分布式搜索引擎。是基于Lucene的开源分布式搜索服务器，具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。【搜集、分析、存储数据】

Kibana：可视化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。【图形化展示日志】
el有五个切片一个副本（这是默认的）

Elasticsearch添加数据是需要用到索引-------保存相关数据的地方。索引实际上是指向一个或者多个物理分片的逻辑命名空间。

一个分片是一个底层的工作单元，它仅保存了全部数据中的一部分。一个分片是一个Lucene的实例，以及它本身就是一个完整的搜索引擎。我们的文档被存储和索引到分片内，但是应用程序是直接与索引而不是与分片进行交互的。

Elasticsea是利用分片将数据分发到集群内各处的。分片是数据的同期，文档保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时，Elasticsearch会自动的在各个节点中迁移分片，使数据仍然均匀分布在集群里。

一个分片可以是主分片或者是副本分片。索引内任意一个文档都属于一主分片，所以主分片的树木决定着索引能够保存的最大数据量。

Note 技术上来说，一个主分片最大能够存储 Integer.MAX_VALUE - 128 个文档，但是实际最大值还需要参考你的使用场景：包括你使用的硬件，文档的大小和复杂程度，索引和查询文档的方式以及你期望的响应时长。
一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。

在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。

让我们在包含一个空节点的集群内创建名为 blogs 的索引。索引在默认情况下会被分配5个主分片，但是为了演示目的，我们将分配3个主分片和一份副本（每个主分片拥有一个副本分片）：
PUT /blogs
{
“settings” : {
“number_of_shards” : 3,
“number_of_replicas” : 1
}
}
我们的集群现在是拥有一个索引的单节点集群。所有3个主分片都被分配在Node 1 。
Figure 1. 拥有一个索引的单节点集群
如果我们现在查看集群健康，我们将看到如下内容：
{
“cluster_name”: “elasticsearch”,
“status”: “yellow”, (1)
“timed_out”: false,
“number_of_nodes”: 1,
“number_of_data_nodes”: 1,
“active_primary_shards”: 3,
“active_shards”: 3,
“relocating_shards”: 0,
“initializing_shards”: 0,
“unassigned_shards”: 3, (2)
“delayed_unassigned_shards”: 0,
“number_of_pending_tasks”: 0,
“number_of_in_flight_fetch”: 0,
“task_max_waiting_in_queue_millis”: 0,
“active_shards_percent_as_number”: 50
}
集群 status 值为 yellow 。
没有被分配到任何节点的副本数。
集群的健康状况为 yellow 则表示全部 主 分片都正常运行（集群可以正常服务所有请求），但是 副本 分片没有全部处在正常状态。实际上，所有3个副本分片都是unassigned —— 它们都没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。
当前我们的集群是正常运行的，但是在硬件故障时有丢失数据的风险。

添加故障转移
当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。幸运的是，我们只需再启动一个节点即可防止数据丢失。
启动第二个节点
为了测试第二个节点启动后的情况，你可以在同一个目录内，完全依照启动第一个节点的方式来启动一个新节点（参考[running-elasticsearch]）。多个节点可以共享同一个目录。
当你在同一台机器上启动了第二个节点时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播主机列表。详细信息请查看[unicast]
如果启动了第二个节点，我们的集群将会如拥有两个节点的集群——所有主分片和副本分片都已被分配所示。

Figure 1. 拥有两个节点的集群——所有主分片和副本分片都已被分配
当第二个节点加入到集群后，3个 副本分片 将会分配到这个节点上——每个主分片对应一个副本分片。这意味着当集群内任何一个节点出现问题时，我们的数据都完好无损。
所有新近被索引的文档都将会保存在主分片上，然后被并行的复制到对应的副本分片上。这就保证了我们既可以从主分片又可以从副本分片上获得文档。
cluster-health 现在展示的状态为 green ，这表示所有6个分片（包括3个主分片和3个副本分片）都在正常运行。
{
“cluster_name”: “elasticsearch”,
“status”: “green”, (1)
“timed_out”: false,
“number_of_nodes”: 2,
“number_of_data_nodes”: 2,
“active_primary_shards”: 3,
“active_shards”: 6,
“relocating_shards”: 0,
“initializing_shards”: 0,
“unassigned_shards”: 0,
“delayed_unassigned_shards”: 0,
“number_of_pending_tasks”: 0,
“number_of_in_flight_fetch”: 0,
“task_max_waiting_in_queue_millis”: 0,
“active_shards_percent_as_number”: 100
}
集群 status 值为 green 。
我们的集群现在不仅仅是正常运行的，并且还处于 始终可用 的状态。

水平扩容
怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第三个节点，我们的集群将会看起来如拥有三个节点的集群——为了分散负载而对分片进行重新分配所示。

Figure 1. 拥有三个节点的集群——为了分散负载而对分片进行重新分配
Node 1 和 Node 2 上各有一个分片被迁移到了新的 Node 3 节点，现在每个节点上都拥有2个分片，而不是之前的3个。这表示每个节点的硬件资源（CPU, RAM, I/O）将被更少的分片所共享，每个分片的性能将会得到提升。
分片是一个功能完整的搜索引擎，它拥有使用一个节点上的所有资源的能力。我们这个拥有6个分片（3个主分片和3个副本分片）的索引可以最大扩容到6个节点，每个节点上存在一个分片，并且每个分片拥有所在节点的全部资源。

更多的扩容
但是如果我们想要扩容超过6个节点怎么办呢？
主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够 存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。）但是，读操作——搜索和返回数据——可以同时被主分片或 副本分片所处理，所以当你拥有越多的副本分片时，也将拥有越高的吞吐量。
在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把副本数从默认的 1 增加到 2 ：
PUT /blogs/_settings
{
“number_of_replicas” : 2
}
如将参数number_of_replicas 调大到 2所示， blogs 索引现在拥有9个分片：3个主分片和6个副本分片。这意味着我们可以将集群扩容到9个节点，每个节点上一个分片。相比原来3个节点时，集群搜索性能可以提升3 倍。

Figure 1. 将参数 number_of_replicas 调大到 2
Note 当然，如果只是在相同节点数目的集群上增加更多的副本分片并不能提高性能，因为每个分片从节点上获得的资源会变少。你需要增加更多的硬件资源来提升吞吐量。但是更多的副本分片数提高了数据冗余量：按照上面的节点配置，我们可以在失去2个节点的情况下不丢失任何数据。

应对故障
我们之前说过 Elasticsearch 可以应对节点故障，接下来让我们尝试下这个功能。如果我们关闭第一个节点，这时集群的状态为关闭了一个节点后的集群
Figure 1. 关闭了一个节点后的集群
我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 2 。
在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。
幸运的是，在其它节点上存在着这两个主分片的完整副本，所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片，此时集群的状态将会为 yellow 。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。
为什么我们集群状态是 yellow 而不是 green 呢？虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应2份副本分片，而此时只存在一份副本分片。所以集群不能为 green 的状态，不过我们不必过于担心：如果我们同样关闭了 Node 2 ，我们的程序 依然 可以保持在不丢任何数据的情况下运行，因为 Node 3 为每一个分片都保留着一份副本。
如果我们重新启动 Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将如[cluster-three-nodes-two-replicas]所示。如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，同时仅从主分片复制发生了修改的数据文件。
到目前为止，你应该对分片如何使得 Elasticsearch 进行水平扩容以及数据保障等知识有了一定了解。接下来我们将讲述关于分片生命周期的更多细节。

关于分片的生命周期：

Elasticsearch索引生命周期管理指：Elasticsearch从设置、创建、打开、关闭、删除的全生命周期过程的管理。
Elasticsearch生产环境中一般采用多索引结合基于时间、基于空间的横向扩展的方式存储数据，随着数据量的增多，不用修改索引的底层架构逻辑。

2、索引生命周期管理为什么重要？
索引管理决定Elasticsearch鲁棒性、高可用性。
索引管理和搜索、插入性能也密切相关。
实际场景例子：100节点的集群中某一个节点数据丢失后，GET /_cat/nodes?v 接口的返回时延时延非常大，接近5-8s。搜索、聚合的性能更不必说。
原因：节点丢失后，ES会自动复制分片到新的节点中去，但是该丢失节点的shard非常大（几百个GB甚至上TB），集群当时的写入压力也非常大。这么大量级的数据拷贝和实时写入，最终导致延时会非常大。

3、索引生命周期管理面临的挑战
1）索引管理需要ES专业知识和业务知识的结合。
业务数据多少结合业务场景，有突发情况。
2）涉及生产环境的操作。
3）用户使用有突发情况。
比如：参数设置错误，分片数和副本数弄反了，路由设置错误。
4）索引操作的时候可能会失败。
5）高可用性挑战。

4、高可用的索引管理初探
Ebay的分享提及内部团队开发了索引管理系统，会择期分享，截止20180805 github还没有开源，期待中。
索引生命周期管理的核心就是定义索引的早期阶段，前面考虑充分了，后面的架构才会高效、稳定。
实际Elasticsearch5.X之后的版本已经推出：新增了一个Rollover API。Rollover API解决的是以日期作为索引名称的索引大小不均衡的问题。
medcl介绍如下：Rollover API对于日志类的数据非常有用，一般我们按天来对索引进行分割（数据量更大还能进一步拆分），没有Rollover之前，需要在程序里设置一个自动生成索引的模板，
相比于模板，Rollover API是更为简洁的方式。

4.1 RollOver 的定义
当现有索引被认为太大或太旧时，滚动索引API将别名滚动到新索引。该API接受一个别名和一个条件列表。别名必须只指向一个索引。如果索引满足指定条件，则创建一个新索引，并将别名切换到指向新索引的位置。
6.XRollover支持的三种条件是：

1）索引存储的最长时间。如： “max_age”: “7d”,
2）索引支持的最大文档数。如：”max_docs”: 1000,
3）索引最大磁盘空间大小。”max_size”: “5gb”。
注意：
5.X版本不支持”max_size”: “5gb”磁盘大小的方式。
分片的大小并不是一个可靠的测量标准，因为正在进行中的合并会产生大量的临时分片大小增长，而当合并结束后这些增长会消失掉。五个主分片，每个都在合并到一个 5GB 分片的过程中，那么此时索引大小会临时增多 25GB！而对于文档数量来说，它的增长则是可以预测的。

4.2 RollOver的适用场景
这个特性对于存放日志数据的场景、索引非常大、索引实时导入数据的场景是极为友好的。
你也可以先在索引模板里面设置索引的setting、mapping等参数, 然后设定好_rollover 规则，剩下的es会自动帮你处理。

4.3 6.XRollOverAPI调用方式如下：
方式一：基于序号的索引管理。
步骤1：创建索引（注意序号）

PUT /logs-000001
{
“aliases”: {
“logs_write”: {}
}
}

步骤2：指定RollOver规则。

POST /logs_write/_rollover
{
“conditions”: {
“max_age”: “7d”,
“max_docs”: 2,
“max_size”: “5gb”
}
}

步骤3：批量插入数据。

POST logs_write/log/_bulk
{ “create”: {"_id":1}}
{ “text”: “111”}
{ “create”: {"_id":2}}
{ “text”: “222” }
{ “create”: {"_id":3}}
{ “text”: “333”}
{ “create”: {"_id":4}}
{ “text”: “4444”}

注意啦，理论上：_id=3和_id=4的数据会滚动到logs-000002的索引，实际并没有。
这个问题困扰我一上午。
实践验证发现，然并卵。

步骤4：重复步骤2。
查看返回结果如下：

{
“old_index”: “logs-000001”,
“new_index”: “logs-000002”,
“rolled_over”: true,
“dry_run”: false,
“acknowledged”: true,
“shards_acknowledged”: true,
“conditions”: {
“[max_docs: 2]”: true,
“[max_age: 7d]”: false,
“[max_size: 5gb]”: false
}
}

这样以后，后续插入的数据索引就自动变为logs-000002，logs-000003……logs-00000N。

注意：
1）执行数据插入前要先执行_rollover API。
2）_rollover API不是一劳永逸的，需要手动执行后才能生效。

方式二：基于时间的索引管理。
步骤1：创建基于日期的索引。

#PUT /<logs-{now/d}-1> with URI encoding:
PUT /%3Clogs-%7Bnow%2Fd%7D-1%3E
{
“aliases”: {
“logs_write”: {}
}
}

URI 编码工具：http://tool.oschina.net/encode?type=4
输入：<logs-{now/d}-1>
输出：%3Clogs-%7Bnow%2Fd%7D-1%3E
步骤2：插入一条数据。

PUT logs_write/_doc/1
{
“message”: “a dummy log”
}

步骤3：指定RollOver规则。

POST /logs_write/_rollover
{
“conditions”: {
“max_docs”: “1”
}
}

返回结果：

{
“old_index”: “logs-2018.08.05-1”,
“new_index”: “logs-2018.08.05-000002”,
“rolled_over”: true,
“dry_run”: false,
“acknowledged”: true,
“shards_acknowledged”: true,
“conditions”: {
“[max_docs: 1]”: true
}
}

注意，可能感觉到日期没有变更困惑的问题解释如下：
1）如果立即执行，new_index的名字就是当前的日期：logs-2018.08.05-000002。
2）如果24小时候后执行，new_index的名字就是+1天后的日期：logs-2018.08.06-000002。

5、高可用的索引管理进阶
ES官网博客做了更好的诠释：https://www.elastic.co/blog/managing-time-based-indices-efficiently。
翻译版本：https://juejin.im/post/5a990cdbf265da239b40de65。
在基础RollOver滚动索引的基础上，引入冷、热数据分离。这是实际业务非常需要一种场景。
冷热分离结合滚动模式工作流程如下：

步骤1：有一个用于写入的索引别名，其指向活跃索引（热数据）；
步骤2：另外一个用于读取（搜索）的索引别名，指向不活跃索引（冷数据）；
步骤3：活跃索引具有和热节点数量一样多的分片，可以充分发挥昂贵硬件的索引写入能力；
步骤4：当活跃索引太满或者太老的时候，它就会滚动：新建一个索引并且索引别名自动从老索引切换到新索引；
步骤5：移动老索引到冷节点上并且缩小为一个分片，之后可以强制合并和压缩。

具体实现，官方博客已经做了具体的说明。
注意：

“routing.allocation.include.box_type”: “hot”,
“routing.allocation.total_shards_per_node”: 2

单节点执行上述操作会导致失败，具体原因待进一步验证。

6、Rollover的不足和改进
Rollover API大大简化了基于时间的索引的管理。但是，仍然需要以一种重复的方式调用_rollover API接口，可以手动调用，也可以通过基于crontab的工具(如director)调用。
但是，如果翻转过程是隐式的并在内部进行管理，则会简单得多。其思想是在创建索引时(或在索引模板中相等地)在别名中指定滚动条件。

PUT /<logs-{now/d}-1>
{
“mappings”: {…},
“aliases” : {
“logs-search” : {},
“logs-write” : {
“rollover” : {
“conditions”: {
“max_age”: “1d”,
“max_docs”: 100000
}
}
}
}
}

github提出的改进建议如下：
https://github.com/elastic/elasticsearch/issues/26092

7、小结
Elasticsearch索引生命周期管理是件大事，无论你是开发还是运维人员，千万不要轻视。
Rollover的出现能相对缓解分片、索引、集群的压力，相对高效的管理索引的生命周期。
结合curator的定时删除机制会更高效。
参考：
https://elasticsearch.cn/slides/120