2

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

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

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

月度指数格式

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 天。

我期待 curator 会保留以下索引

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

谁能解释为什么馆长无法保留 60 天的索引？

4

2 回答 2

5

TL;DR : 二月的天数较短，age计算是秒的倍数 * 适当的units 数。

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

年龄过滤器与周期过滤器

时差计算方法可能会导致挫败感。

将单位设置为months, 和unit_countto3将实际计算年龄为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过滤器做得更好，因为它适用于完整的天、周、月和年。

于 2018-04-07T14:23:08.207 回答
0 
actions:
  1:
    action: delete_indices
    description: >-
      Delete indices older than 2 months (based on index name), for custom-
      prefixed indices. Ignore the error if the filter does not result in an
      actionable list of indices (ignore_empty_list) and exit cleanly.
    options:
      ignore_empty_list: True
      continue_if_exception: False
      disable_action: False
    filters:
      - filtertype: pattern
        kind: regex
        value: ^(index-pattern).*$
      - filtertype: age
        source: name
        direction: older
        timestring: "%Y.%m"
        unit: months
        unit_count: 2

这是仅用于删除每月索引的 yml 配置。

于 2022-01-25T15:07:28.463 回答