В версии Elastic Stack 6.3.0 были внесены некоторые критические изменения , особенно в том, как Beats отправляет имя хоста. Если раньше это было только простое поле host, содержащее имя хоста, то начиная с 6.3.0 оно стало сложным полем с вложенными свойствами. Имя теперь хранится в host.name.
Страница критических изменений содержит инструкции по переходу на Elastic Common Schema, в зависимости от того, как вы в настоящее время управляете своими индексами. При использовании версионных индексов (содержащих версию Beats), на самом деле ничего не нужно менять . Каждый индекс всегда будет содержать только одно отображение для свойства host, и нет конфликтов отображения.
Вариант использования: Вы используете шаблон индекса Beats и версионные индексы
В этом случае вы загружаете версионный шаблон вручную и используете шаблон индекса версионности Beats, %{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}, как рекомендовано в документации по входному плагину Beats. В результате получается поле host с индексами 6,2 и поле host.name с индексами 6,3. Нет конфликтов сопоставления, но любые визуализации или поиски, использующие host, больше не будут показывать результаты для индексов 6.3.
Что нужно изменить?
Если вы искали поле хоста ранее, измените результаты поиска, чтобы использовать вместо него поле beat.hostname. Поле beat.hostname существовало до 6.3 и содержит ту же информацию, что и host.name. Использование этого поля гарантирует, что ваши запросы и агрегаты будут работать так, как ожидалось в более ранних выпусках и 6.3.
Проблемы возникают, когда у вас есть шаблон индекса, который охватывает несколько индексов (например, filebeat-*). Кибана будет жаловаться на конфликтующие сопоставления для поля host. Одним из решений было бы использование разных шаблонов индексов для каждой отдельной версии входного сигнала, но это становится громоздким для многих различных версий. Кроме того, это делает анализ / поиск по различным индексам трудным / невозможным (например, панели управления Kibana).
Конечно, если у вас нет доступа к полю host в вашей визуализации или панели мониторинга, все будет работать так, как ожидалось. Но мой внутренний OCD вызван предупреждением о конфликте карт в диалоге настроек. Кроме того, становится сложнее видеть, существуют ли реальные конфликты отображения. В основном то же самое, если у вас есть один неудачный тест, который вы не исправите - вы не будете обращать внимание на новые неудачные тесты, потому что «результат всегда был красным».
Итак, какова стратегия перехода на существующие индексы для соответствия новому формату отображения? Создание новых индексов и использование переиндексации API Elasticsearch? Какими должны быть названы новые индексы, другими словами: какой номер версии они должны получить? Какова лучшая практика здесь? Или это то, что я просто должен игнорировать?