监控日志loging kibana (索引周期管理一）

如果你要处理时间序列数据，则不想将所有内容连续转储到单个索引中。 取而代之的是，您可以定期将数据滚动到新索引，以防止数据过大而又缓慢又昂贵。 随着索引的老化和查询频率的降低，您可能会将其转移到价格较低的硬件上，并减少分片和副本的数量。

要在索引的生命周期内自动移动索引，可以创建策略来定义随着索引的老化对索引执行的操作。 索引生命周期策略在与 Beats 数据发件人一起使用时特别有用，Beats 数据发件人不断将运营数据（例如指标和日志）发送到 Elasticsearch。 当现有索引达到指定的大小或期限时，你可以自动滚动到新索引。 这样可以确保所有索引具有相似的大小，而不是每日索引，其大小可以根 beats 数和发送的事件数而有所不同。

让我们通过动手操作场景跳入索引生命周期管理（Index cycle management: ILM）。 本文章将利用您可能不熟悉的ILM独有的许多新概念。 我们先用一个示例来展示。本示例的目标是建立一组索引，这些索引将封装来自时间序列数据源的数据。 我们可以想象有一个像Filebeat这样的系统，可以将文档连续索引到我们的书写索引中。 我们希望在索引达到50 GB，或文档的数量超过10000，或已在30天前创建索引后对其进行 rollover，然后在90天后删除该索引。

上图显示一个 Log 文档在 Elasticsearch 中生命周期。

针对一个超大规模的集群：

运行两个 node 的 Elasticsearch 集群

我们可以参考文章 “Elasticsearch：运用shard filtering来控制索引分配给哪个节点” 运行起来两个 node 的 cluster。其实非常简单，当我们安装好 Elasticsearch 后，打开一个 terminal，并运行如下的命令：

./bin/elasticsearch -E node.nam