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

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

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

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

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

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

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

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

Это ограничение с тех пор было устранено. Начиная с версии 6.4.0, лучшей практикой является объединение всех конфигураций сводки в одну задачу.

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

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

и

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

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

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" ]
    }
  ]
}

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

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