Сбор и обработка данных

Чтобы проверить, относится ли alias1 к index-1, выполняют одну из следующих команд:

GET /_alias/alias1
GET /index-1/_alias/alias1

Чтобы получить информацию о сопоставлениях индексов и настройках, на которые ссылается псевдоним, выполняют следующую команду:

GET alias1

Добавление или удаление индексов

Возможно выполнить несколько действий с помощью одной и той же операции _aliases. Например, следующая команда удаляет index-1 и добавляет index-2 в alias1:

POST _aliases
{
"actions": [
{
"remove": {
"index": "index-1",
"alias": "alias1"
}
},
{
"add": {
"index": "index-2",
"alias": "alias1"
}
}
]
}

Действия add и remove выполняются атомарно, то есть alias1 никогда не будет указывать одновременно на index-1 и index-2. Также можно добавлять индексы на основе шаблона индекса, как показано в следующем запросе POST:

POST _aliases
{
"actions": [
{
"add": {
"index": "index*",
"alias": "alias1"
}
}
]
}

Действие remove также поддерживает параметр must_exist. Если для параметра задано значение TRUE и указанный псевдоним не существует, возникает исключение. Если для параметра задано значение FALSE, то при отсутствии указанного псевдонима никаких действий не предпринимается. Значение по умолчанию для must_exist — NULL. Исключение возникает только в том случае, если ни один из указанных псевдонимов не существует.

В следующем POST-запросе используется действие remove с параметром must_exist со значением TRUE:

POST _aliases
{
"actions": [
{
"remove": {
"index": "index-1",
"alias": "alias1",
"must_exist": true
}
}
]
}

Управление псевдонимами

Чтобы отобразить распределение псевдонимов на индексы, выполняют следующую команду:

GET _cat/aliases?v
Копировать
Копировать как cURL

Пример ответа:

alias     index   filter    routing.index   routing.search
alias1    index-1   *             –                 -

Чтобы проверить, на какие индексы указывает псевдоним, выполняют следующую команду:

GET _alias/alias1

Пример ответа:

{
"index-2": {
"aliases": {
"alias1": {}
}
}
}

Чтобы узнать, какой псевдоним указывает на конкретный индекс, выполняют следующую команду:

