› › ›

Взрыв карты

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

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

API CAT nodes показывает высокую нагрузку на кучу или процессор на основном узле и/или узлах, на которых размещены фрагменты индексов. Это потенциально может привести к временной неотзывчивости узла и/или перегрузке.
API CAT tasks показывает длительные продолжительности поиска, относящиеся только к этому индексу или индексам, даже при простых запросах.
API CAT tasks показывает длительные продолжительности индексирования, относящиеся только к этому индексу или индексам. Это обычно связано с задачами в ожидании, пока координационный узел ожидает подтверждения от всех остальных узлов о выполнении запроса на обновление карты.
Загрузка страницы Поля с подстановкой или команды обновления страницы в Dev Tools в Kibana занимают много времени (более 10 секунд) или вызывают таймаут в вкладке «Сеть» инструментов разработчика браузера. Дополнительную информацию можно найти в нашей статье по устранению неполадок в Discover.
Сбор данных Доступные поля в Kibana занимает много времени для компиляции JavaScript в вкладке «Производительность» инструментов разработчика браузера. Это потенциально может привести к временной неотзывчивости страницы браузера.
Уведомления или правила безопасности Kibana могут выдавать ошибки The content length (X) is bigger than the maximum allowed string (Y), где X — это передаваемая нагрузка, а Y — предел загрузки Kibana server-maxPayload.
Длительные периоды запуска Elasticsearch.

Предотвращение или подготовка

Карты нельзя уменьшать после их инициализации. Индексы Elasticsearch по умолчанию используют динамические карты, что обычно не вызывает проблем, если не сочетается с переопределением index.mapping.total_fields.limit.

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

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

Установите index.mapping.total_fields.ignore_dynamic_beyond_limit на true. Вместо отклонения документов, превышающих лимит полей, это будет игнорировать динамические поля, как только лимит будет достигнут.
Используйте тип данных уплощенные. Обратите внимание, что уплощенные объекты еще не полностью поддерживаются в Kibana. Например, это может относиться к подкартам, таким как { host.name , host.os, host.version }. Необходимые поля по-прежнему доступны через поля в реальном времени.
Отключите динамическое сопоставление. Это не повлияет на текущую карту индекса, но может применяться в будущем с помощью шаблонов индексов.

Изменение на тип данных вложенные не решит основную проблему.

Проверка проблемы

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

Проверьте журналы кластера Elasticsearch на наличие ошибок Limit of total fields [X] in index [Y] has been exceeded, где X — значение index.mapping.total_fields.limit, а Y — ваш индекс. Соответствующая ошибка в журнале приема данных будет Limit of total fields [X] has been exceeded while adding new fields [Z], где Z — добавляемые новые поля.
Для полей верхнего уровня запросите возможности полей fields=*.
Ищите "type" в выводе API получения карты.

Если вы хотите использовать сторонний инструмент JQ, вы можете обработать вывод API получения карты mapping.json.

$ cat mapping.json | jq -c 'to_entries[]| .key as $index| [.value.mappings| to_entries[]|select(.key=="properties") | {(.key):([.value|..|.type?|select(.!=null)]|length)}]| map(to_entries)| flatten| from_entries| ([to_entries[].value]|add)| {index: $index, field_count: .}'

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

Сложные взрывы

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

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

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

Если проблема проявляется только в представлении данных, можно рассмотреть фильтры полей, если вы не используете множественные поля. В качестве альтернативы, можно рассмотреть более целевой шаблон индекса или использовать отрицательный шаблон для фильтрации проблемных индексов. Например, если у logs-* слишком высокое количество полей из-за проблемных вспомогательных индексов logs-lotsOfFields-*, вы можете обновить либо на logs-*,-logs-lotsOfFields-*, либо на logs-iMeantThisAnyway-*.

Решение

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

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

Разделение индекса не решит основную проблему.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/8.17/mapping-explosion.html