脚本：
我们使用elasticsearch和logstash为一个中等流量的系统做应用程序日志记录
该系统每天生成约200gb的日志
我们使用4个示例切分；想保留大约3天的原木
因此，我们实现了一个“清理”系统，每天运行，它删除所有超过3天的数据
到现在为止，一直都还不错。然而，几天前，一些子系统生成了一个持久的数据日志峰值，导致在几个小时内填满了所有可用的磁盘空间，从而使集群变红。这也意味着，清理系统无法连接到es，因为整个集群由于磁盘已满而停机。这是一个非常棘手的问题，因为它限制了我们对正在发生的事情的可见性，并且阻碍了我们从一开始就看到是什么导致了这种情况。
在这里做根本原因分析，会弹出几个问题：
当集群状态为红色时，我们如何查看例如kibana中的系统？
如果没有更多的空间，我们如何告诉es丢弃（最旧的优先）日志，而不是将status=red？
我们怎样才能确保这种情况不再发生？
2条答案
按热度按时间np8igboo1#
基于日期的索引模式很难处理尖峰负载。有两种方法可以结合使用，以实现无需手动干预的平滑设置：
切换到滚动索引。然后可以定义，一旦现有索引达到xgb，就要创建一个新索引。这样，您就不必再关心每天的日志量了，只需保留尽可能多的索引（并保留一些缓冲区/微调水印）。
为了自动化滚动、删除索引和可选地设置别名，我们有elastic curator：
滚动更新示例
例如delete index，但您希望将其与count filtertype结合使用
ps：很快就会有另一个解决方案，叫做索引生命周期管理。它直接内置在elasticsearch中，可以通过kibana进行配置，但目前还只是指日可待。
vlf7wbxs2#
当集群状态为红色时，我们如何查看例如kibana中的系统？
如果已经坏了，kibana就无法连接到es。最好轮询群集运行状况api以获取群集的当前状态。
如果没有更多的空间，我们如何告诉es丢弃（最旧的优先）日志，而不是将status=red？
此选项未内置在elasticsearch中。最好的方法是使用watcher或其他工具监视磁盘空间，并让您的监视发送警报+触发一个作业，如果磁盘使用率低于指定的阈值，则清除旧日志。
我们怎样才能确保这种情况不再发生？
监视群集节点的磁盘空间。