Понимание групп

Каждая задача Rollup должна иметь группу с гистограммой дат с определенным интервалом. Elasticsearch понимает как календарные, так и фиксированные интервалы времени. Фиксированные интервалы довольно легко понять; 60s означает шестьдесят секунд. А что означает 1M? Один месяц времени зависит от того, о каком месяце идет речь; некоторые месяцы длиннее или короче других. Это пример календарного времени, и продолжительность этого блока зависит от контекста. Календарные единицы также зависят от високосных секунд, високосных лет и т.д.

Это важно, потому что создаваемые задачами Rollup корзины используют либо календарные, либо фиксированные интервалы, что ограничивает то, как вы можете их запросить позже. См. Запросы должны быть кратными конфигурации.

Мы рекомендуем использовать фиксированные интервалы, так как они легче поддаются пониманию и более гибкие при запросах. Это внесет некоторое смещение в ваши данные во время високосных событий, и вам придется думать о месяцах как о фиксированной величине (30 дней), а не об их фактической календарной продолжительности. Однако это часто проще, чем иметь дело с календарными единицами при запросах.

Кратные единицы всегда «фиксированные». Например, 2h всегда является фиксированной величиной 7200 секунд. Единичные единицы могут быть фиксированными или календарными, в зависимости от единицы:

Для некоторых единиц, где есть как фиксированные, так и календарные значения, вам может потребоваться выразить количество в терминах следующей более мелкой единицы. Например, если вы хотите фиксированный день (не календарный день), вы должны указать 24h вместо 1d. Аналогично, если вы хотите фиксированные часы, укажите 60m вместо 1h. Это связано с тем, что единичное количество подразумевает календарное время и ограничивает вас запросами по календарному времени в будущем.

Ранее существовало ограничение в том, как Rollup мог обрабатывать индексы с гетерогенными отображениями (множественные, несвязанные/непересекающиеся отображения). Тогда рекомендовалось настраивать отдельную задачу для каждого типа данных. Например, вы можете настроить отдельную задачу для каждого модуля Beats, который вы включили (одна для process, другая для filesystem и т.д.).

Это рекомендация была обусловлена внутренними особенностями реализации, которые могли привести к потенциально некорректным подсчетам количества документов, если использовалась одна «объединённая» задача.

Это ограничение с тех пор устранено. С версии 6.4.0 рекомендуется объединять все конфигурации Rollup в одну задачу.

Например, если ваш индекс содержит два типа документов:

{
  "timestamp": 1516729294000,
  "temperature": 200,
  "voltage": 5.2,
  "node": "a"
}

и

{
  "timestamp": 1516729294000,
  "price": 123,
  "title": "Foo"
}

лучшей практикой является объединение их в одну задачу Rollup, охватывающую оба типа документов, как показано ниже:

PUT _rollup/job/combined
{
  "index_pattern": "data-*",
  "rollup_index": "data_rollup",
  "cron": "*/30 * * * * ?",
  "page_size": 1000,
  "groups": {
    "date_histogram": {
      "field": "timestamp",
      "fixed_interval": "1h",
      "delay": "7d"
    },
    "terms": {
      "fields": [ "node", "title" ]
    }
  },
  "metrics": [
    {
      "field": "temperature",
      "metrics": [ "min", "max", "sum" ]
    },
    {
      "field": "price",
      "metrics": [ "avg" ]
    }
  ]
}

Ранее существовала проблема с подсчетом документов в конфигурациях «перекрывающихся» задач, вызванная той же внутренней особенностью реализации. Если две задачи Rollup сохраняли данные в один и тот же индекс, где одна задача была «подмножеством» другой задачи, было возможно, что количество документов могло быть неверным для некоторых схем агрегаций.

Эта проблема также была устранена в версии 6.4.0.