Начало работы со сворачиванием

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

Представьте, что у вас есть ряд ежедневных индексов, которые содержат данные датчиков (sensor-2017-01-01, sensor-2017-01-02 и т.д.). Пример документа может выглядеть так:

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

Мы хотели бы свернуть эти документы в почасовые сводки, что позволит нам генерировать отчеты и панели мониторинга с любым интервалом времени в один час или больше. Задача свертывания может выглядеть так:

PUT _rollup/job/sensor
{
  "index_pattern": "sensor-*",
  "rollup_index": "sensor_rollup",
  "cron": "*/30 * * * * ?",
  "page_size": 1000,
  "groups": {
    "date_histogram": {
      "field": "timestamp",
      "fixed_interval": "60m"
    },
    "terms": {
      "fields": [ "node" ]
    }
  },
  "metrics": [
    {
      "field": "temperature",
      "metrics": [ "min", "max", "sum" ]
    },
    {
      "field": "voltage",
      "metrics": [ "avg" ]
    }
  ]
}

Мы даём задаче идентификатор «sensor» (в URL: PUT _rollup/job/sensor) и говорим ей свернуть шаблон индекса "sensor-*". Эта задача найдет и свернет любой индекс, соответствующий этому шаблону. Сводки свертывания затем сохраняются в индексе "sensor_rollup".

Параметр cron контролирует, когда и как часто активируется задача. Когда плановое задание задачи свертывания срабатывает, оно начинает свертывать данные с места, где оно остановилось после последней активации. Так что, если вы настроите задание на выполнение каждые 30 секунд, задача будет обрабатывать последние 30 секунд данных, которые были проиндексированы в индексах sensor-*.

Если вместо этого задание было настроено на выполнение один раз в сутки в полночь, задача обработает данные за последние 24 часа. Выбор во многом зависит от того, насколько «реальным временем» вы хотите свертывания и хотите ли вы непрерывно обрабатывать данные или переместить их на непиковые часы.

Далее мы определяем набор groups. По сути, мы определяем измерения, на которых мы хотим сортировать данные в будущем при запросе данных. Группировка в этой задаче позволяет нам использовать date_histogram агрегации по полю timestamp, свёрнутые с почасовыми интервалами. Она также позволяет выполнять агрегации по типу node по полю node.

После определения групп, которые должны быть сгенерированы для данных, вы затем настраиваете метрики, которые должны быть собраны. По умолчанию собираются только doc_counts для каждой группы. Чтобы свертывание было полезным, вы часто добавляете метрики, такие как средние значения, минимальные и максимальные значения и т. д. В этом примере метрики довольно просты: мы хотим сохранить минимальное/максимальное/суммарное значение поля temperature и среднее значение поля voltage.

Дополнительную информацию о синтаксисе задания см. в разделе Создание задач свертывания.

После выполнения вышеуказанной команды и создания задачи вы получите следующий ответ:

{
  "acknowledged": true
}

После создания задача находится в неактивном состоянии. Задачи необходимо запускать, прежде чем они начнут обрабатывать данные (это позволяет остановить их позже, чтобы временно приостановить работу, не удаляя конфигурацию).

Чтобы запустить задачу, выполните эту команду:

POST _rollup/job/sensor/_start

После того, как задача выполнилась и обработала некоторые данные, мы можем использовать конечную точку Поиск свертывания, чтобы выполнить поиск. Функция свертывания разработана таким образом, что вы можете использовать тот же синтаксис запросов Query DSL, к которому вы привыкли… только он работает с свёрнутыми данными вместо исходных.

Например, рассмотрим этот запрос:

GET /sensor_rollup/_rollup_search
{
  "size": 0,
  "aggregations": {
    "max_temperature": {
      "max": {
        "field": "temperature"
      }
    }
  }
}

Это простая агрегация, которая вычисляет максимальное значение поля temperature. Но вы заметите, что она отправляется в индекс sensor_rollup, а не в исходные индексы sensor-*. И вы также заметите, что она использует конечную точку _rollup_search. В остальном синтаксис точно такой же, как вы ожидаете.

Если вы выполните этот запрос, вы получите результат, похожий на обычный ответ агрегации:

{
  "took" : 102,
  "timed_out" : false,
  "terminated_early" : false,
  "_shards" : ... ,
  "hits" : {
    "total" : {
        "value": 0,
        "relation": "eq"
    },
    "max_score" : 0.0,
    "hits" : [ ]
  },
  "aggregations" : {
    "max_temperature" : {
      "value" : 202.0
    }
  }
}

Единственное заметное отличие заключается в том, что результаты поиска свертывания имеют ноль hits, потому что мы больше не ищем исходные, текущие данные. В остальном синтаксис идентичен.

Здесь есть несколько интересных выводов. Во-первых, даже если данные были свёрнуты с почасовыми интервалами и разделены по имени узла, запрос, который мы выполнили, просто вычисляет максимальную температуру по всем документам. groups, которые были настроены в задаче, не являются обязательными элементами запроса, они просто дополнительные измерения, по которым можно разделить данные. Во-вторых, синтаксис запроса и ответа почти идентичен обычному синтаксису DSL, что облегчает интеграцию в панели мониторинга и приложения.

Наконец, мы можем использовать эти поля группировки, которые мы определили, чтобы построить более сложный запрос:

GET /sensor_rollup/_rollup_search
{
  "size": 0,
  "aggregations": {
    "timeline": {
      "date_histogram": {
        "field": "timestamp",
        "fixed_interval": "7d"
      },
      "aggs": {
        "nodes": {
          "terms": {
            "field": "node"
          },
          "aggs": {
            "max_temperature": {
              "max": {
                "field": "temperature"
              }
            },
            "avg_voltage": {
              "avg": {
                "field": "voltage"
              }
            }
          }
        }
      }
    }
  }
}

Что возвращает соответствующий ответ:

{
   "took" : 93,
   "timed_out" : false,
   "terminated_early" : false,
   "_shards" : ... ,
   "hits" : {
     "total" : {
        "value": 0,
        "relation": "eq"
     },
     "max_score" : 0.0,
     "hits" : [ ]
   },
   "aggregations" : {
     "timeline" : {
       "meta" : { },
       "buckets" : [
         {
           "key_as_string" : "2018-01-18T00:00:00.000Z",
           "key" : 1516233600000,
           "doc_count" : 6,
           "nodes" : {
             "doc_count_error_upper_bound" : 0,
             "sum_other_doc_count" : 0,
             "buckets" : [
               {
                 "key" : "a",
                 "doc_count" : 2,
                 "max_temperature" : {
                   "value" : 202.0
                 },
                 "avg_voltage" : {
                   "value" : 5.1499998569488525
                 }
               },
               {
                 "key" : "b",
                 "doc_count" : 2,
                 "max_temperature" : {
                   "value" : 201.0
                 },
                 "avg_voltage" : {
                   "value" : 5.700000047683716
                 }
               },
               {
                 "key" : "c",
                 "doc_count" : 2,
                 "max_temperature" : {
                   "value" : 202.0
                 },
                 "avg_voltage" : {
                   "value" : 4.099999904632568
                 }
               }
             ]
           }
         }
       ]
     }
   }
}

Помимо того, что он более сложный (гистограмма дат и агрегация по типу, а также дополнительная метрика среднего значения), вы заметите, что date_histogram использует интервал 7d вместо 60m.

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