GET /index-2/_alias/*

Чтобы получить все имена индексов и их псевдонимы, выполняют следующую команду:

GET /_alias

Чтобы проверить, существует ли псевдоним, выполняют одну из следующих команд:

HEAD /alias1/_alias/
HEAD /_alias/alias1/
HEAD index-1/_alias/alias1/

Добавление псевдонимов при создании индекса

Добавление индекса к псевдониму при создании индекса можно осуществить так, как показано в следующем запросе PUT:

PUT index-1
{
"aliases": {
"alias1": {}
}
}

Создание отфильтрованных псевдонимов

Создание отфильтрованного псевдонима для доступа к подмножеству документов или полей в базовых индексах добавляет только определенное поле временной метки в alias1. Ниже показан пример запроса POST:

POST _aliases
{
"actions": [
{
"add": {
"index": "index-1",
"alias": "alias1",
"filter": {
"term": {
"timestamp": "1574641891142"
}
}
}
}
]
}

Параметры псевдонима индекса

Параметры псевдонима индекса показаны в таблице 16.

Удаление псевдонимов

Чтобы удалить один или несколько псевдонимов из индекса, используют следующий запрос:

DELETE <index>/_alias/<alias>
DELETE <index>/_aliases/<alias>

И <index>, и <alias> в приведенном выше запросе поддерживают списки, разделенные запятыми, и подстановочные выражения. Следует использовать _all вместо <alias> для удаления всех псевдонимов для индексов, перечисленных в <index>.

Например, если alias1 относится к index-1 и index-2, можно выполнить следующую команду, чтобы удалить alias1 из index-1:

DELETE index-1/_alias/alias1

После выполнения запроса alias1 больше не относится к index-1, но по-прежнему относится к index-2.

Потоки данных

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

Типичный рабочий процесс для управления данными временных рядов состоит из нескольких этапов, таких как: создание псевдонима индекса для переключения, определение индекса для записи и определение общих сопоставлений и настроек для базовых индексов.

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

Поток данных внутренне состоит из нескольких вспомогательных индексов. Запросы на поиск направляются во все вспомогательные индексы, а запросы на индексирование направляются в последний индекс для записи. Политики ISM позволяют автоматически обрабатывать обновление или удаление индексов.

Работа с потоками данных осуществляется пошагово:

1. Шаг 1: Создать шаблон индекса

Чтобы создать поток данных, сначала нужно создать шаблон индекса, который настраивает набор индексов как поток данных. Объект data_stream указывает на то, что это поток данных, а не обычный шаблон индекса. Шаблон индекса совпадает с названием потока данных:

PUT _index_template/logs-template
{
"index_patterns": [
"my-data-stream",
"logs-*"
],
"data_stream": {},
"priority": 100
}

В этом случае в каждом загружаемом документе должно быть поле @timestamp. Также можно определить собственное поле с отметкой времени в качестве свойства объекта data_stream. Кроме того, можно добавить сопоставления индексов и другие настройки, как и в случае с обычным шаблоном индекса.

PUT _index_template/logs-template-nginx
{
"index_patterns": "logs-nginx",
"data_stream": {
"timestamp_field": {
"name": "request_time"
}
},
"priority": 200,
"template": {
"settings": {
"number_of_shards": 1,
"number_of_replicas": 0
}
}
}

В этом случае индекс logs-nginx соответствует шаблонам logs-template и logs-template-nginx. Если имеется несколько подходящих шаблонов, Подсистема выбирает шаблон с более высоким приоритетом.

2. Шаг 2: Создать поток данных

После создания шаблона индекса нужно создать поток данных. Для этого можно использовать API потока данных для явного создания потока данных. API потока данных инициализирует первый вспомогательный индекс:

PUT _data_stream/logs-redis
PUT _data_stream/logs-nginx

Также можно напрямую начать прием данных, не создавая поток данных.

Поскольку есть соответствующий шаблон индекса с объектом data_stream, Подсистема автоматически создает поток данных:

POST logs-staging/_doc
{
"message": "login attempt failed",
"@timestamp": "2013-03-01T00:00:00"
}

Чтобы просмотреть информацию о конкретном потоке данных, используют:

GET _data_stream/logs-nginx

Пример ответа:

{
"data_streams" : [
{
"name" : "logs-nginx",
"timestamp_field" : {
"name" : "request_time"
},
"indices" : [
{
"index_name" : ".ds-logs-nginx-000001",
"index_uuid" : "-VhmuhrQQ6ipYCmBhn6vLw"
}
],
"generation" : 1,
"status" : "GREEN",
"template" : "logs-template-nginx"
}
]
}

В ответе можно увидеть название поля с отметкой времени, список вспомогательных индексов и шаблон, используемый для создания потока данных. Кроме того, можно увидеть состояние потока данных, которое соответствует самому низкому статусу всех его вспомогательных индексов.

Чтобы получить дополнительную информацию о потоке данных, используют endpoint _stats:

GET _data_stream/logs-nginx/_stats

Пример ответа:

{
"_shards" : {
"total" : 1,
"successful" : 1,
"failed" : 0
},
"data_stream_count" : 1,
"backing_indices" : 1,
"total_store_size_bytes" : 208,
"data_streams" : [
{
"data_stream" : "logs-nginx",
"backing_indices" : 1,
"store_size_bytes" : 208,
"maximum_timestamp" : 0
}
]
}

Чтобы просмотреть информацию обо всех потоках данных, используют следующий запрос:

GET _data_stream

3. Шаг 3: Ввод данных в поток данных

Чтобы добавить данные в поток данных, можно использовать обычные API-интерфейсы индексирования. Следует убедиться, что в каждом индексируемом документе есть поле с отметкой времени. Если попытаться добавить документ без поля с отметкой времени, будет получено сообщение об ошибке.

POST logs-redis/_doc
{
"message": "login attempt",
"@timestamp": "2013-03-01T00:00:00"
}

4. Шаг 4: Поиск в потоке данных

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

GET logs-redis/_search
{
"query": {
"match": {
"message": "login"
}
}
}

Пример ответа:

{
"took" : 514,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 0.2876821,
"hits" : [
{
"_index" : ".ds-logs-redis-000001",
"_type" : "_doc",
"_id" : "-rhVmXoBL6BAVWH3mMpC",
"_score" : 0.2876821,
"_source" : {
"message" : "login attempt",
"@timestamp" : "2013-03-01T00:00:00"
}
}
]
}
}

5. Шаг 5: Переключение потока данных

Операция переключения создает новый вспомогательный индекс, который становится новым индексом записи для потока данных.

Для выполнения ручной операции переключения в потоке данных:

POST logs-redis/_rollover

Пример ответа:

{
"acknowledged" : true,
"shards_acknowledged" : true,
"old_index" : ".ds-logs-redis-000001",
"new_index" : ".ds-logs-redis-000002",
"rolled_over" : true,
"dry_run" : false,
"conditions" : { }
}

Если теперь выполнить операцию GET над потоком данных logs-redis, то можно убедиться, что идентификатор поколения увеличивается с 1 до 2.

Также можно настроить политику ISM для автоматизации процесса обновления потока данных. Политика ISM применяется к вспомогательным индексам во время их создания. Когда происходит связывание политики с потоком данных, она влияет только на будущие вспомогательные индексы этого потока данных.

Нет необходимости задавать параметр rollover_alias, поскольку политика ISM получает эту информацию из вспомогательного индекса.

6. Шаг 6: Управление потоками данных на "Панелях мониторинга" Подсистемы

Чтобы управлять потоками данных в "Панелях мониторинга" Подсистемы, нужно открыть интерфейс, выбрать "Управление индексом", затем "Индексы" или "Индексы, управляемые политикой".

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

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

Возможно выбрать один или несколько потоков данных и применить к ним политику ISM. Также можно применить политику к любому отдельному вспомогательному индексу.

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

1. Шаг 7: Удаление потока данных

Операция удаления сначала удаляет вспомогательные индексы потока данных, а затем удаляет сам поток данных.

Чтобы удалить поток данных и все его скрытые резервные индексы:

DELETE _data_stream/<name_of_data_stream>

Возможно использовать подстановочные знаки для удаления более чем одного потока данных.

Рекомендуется удалять данные из потока данных с использованием политики ISM.

Возможно использовать асинхронный поиск, SQL и PPL для прямого запроса данных в потоке. Также можно использовать плагин Security для определения подробных разрешений для имени потока данных.

Переиндексация данных

После создания индекса может потребоваться внести существенные изменения, например, добавить новое поле в каждый документ или объединить несколько индексов в один. Вместо того чтобы удалять индекс, вносить изменения в автономном режиме, а затем снова индексировать данные, можно использовать операцию reindex.

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

Переиндексация может быть объемной операцией в зависимости от размера исходного индекса. Рекомендуется отключить реплики в целевом индексе, установив number_of_replicas в значение 0, и снова включить их после завершения процесса переиндексации.

Переиндексация всех документов

Для переиндексации можно скопировать все документы из одного индекса в другой.

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

PUT destination
{
"mappings":{
"Add in your desired mappings"
},
"settings":{
"Add in your desired settings"
}
}

Команда reindex копирует все документы из исходного индекса в целевой индекс:

POST _reindex
{
"source":{
"index":"source"
},
"dest":{
"index":"destination"
}
}

Если целевой индекс еще не создан, операция reindex создаст новый целевой индекс с настройками по умолчанию.

Переиндексация из удаленного кластера

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

Эта команда обращается к удаленному кластеру, входит в Подсистему, используя имя пользователя и пароль, и копирует все документы из исходного индекса удаленного кластера в целевой индекс локального кластера:

POST _reindex
{
"source":{
"remote":{
"host":"https://<REST_endpoint_of_remote_cluster>:9200",
"username":"YOUR_USERNAME",
"password":"YOUR_PASSWORD"
},
"index": "source"
},
"dest":{
"index":"destination"
}
}

Допустимые параметры указаны в таблице 17.

В таблице 18 перечислены параметры кластера для политики повторных попыток.

Переиндексация подмножества документов

Возможно скопировать определенный набор документов, соответствующий поисковому запросу.

Эта команда копирует в целевой индекс только часть документов, соответствующих запросу:

POST _reindex
{
"source":{
"index":"source",
"query": {
"match": {
"field_name": "text"
}
}
},
"dest":{
"index":"destination"
}
}

Слияние одного или нескольких индексов

Возможно объединить документы из одного или нескольких индексов, добавив исходные индексы в виде списка.

Например, эта команда копирует все документы из двух исходных индексов в один индекс назначения:

POST _reindex
{
"source":{
"index":[
"source_1",
"source_2"
]
},
"dest":{
"index":"destination"
}
}

Следует убедиться, что количество сегментов в исходных и целевых индексах одинаково.

Переиндексация только уникальных документов

Возможно копировать только документы, отсутствующие в целевом индексе, установив для параметра op_type значение create. В этом случае, если документ с таким же идентификатором уже существует, операция игнорирует документ из исходного индекса. Чтобы игнорировать все конфликты версий документов, нужно установить для параметра conflicts значение proceed.

POST _reindex
{
"conflicts":"proceed",
"source":{
"index":"source"
},
"dest":{
"index":"destination",
"op_type":"create"
}
}

Преобразование документов во время переиндексации

Возможно преобразовать свои данные в процессе переиндексации с помощью опции script.

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

POST _reindex
{
"source":{
"index":"source"
},
"dest":{
"index":"destination"
},
"script":{
"lang":"painless",
"source":"ctx._account.number++"
}
}

Также можно указать конвейер обработки данных для их преобразования в процессе переиндексации.

Сначала нужно создать конвейер с определенными параметрами processors. В конвейере приема данных можно использовать несколько различных параметров processors.

Ниже приведен пример конвейера обработки данных, который определяет split-процессор, разделяющий поле text на основе разделителя "пробел" и сохраняющий его в новом поле word. Script-процессор — это безопасный скрипт, который определяет длину поля word и сохраняет ее в новом поле word_count. Remove-процессор удаляет поле test.

PUT _ingest/pipeline/pipeline-test
{
"description": "Splits the text field into a list. Computes the length of the 'word' field and stores it in a new 'word_count' field. Removes the 'test' field.",
"processors": [
{
"split": {
"field": "text",
"separator": "\\s+",
"target_field": "word"
}
},
{
"script": {
"lang": "painless",
"source": "ctx.word_count = ctx.word.length"
}
},
{
"remove": {
"field": "test"
}
}
]
}

После создания конвейера можно использовать операцию reindex:

POST _reindex
{
"source": {
"index": "source"
},
"dest": {
"index": "destination",
"pipeline": "pipeline-test"
}
}

Обновление документов в текущем индексе

Чтобы обновить данные в текущем индексе, не копируя их в другой индекс, используют операцию update_by_query.

Операция update_by_query — это POST-операция, которую можно выполнять с одним индексом за раз:

POST <index_name>/_update_by_query

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

Параметры исходного индекса

Параметры для исходного индекса приведены в таблице 19.

Параметры целевого индекса

Параметры для целевого индекса приведены в таблице 20.

Политики

Политики – это документы JSON, которые определяют следующее:

• Состояния, в которых может находиться индекс, включая состояние по умолчанию для новых индексов. Например, можно назвать свои состояния "активный", "отложенный", "удаленный" и так далее;
• Любые действия для выполнения плагином при переходе индекса в другое состояние, например при выполнении операции переключения;
• Условия, которые должны быть соблюдены для перехода индекса в новое состояние, называются переходами. Например, если индексу больше восьми недель, можно перевести его в состояние "удалить".

Другими словами, политика определяет состояния, в которых может находиться индекс, действия, которые необходимо выполнять в каждом состоянии, и условия, которые должны быть соблюдены для перехода между состояниями.

Политики можно полностью гибко настраивать: создать любое состояние, перейти в любое другое состояние и указать любое количество действий в каждом состоянии.

В таблице 21 перечислены соответствующие поля политики.

Состояния

Состояние — это описание статуса, в котором в данный момент находится управляемый индекс. Управляемый индекс может находиться только в одном состоянии одновременно. С каждым состоянием связаны действия, которые выполняются последовательно при переходе в состояние, и переходы, которые проверяются после выполнения всех действий.

В таблице 22 перечислены параметры, которые можно определить для состояния.

Действия

Действия — это шаги, которые последовательно выполняет политика при переходе в определенное состояние.

ISM выполняет действия в том порядке, в котором они определены. Например, если определяются действия A, B, C, D, ISM выполняет действие "A", а затем переходит в режим ожидания в соответствии с настройками кластера plugins.index_state_management.job_interval. По окончании режима ожидания ISM продолжает выполнять оставшиеся действия. Однако если ISM не может успешно выполнить действие "A", операция завершается, и действия "B", "C" и "D" не выполняются.

При необходимости можно задать период ожидания действия, по истечении которого действие будет принудительно прервано. Например, если период ожидания установлен на 1d, а ISM не завершит действие в течение одного дня даже после повторных попыток, действие будет прервано.

В таблице 23 перечислены параметры, которые можно определить для действия.

Параметры операции retry приведены в таблице 24.

В следующем примере действие имеет период ожидания в один час. Политика повторяет это действие три раза с экспоненциальной отсрочкой, с задержкой в 10 минут между каждой попыткой:

"actions": {
"timeout": "1h",
"retry": {
"count": 3,
"backoff": "exponential",
"delay": "10m"
}
}

Операции, поддерживаемые ISM

ISM поддерживает следующие операции:

• force_merge – уменьшает количество сегментов за счет объединения отдельных сегментов. Эта операция пытается привести индекс в состояние "read-only" перед началом процесса объединения. Параметры операции приведены в таблице 25.

Пример:

{
"force_merge": {
"max_num_segments": 1
}
}

• read_only – устанавливает управляемый индекс, доступный только для чтения.

Пример:

{
"read_only": {}
}

Рекомендуется задать для управляемого индекса параметр index.blocks.write в значение TRUE.

Примечание – Это блокирование не препятствует обновлению индекса.

• read_write – делает управляемый индекс доступным для записи.

Пример:

{
"read_write": {}
}

• replica_count – задает количество реплик, которые нужно присвоить индексу.

Параметр number_of_replicas с типом number определяет количество реплик, которые нужно присвоить индексу и является обязательным.

Пример:

{
"replica_count": {
"number_of_replicas": 2
}
}

• shrink – позволяет уменьшить количество основных сегментов в индексах. С помощью этого действия можно указать:
• количество основных сегментов, которые должен содержать целевой индекс;
• максимальный размер сегментов для основных сегментов в целевом индексе;
• процентное значение для уменьшения количества основных сегментов в целевом индексе.

Пример:

"shrink": {
"num_new_shards": 1,
"target_index_name_template": {
"source": "_shrunken"
},
"aliases": [
{
"my-alias": {}
}
],
"switch_aliases": true,
"force_unsafe": false
}

Параметры операции shrink приведены в таблице 26.

Если требуется добавить aliases к действию, параметр должен содержать массив объектов псевдонимов, например,

"aliases": [
{
"my-alias": {}
},
{
"my-second-alias": {
"is_write_index": false,
"filter": {
"multi_match": {
"query": "QUEEN",
"fields": ["speaker", "text_entry"]
}
},
"index_routing" : "1",
"search_routing" : "1"
}
},
]

• close – закрывает управляемый индекс.

Пример:

{
"close": {}
}

Закрытые индексы остаются на диске, но не потребляют ресурсы процессора или памяти. Нельзя читать закрытые индексы, записывать в них данные или выполнять поиск по ним.

Закрытие индекса — хороший вариант, если нужно хранить данные дольше, чем планируется их активно искать, и если на узлах данных достаточно места на диске. Если нужно снова выполнить поиск данных, проще открыть закрытый индекс, чем восстановить его из снимка.

• open – открывает управляемый индекс.

Пример:

{
"open": {}
}

delete – удаляет управляемый индекс.

Пример:

{
"delete": {}
}

• rollover – переключает псевдоним в новый индекс, когда управляемый индекс соответствует одному из условий переключения.

ISM проверяет условия для операций при каждом выполнении политики в соответствии с установленным интервалом, а не постоянно. Переключение будет выполнено, если значение достигнет или превысит установленный предел при выполнении проверки. Например, если min_size установлено значение в 100 ГБ, ISM может проверить индекс при 99 ГБ и не выполнить переполнение. Однако если к моменту следующей проверки индекс превысит лимит (например, 105 ГБ), будет выполнена операция.

Если нужно пропустить действие переключения, можно установить параметр индекса index.plugins.index_state_management.rollover_skip в TRUE. Например, если получено сообщение об ошибке "Отсутствует псевдоним или индекс записи…", можно установить параметр index.plugins.index_state_management.rollover_skip в TRUE и повторить попытку, чтобы пропустить действие переключения.

Формат индекса должен соответствовать шаблону: ^.*-\d+$, например (logs-000001). Можно задать параметр index.plugins.index_state_management.rollover_alias в качестве псевдонима для переключения.

Параметры операции rollover приведены в таблице 27.

Пример:

{
"rollover": {
"min_size": "50gb"
}
}
{
"rollover": {
"min_primary_shard_size": "30gb"
}
}
{
"rollover": {
"min_doc_count": 100000000
}
}
{
"rollover": {
"min_index_age": "30d"
}
}

• notification – отправляет уведомление.

Для уведомлений доступны параметры, перечисленные в таблице 28.

Система назначения должна вернуть ответ, иначе операция уведомления завершится ошибкой.

Пример 1: Уведомление о перезвоне

{
"notification": {
"destination": {
"chime": {
"url": "<url>"
}
},
"message_template": {
"source": "the index is {{ctx.index}}"
}
}
}

Пример 2: Пользовательское уведомление webhook

{
"notification": {
"destination": {
"custom_webhook": {
"url": "https://<your_webhook>"
}
},
"message_template": {
"source": "the index is {{ctx.index}}"
}
}
}

Пример 3: Уведомление о замедлении

{
"notification": {
"destination": {
"slack": {
"url": "https://hooks.slack.com/services/xxx/xxxxxx"
}
},
"message_template": {
"source": "the index is {{ctx.index}}"
}
}
}

Можно использовать переменные ctx в сообщении, чтобы указать ряд параметров политики на основе предыдущих выполнений политики. Например, если в политике есть действие по переключению, можно использовать в сообщении, чтобы указать название переключения.

Для каждой политики доступны параметры ctx-переменных, перечисленные в таблице 29.

• snapshot – создает резервную копию индексов и состояния кластера.

Параметры операции перечислены в таблице 30.

Пример:

{
"snapshot": {
"repository": "my_backup",
"snapshot": ""
}
}

• index_priority – задает приоритет для индекса в определенном состоянии. Нераспределенные сегменты индексов восстанавливаются в порядке их приоритета, если это возможно. Сначала восстанавливаются индексы с более высоким приоритетом, а затем — с более низким.

Параметр операции приведен в таблице 31.

Пример:

"actions": [
{
"index_priority": {
"priority": 50
}
}
]

• allocation – назначает индекс узлу с определенным набором атрибутов. Например, установка require в значение "warm" перемещает данные только на узлы "warm".

Операция имеет следующие параметры, приведенные в таблице 32.

Пример:

"actions": [
{
"allocation": {
"require": { "temp": "warm" }
}
}
]

• rollup – слияние индексов позволяет периодически уменьшать детализацию данных, объединяя старые данные в сводные индексы.

Задания на слияние могут быть непрерывными или прерывистыми. Задание на слияние, созданное с помощью политики ISM, может быть только прерывистым.

Примеры endpoints:

PUT _plugins/_rollup/jobs/<rollup_id>
GET _plugins/_rollup/jobs/<rollup_id>
DELETE _plugins/_rollup/jobs/<rollup_id>
POST _plugins/_rollup/jobs/<rollup_id>/_start
POST _plugins/_rollup/jobs/<rollup_id>/_stop
GET _plugins/_rollup/jobs/<rollup_id>/_explai

Пример сводной политики ISM:

{
"policy": {
"description": "Sample rollup" ,
"default_state": "rollup",
"states": [
{
"name": "rollup",
"actions": [
{
"rollup": {
"ism_rollup": {
"description": "Creating rollup through ISM",
"target_index": "target",
"page_size": 1000,
"dimensions": [
{
"date_histogram": {
"fixed_interval": "60m",
"source_field": "order_date",
"target_field": "order_date",
"timezone": "America/Los_Angeles"
}
},
{
"terms": {
"source_field": "customer_gender",
"target_field": "customer_gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day_of_week"
}
}
],
"metrics": [
{
"source_field": "taxless_total_price",
"metrics": [
{
"sum": {}
}
]
},
{
"source_field": "total_quantity",
"metrics": [
{
"avg": {}
},
{
"max": {}
}
]
}
]
}
}
}
],
"transitions": []
}
]
}
}

Переходы

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

ISM оценивает переходы в том порядке, в котором они определены. Например, если определены переходы A, B, C, D, ISM перебирает этот список переходов до тех пор, пока не найдет переход, который оценивается как TRUE, после чего останавливается и устанавливает следующее состояние в соответствии с этим переходом. При следующем выполнении ISM игнорирует остальные переходы и начинает работу в этом новом состоянии.

Если не указываются никакие условия для перехода, и он оставляется пустым, то предполагается, что он всегда выполняется. Это означает, что политика переводит индекс в это состояние в момент проверки.

В таблице 33 перечислены параметры, которые можно определить для переходов.

Объект conditions имеет параметры, перечисленные в таблице 34.

В следующем примере индекс переходит в состояние cold через 30 дней:

"transitions": [
{
"state_name": "cold",
"conditions": {
"min_index_age": "30d"
}
}
]

ISM проверяет условия при каждом выполнении политики в соответствии с заданным интервалом.

В этом примере используется условие cron для переключения индексов каждую субботу в 17:00 по тихоокеанскому времени:

"transitions": [
{
"state_name": "cold",
"conditions": {
"cron": {
"cron": {
"expression": "* 17 * * SAT",
"timezone": "America/Los_Angeles"
}
}
}
}
]

Следует обратить внимание, что это условие выполняется не ровно в 17:00; задание по-прежнему выполняется в соответствии с настройкой job_interval. Из-за разницы во времени начала и времени, которое может потребоваться для выполнения действий до проверки условий перехода, не рекомендуется использовать слишком узкие выражения cron. Например, не стоит использовать "15 17 * * SAT" (17:15 в субботу).

Окно в один час, которое используется в этом примере, обычно достаточно, но можно увеличить его до 2–3 часов, чтобы не пропустить это окно и не ждать неделю, пока произойдет переход. В качестве альтернативы можно использовать более широкое выражение, например "* * * * SAT,SUN", чтобы переход происходил в любое время в течение выходных.

Уведомления об ошибках

Операция error_notification отправляет уведомление в случае сбоя управляемого индекса. Она уведомляет одного получателя или канал уведомлений с помощью специального сообщения.

Настройка уведомлений об ошибках на уровне политики осуществляется следующим образом:

{
"policy": {
"description": "hot warm delete workflow",
"default_state": "hot",
"schema_version": 1,
"error_notification": { },
"states": [ ]
}
}

Параметры операции перечислены в таблице 35.

Канал уведомлений должен вернуть ответ, иначе операция error_notification выдаст ошибку.

Пример 1: Уведомление о получении

{
"error_notification": {
"destination": {
"chime": {
"url": "<url>"
}
},
"message_template": {
"source": "The index {{ctx.index}} failed during policy execution."
}
}
}

Пример 2: Пользовательское уведомление webhook

{
"error_notification": {
"destination": {
"custom_webhook": {
"url": "https://<your_webhook>"
}
},
"message_template": {
"source": "The index {{ctx.index}} failed during policy execution."
}
}
}

Пример 3: Уведомление Slack

{
"error_notification": {
"destination": {
"slack": {
"url": "https://hooks.slack.com/services/xxx/xxxxxx"
}
},
"message_template": {
"source": "The index {{ctx.index}} failed during policy execution."
}
}
}

Пример 4. Использование канала уведомлений

{
"error_notification": {
"channel": {
"id": "some-channel-config-id"
},
"message_template": {
"source": "The index {{ctx.index}} failed during policy execution."
}
}
}

Можно использовать те же параметры для переменных ctx при выполнении операции уведомления.

Управляемые индексы

C помощью операций с управляемым индексом можно изменить или обновить политику.

В таблице 36 перечислены параметры операций с управляемым индексированием.

В следующем примере показана политика управляемого индексирования:

{
"managed_index": {
"name": "my_index",
"index": "my_index",
"index_uuid": "sOKSOfkdsoSKeofjIS",
"enabled": true,
"enabled_time": 1553112384,
"last_updated_time": 1553112384,
"schedule": {
"interval": {
"period": 1,
"unit": "MINUTES",
"start_time": 1553112384
}
},
"policy_id": "log_rotation",
"policy_version": 1,
"policy": {...},
"change_policy": null
}
}

Настройки ISM

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

ISM сохраняет свою конфигурацию в индексе .opendistro-ism-config. Не следует изменять этот индекс без использования операций API ISM.

Все настройки доступны с помощью операции _cluster/settings. Ни одна из них не требует перезапуска, и все они могут быть помечены persistent или transient. Перечень настроек приведен в таблице 37.

ISM API

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

Создание политики

Пример запроса:

PUT _plugins/_ism/policies/policy_1
{
"policy": {
"description": "ingesting logs",
"default_state": "ingest",
"states": [
{
"name": "ingest",
"actions": [
{
"rollover": {
"min_doc_count": 5
}
}
],
"transitions": [
{
"state_name": "search"
}
]
},
{
"name": "search",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "5m"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
]
}
}

Пример ответа:

{
"_id": "policy_1",
"_version": 1,
"_primary_term": 1,
"_seq_no": 7,
"policy": {
"policy": {
"policy_id": "policy_1",
"description": "ingesting logs",
"last_updated_time": 1577990761311,
"schema_version": 1,
"error_notification": null,
"default_state": "ingest",
"states": [
{
"name": "ingest",
"actions": [
{
"rollover": {
"min_doc_count": 5
}
}
],
"transitions": [
{
"state_name": "search"
}
]
},
{
"name": "search",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "5m"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
]
}
}
}

Добавление политики

Операция добавляет политику в индекс. Эта операция не изменяет политику, если она уже есть в индексе.

Пример запроса:

POST _plugins/_ism/add/index_1
{
"policy_id": "policy_1"
}

Пример ответа:

{
"updated_indices": 1,
"failures": false,
"failed_indices": []
}

Если при добавлении политики к индексу используется подстановочный знак *, плагин ISM интерпретирует * как все индексы, включая системные индексы, такие как .opendistro-security, в которых хранятся пользователи, роли и арендаторы. Действие удаления в политике может привести к случайному удалению всех ролей пользователей и арендаторов в кластере. Не следует использовать подстановочный знак * с широкими возможностями, а вместо этого лучше добавлять префикс, например my-logs*, при указании индексов с помощью _ism/add API.

Обновление политики

Операция обновляет политику. Используются параметры seq_no и primary_term для обновления существующей политики. Если эти значения не соответствуют существующей политике или политика не существует, ISM выдаст ошибку.

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

PUT _plugins/_ism/policies/policy_1?if_seq_no=7&if_primary_term=1
{
"policy": {
"description": "ingesting logs",
"default_state": "ingest",
"states": [
{
"name": "ingest",
"actions": [
{
"rollover": {
"min_doc_count": 5
}
}
],
"transitions": [
{
"state_name": "search"
}
]
},
{
"name": "search",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "5m"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
]
}
}

Пример ответа:

{
"_id": "policy_1",
"_version": 2,
"_primary_term": 1,
"_seq_no": 10,
"policy": {
"policy": {
"policy_id": "policy_1",
"description": "ingesting logs",
"last_updated_time": 1577990934044,
"schema_version": 1,
"error_notification": null,
"default_state": "ingest",
"states": [
{
"name": "ingest",
"actions": [
{
"rollover": {
"min_doc_count": 5
}
}
],
"transitions": [
{
"state_name": "search"
}
]
},
{
"name": "search",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "5m"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
]
}
}
}

Получить политику

Операция получает политику с помощью policy_id.

Пример запроса:

GET _plugins/_ism/policies/policy_1

Пример ответа:

{
"_id": "policy_1",
"_version": 2,
"_seq_no": 10,
"_primary_term": 1,
"policy": {
"policy_id": "policy_1",
"description": "ingesting logs",
"last_updated_time": 1577990934044,
"schema_version": 1,
"error_notification": null,
"default_state": "ingest",
"states": [
{
"name": "ingest",
"actions": [
{
"rollover": {
"min_doc_count": 5
}
}
],
"transitions": [
{
"state_name": "search"
}
]
},
{
"name": "search",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "5m"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
]
}
}

Удаление политики из индекса

Операция удаляет любую политику ISM из индекса.

Пример запроса:

POST _plugins/_ism/remove/index_1

Пример ответа:

{
"updated_indices": 1,
"failures": false,
"failed_indices": []
}

Обновление политики управляемого индекса

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

Изменение политики — это асинхронный фоновый процесс. Изменения ставятся в очередь и не выполняются сразу фоновым процессом. Эта задержка в выполнении защищает управляемые индексы, которые работают в данный момент, от перехода в нерабочее состояние. Если политика, которую нужно изменить, содержит лишь небольшие изменения в конфигурации, то изменение происходит немедленно. Например, если политика изменяет параметр min_index_age в условии перехода с 1000d на 100d, то это изменение происходит немедленно при следующем выполнении. Если изменение затрагивает состояние, действия или порядок действий в текущем состоянии, в котором находится индекс, то изменение происходит в конце текущего состояния перед переходом в новое состояние.

В этом примере политика, применяемая к индексу index_1, изменяется на policy_1, которая может быть как совершенно новой политикой, так и обновленной версией существующей политики. Процесс применяет изменение только в том случае, если индекс в данный момент находится в состоянии searches. После изменения политики index_1 переходит в состояние delete.

Пример запроса:

POST _plugins/_ism/change_policy/index_1
{
"policy_id": "policy_1",
"state": "delete",
"include": [
{
"state": "searches"
}
]
}

Пример ответа:

{
"updated_indices": 0,
"failures": false,
"failed_indices": []
}

Повторение неудачной попытки индексирования

Операция повторяет неудачное действие для индекса. Чтобы повторная попытка прошла успешно, ISM должен управлять индексом, а индекс должен находиться в состоянии сбоя. Можно использовать шаблоны индексов (*) для повторной попытки нескольких неудачных индексов.

Пример запроса:

POST _plugins/_ism/retry/index_1
{
"state": "delete"
}

Пример ответа:

{
"updated_indices": 0,
"failures": false,
"failed_indices": []
}

Состояние индекса

Операция получает текущее состояние индекса. Можно использовать шаблоны индексов для получения состояния нескольких индексов.

Пример запроса:

GET _plugins/_ism/explain/index_1

Пример ответа:

{
"index_1": {
"index.plugins.index_state_management.policy_id": "policy_1"
}
}

При необходимости можно добавить параметр show_policy в путь запроса, чтобы получить политику, которая в данный момент применяется к индексу. Это полезно для проверки того, является ли политика, применяемая к индексу, последней.

Пример запроса:

GET _plugins/_ism/explain/index_1?show_policy=true

Пример ответа:

{
"index_1": {
"index.plugins.index_state_management.policy_id": "sample-policy",
"index.opendistro.index_state_management.policy_id": "sample-policy",
"index": "index_1",
"index_uuid": "gCFlS_zcTdih8xyxf3jQ-A",
"policy_id": "sample-policy",
"enabled": true,
"policy": {
"policy_id": "sample-policy",
"description": "ingesting logs",
"last_updated_time": 1647284980148,
"schema_version": 13,
"error_notification": null,
"default_state": "ingest",
"states": [...],
"ism_template": null
}
},
"total_managed_indices": 1
}

Удаление политики

Операция удаляет политику с помощью policy_id.

Пример запроса:

DELETE _plugins/_ism/policies/policy_1

Пример ответа:

{
"_index": ".opendistro-ism-config",
"_id": "policy_1",
"_version": 3,
"result": "deleted",
"forced_refresh": true,
"_shards": {
"total": 2,
"successful": 2,
"failed": 0
},
"_seq_no": 15,
"_primary_term": 1
}

Проверка предотвращения ошибок

ISM позволяет автоматически запускать действие, но запуск действия может завершиться ошибкой по ряду причин. Можно использовать проверку для предотвращения ошибок, чтобы протестировать действие и исключить сбои.

Чтобы включить проверку предотвращения ошибок, устанавливают для параметра plugins.index_state_management.action_validation.enabled значение TRUE:

PUT _cluster/settings
{
"persistent":{
"plugins.index_state_management.action_validation.enabled": true
}
}

Пример ответа:

{
"acknowledged" : true,
"persistent" : {
"plugins" : {
"index_state_management" : {
"validation_action" : {
"enabled" : "true"
}
}
}
},
"transient" : { }
}

Чтобы проверить статус и сообщение о предотвращении ошибок, передают validate_action=true в endpoint _plugins/_ism/explain:

GET _plugins/_ism/explain/test-000001?validate_action=true

Пример ответа содержит дополнительный объект проверки с сообщением о состоянии проверки:

{
"test-000001" : {
"index.plugins.index_state_management.policy_id" : "test_rollover",
"index.opendistro.index_state_management.policy_id" : "test_rollover",
"index" : "test-000001",
"index_uuid" : "CgKsxFmQSIa8dWqpbSJmyA",
"policy_id" : "test_rollover",
"policy_seq_no" : -2,
"policy_primary_term" : 0,
"rolled_over" : false,
"index_creation_date" : 1667410460649,
"state" : {
"name" : "rollover",
"start_time" : 1667410766045
},
"action" : {
"name" : "rollover",
"start_time" : 1667411127803,
"index" : 0,
"failed" : false,
"consumed_retries" : 0,
"last_retry_time" : 0
},
"step" : {
"name" : "attempt_rollover",
"start_time" : 1667411127803,
"step_status" : "starting"
},
"retry_info" : {
"failed" : true,
"consumed_retries" : 0
},
"info" : {
"message" : "Previous action was not able to update IndexMetaData."
},
"enabled" : false,
"validate" : {
"validation_message" : "Missing rollover_alias index setting [index=test-000001]",
"validation_status" : "re_validating"
}
},
"total_managed_indices" : 1
}

Если передать validate_action=false или не передать значение validate_action в endpoint _plugins/_ism/explain, ответ не будет содержать статус проверки на наличие ошибок и сообщение:

GET _plugins/_ism/explain/test-000001?validate_action=false

или:

GET _plugins/_ism/explain/test-000001

Пример ответа:

{
"test-000001" : {
"index.plugins.index_state_management.policy_id" : "test_rollover",
"index.opendistro.index_state_management.policy_id" : "test_rollover",
"index" : "test-000001",
"index_uuid" : "CgKsxFmQSIa8dWqpbSJmyA",
"policy_id" : "test_rollover",
"policy_seq_no" : -2,
"policy_primary_term" : 0,
"rolled_over" : false,
"index_creation_date" : 1667410460649,
"state" : {
"name" : "rollover",
"start_time" : 1667410766045
},
"action" : {
"name" : "rollover",
"start_time" : 1667411127803,
"index" : 0,
"failed" : false,
"consumed_retries" : 0,
"last_retry_time" : 0
},
"step" : {
"name" : "attempt_rollover",
"start_time" : 1667411127803,
"step_status" : "starting"
},
"retry_info" : {
"failed" : true,
"consumed_retries" : 0
},
"info" : {
"message" : "Previous action was not able to update IndexMetaData."
},
"enabled" : false
},
"total_managed_indices" : 1
}

Преобразования индексов

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

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

Задания преобразования можно использовать двумя способами:

1. С помощью пользовательского интерфейса "Панелей мониторинга" указать индекс, который требуется преобразовать, и дополнительные фильтры данных, которые предполагается использовать для фильтрации исходного индекса. Затем выбрать поля, которые нужно преобразовать, и агрегации, которые необходимо использовать при преобразовании. Наконец, определить расписание для выполнения задания.
2. Использовать API преобразований, чтобы указать все сведения о задании: индекс, который требуется преобразовать, целевые группы, которые должен содержать преобразованный индекс, любые агрегации, которые предполагается использовать для группировки столбцов, а также расписание выполнения задания.

На "Панелях мониторинга" Подсистемы отображается подробная сводка по созданным заданиям и соответствующая информация, например связанные индексы и статусы заданий. Можно просмотреть и отредактировать сведения о задании и выбранные параметры перед его созданием и даже просмотреть данные преобразованного индекса, выбирая поля для преобразования. Однако также можно использовать REST API для создания заданий преобразования и предварительного просмотра результатов преобразования, но для этого необходимо знать все необходимые настройки и параметры, чтобы отправить их в теле HTTP-запроса. Отправка конфигураций заданий преобразования в виде скриптов JSON обеспечивает большую переносимость и позволяет делиться заданиями преобразования и воспроизводить их, что сложнее сделать с помощью "Панелей мониторинга" Подсистемы.

Сценарии использования помогут решить, какой метод использовать для создания заданий на преобразование.

Преобразование API

Помимо использования "Панелей мониторинга" Подсистемы также можно использовать REST API для создания, запуска, остановки и выполнения других операций, связанных с заданиями преобразования.

Создание задания преобразования

Операция создает задание преобразования.

Формат запроса:

PUT _plugins/_transform/<transform_id>

Идентификатор преобразования transform_i имеет тип данных string.

В таблице 38 указаны параметры в теле HTTP-запроса.

Следующий запрос создает задание преобразования с идентификатором sample:

PUT _plugins/_transform/sample
{
"transform": {
"enabled": true,
"continuous": true,
"schedule": {
"interval": {
"period": 1,
"unit": "Minutes",
"start_time": 1602100553
}
},
"description": "Sample transform job",
"source_index": "sample_index",
"target_index": "sample_target",
"data_selection_query": {
"match_all": {}
},
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
}

Пример ответа:

{
"_id": "sample",
"_version": 7,
"_seq_no": 13,
"_primary_term": 1,
"transform": {
"transform_id": "sample",
"schema_version": 7,
"continuous": true,
"schedule": {
"interval": {
"start_time": 1621467964243,
"period": 1,
"unit": "Minutes"
}
},
"metadata_id": null,
"updated_at": 1621467964243,
"enabled": true,
"enabled_at": 1621467964243,
"description": "Sample transform job",
"source_index": "sample_index",
"data_selection_query": {
"match_all": {
"boost": 1.0
}
},
"target_index": "sample_target",
"roles": [],
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
}

Обновление задания преобразования

Операция обновляет задание преобразования, если transform_id уже существует. Для этого запроса необходимо указать порядковый номер и основной термин обновляемого преобразования. Чтобы получить их, используют вызов API "Получить сведения о задании преобразования".

Формат запроса

PUT _plugins/_transform/<transform_id>?if_seq_no=<seq_no>&if_primary_term=<primary_term>

Операция обновления поддерживает параметры запроса из таблицы 39.

Поля тела запроса для обновления приведены в таблицу 40.

Следующий запрос обновляет задание преобразования с идентификатором sample, порядковым номером 13 и основным термином 1:

PUT _plugins/_transform/sample?if_seq_no=13&if_primary_term=1
{
"transform": {
"enabled": true,
"schedule": {
"interval": {
"period": 1,
"unit": "Minutes",
"start_time": 1602100553
}
},
"description": "Sample transform job",
"source_index": "sample_index",
"target_index": "sample_target",
"data_selection_query": {
"match_all": {}
},
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
}

Пример ответа:

PUT _plugins/_transform/sample?if_seq_no=13&if_primary_term=1
{
"transform": {
"enabled": true,
"schedule": {
"interval": {
"period": 1,
"unit": "Minutes",
"start_time": 1602100553
}
},
"description": "Sample transform job",
"source_index": "sample_index",
"target_index": "sample_target",
"data_selection_query": {
"match_all": {}
},
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
}

Получение подробной информации о задании преобразования

Операция возвращает сведения о задании преобразования.

Формат запроса

GET _plugins/_transform/<transform_id>

Следующий запрос возвращает сведения о задании преобразования с идентификатором sample:

GET _plugins/_transform/sample

Пример ответа:

{
"_id": "sample",
"_version": 7,
"_seq_no": 13,
"_primary_term": 1,
"transform": {
"transform_id": "sample",
"schema_version": 7,
"continuous": true,
"schedule": {
"interval": {
"start_time": 1621467964243,
"period": 1,
"unit": "Minutes"
}
},
"metadata_id": null,
"updated_at": 1621467964243,
"enabled": true,
"enabled_at": 1621467964243,
"description": "Sample transform job",
"source_index": "sample_index",
"data_selection_query": {
"match_all": {
"boost": 1.0
}
},
"target_index": "sample_target",
"roles": [],
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
}

Также можно получить подробную информацию обо всех заданиях преобразования, опустив transform_id.

В таблице 41 указана параметры запроса операции GET API для фильтрации результатов.

Следующий запрос возвращает два результата, начиная с преобразования 8:

GET _plugins/_transform?size=2&from=8

Пример ответа:

{
"total_transforms": 18,
"transforms": [
{
"_id": "sample8",
"_seq_no": 93,
"_primary_term": 1,
"transform": {
"transform_id": "sample8",
"schema_version": 7,
"schedule": {
"interval": {
"start_time": 1622063596812,
"period": 1,
"unit": "Minutes"
}
},
"metadata_id": "y4hFAB2ZURQ2dzY7BAMxWA",
"updated_at": 1622063657233,
"enabled": false,
"enabled_at": null,
"description": "Sample transform job",
"source_index": "sample_index3",
"data_selection_query": {
"match_all": {
"boost": 1.0
}
},
"target_index": "sample_target3",
"roles": [],
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
},
{
"_id": "sample9",
"_seq_no": 98,
"_primary_term": 1,
"transform": {
"transform_id": "sample9",
"schema_version": 7,
"schedule": {
"interval": {
"start_time": 1622063598065,
"period": 1,
"unit": "Minutes"
}
},
"metadata_id": "x8tCIiYMTE3veSbIJkit5A",
"updated_at": 1622063658388,
"enabled": false,
"enabled_at": null,
"description": "Sample transform job",
"source_index": "sample_index4",
"data_selection_query": {
"match_all": {
"boost": 1.0
}
},
"target_index": "sample_target4",
"roles": [],
"page_size": 1,
"groups": [
{
"terms": {
"source_field": "customer_gender",
"target_field": "gender"
}
},
{
"terms": {
"source_field": "day_of_week",
"target_field": "day"
}
}
],
"aggregations": {
"quantity": {
"sum": {
"field": "total_quantity"
}
}
}
}
}
]
}