当“时间单位” =“天数”时，ELK Curator如何管理每月/每周索引

Question

在我们公司的标准Elasticsearch和策展人实施之上，我们有一个自定义包装器。我想知道当默认的“时间单位”设置为“天”时，策展人处理“每月/每周”索引的行为是什么。

**我无法覆盖默认的“时间单位”

这是我们每月/每周索引命名方式的示例格式

月度索引格式

logstash-test-monthly-2018.01
logstash-test-monthly-2018.02
logstash-test-monthly-2018.03
logstash-test-monthly-2018.04
...
...
logstash-test-monthly-2018.12

每周索引格式

logstash-test-weekly-2018.01
logstash-test-weekly-2018.02
...
...
...
logstash-test-weekly-2018.51
logstash-test-weekly-2018.52

Delete_Index.yml-馆长删除说明

actions:
  1:
    action: delete_indices
    options:
      ignore_empty_list: true
    filters:
      - exclude: true
        filtertype: kibana
      - exclude: false
        kind: regex
        filtertype: pattern
        value: .*-monthly-.*
      - range_to: 0
        filtertype: period
        source: name
        range_from: -60
        period_type: relative
        timestring: '%Y.%m.%d'
        exclude: true
        unit: days
    description: Delete indices more than X days old
  2:
    action: delete_indices
    options:
      ignore_empty_list: true
    filters:
      - exclude: true
        filtertype: kibana
      - exclude: false
        kind: regex
        filtertype: pattern
        value: .*-weekly-.*
      - range_to: 0
        filtertype: period
        source: name
        range_from: -30
        period_type: relative
        timestring: '%Y.%m.%d'
        exclude: true
        unit: days

实施上述配置，每月索引保留为60天，每周索引保留为30天。

该配置于** 2018年4月4日执行，结果为**

执行后保留每月索引

logstash-test-monthly-2018.03
logstash-test-monthly-2018.04

由于上述索引^^仅包含31 + 4 = 35天的索引数据，而不是60天的预期值。

我期望馆长会保留以下指标

logstash-test-monthly-2018.02
logstash-test-monthly-2018.03
logstash-test-monthly-2018.04

谁能解释为什么策展人无法保留价值60天的索引？

Answer 1

TL; DR：2月中的天数较短，并且age计算是秒的倍数*适当的units数。

所有这些都在Elastic网站上的age过滤器文档中进行了说明。

年龄过滤器与期间过滤器

时差计算手段会导致挫败感。

设置单位months，并unit_count以3将实际计算的年龄3*30*24*60*60，这是7776000秒。这可能是一件大事。如果日期为2017-01-01T02：30：00Z或1483237800以纪元时间计，则减去7776000秒数1475461800即为2016-10-03T02：30：00Z。如果你要尝试匹配monthly指数 index-2016.12，index-2016.11，2016.10，2016.09，等等，那么这两个 index-2016.09和index-2016.10将older超过截止日期。这可能会导致意外的行为。

可能导致问题的另一种方法是使用weeks。每周索引可能从星期日或星期一开始。该age过滤器的计算没有考虑到这一点，并且仅测试执行时间和在索引中的时间戳（从任何来源）之间的差。

选择索引和快照的另一种方法是period过滤器，它可能是选择星期和月份的更好选择，因为它可以弥补这些差异。

一旦您了解到age计算只不过是乘以unit_count* unit的适当秒数，就可以理解为什么保留是这样进行的。如前所述，您可以对period过滤器进行更好的处理，因为它可以处理整天，几周，几个月和几年。