Экспортеры
Рекомендуется использовать Metricbeat для сбора и отправки данных мониторинга в кластер мониторинга.
Если вы ранее настраивали методы сбора устаревшего типа, вам следует перейти на методы сбора с использованием Metricbeat. Используйте либо методы сбора Metricbeat, либо устаревшие методы сбора; не используйте оба способа одновременно.
Дополнительную информацию см. в разделе Сбор данных мониторинга с помощью Metricbeat.
Экспортеры предназначены для получения данных, собранных из любого источника Elastic Stack, и перенаправления их в кластер мониторинга. Можно настроить несколько экспортеров, но стандартная и рекомендуемая настройка — использование одного экспортера.
В Elasticsearch существуют два типа экспортеров:
-
local - По умолчанию используется экспортер Elasticsearch для мониторинга. Этот экспортер направляет данные обратно в тот же кластер. См. Локальные экспортеры.
-
http - Предпочтительный экспортер, который можно использовать для перенаправления данных в любой поддерживаемый кластер Elasticsearch, доступный по протоколу HTTP. В производственных средах всегда следует использовать отдельный кластер мониторинга. См. HTTP-экспортеры.
Оба экспортера выполняют одинаковую задачу: настройка кластера мониторинга и перенаправление данных мониторинга. Однако они выполняют эти задачи по-разному. Несмотря на разницу в способах работы, оба экспортера могут отправлять все те же данные.
Экспортеры можно настраивать на уровне узла и кластера. Параметры кластера, обновляемые с помощью _cluster/settings API, имеют приоритет над параметрами в файле elasticsearch.yml на каждом узле. При обновлении экспортера он полностью заменяется обновлённой версией.
Крайне важно, чтобы на всех узлах была одинаковая настройка. В противном случае данные мониторинга могут перенаправляться разными способами или в разные места.
При перенаправлении данных мониторинга в кластер мониторинга экспортеры используют _bulk индексирование для повышения производительности. Все данные мониторинга отправляются оптом всем включённым экспортерам на одном узле. Затем экспортеры сериализуют данные мониторинга и отправляют пакетный запрос в кластер мониторинга. Очередей — ни в памяти, ни на диске — нет, поэтому любая ошибка во время экспорта приводит к потере этой партии данных мониторинга. Такая конструкция минимизирует влияние на Elasticsearch, и предполагается, что следующий запрос будет успешным.
Перенаправление данных мониторинга включает их индексирование в соответствующие индексы мониторинга. После индексирования данные хранятся в индексе мониторинга, который по умолчанию имеет ежедневную структуру индекса. Для данных мониторинга Elasticsearch это индекс, соответствующий .monitoring-es-6-*. Далее данные находятся в кластере мониторинга и должны управляться или очищаться по мере необходимости. Если вы не будете управлять данными мониторинга, они в конечном итоге заполнят узлы, и кластер может выйти из строя из-за нехватки дискового пространства.
Сильно рекомендуется управлять очисткой индексов, особенно индексов мониторинга. Для этого можно воспользоваться сервисом очистки или Elastic Curator.
Также существует дисковое пороговое значение (также известное как пороговое значение «затопления»), которое защищает кластеры от исчерпания дискового пространства. Когда эта функция срабатывает, все индексы (включая индексы мониторинга) становятся только для чтения, пока проблема не будет решена, и пользователь вручную не сделает индекс доступным для записи. Пока активный индекс мониторинга только для чтения, он естественным образом не сможет записать новые данные и будет постоянно регистрировать ошибки, свидетельствующие об отказе записи. Дополнительную информацию см. в разделе Параметры распределения фрагментов на основе диска.
Экспортеры по умолчанию
Если узел или кластер не определяют экспортер явно, используется следующий экспортер по умолчанию:
xpack.monitoring.exporters.default_local: type: local
| Имя экспортера однозначно определяет его, но в остальном не используется. При указании собственных экспортеров вам не нужно явно перезаписывать или ссылаться на |
Если другой экспортер уже определён, экспортер по умолчанию не создаётся. При определении нового экспортера, если экспортер по умолчанию существует, он автоматически удаляется.
Шаблоны экспортеров и конвейеры ingest
Прежде чем экспортеры смогут перенаправлять данные мониторинга, они должны настроить определённые ресурсы Elasticsearch. К таким ресурсам относятся шаблоны и конвейеры ingest. В следующей таблице перечислены шаблоны, которые необходимы для перенаправления данных мониторинга экспортером:
| Шаблон | Назначение |
|---|---|
| Все оповещения кластера для данных мониторинга. |
| Все данные мониторинга Beats. |
| Все данные мониторинга Elasticsearch. |
| Все данные мониторинга Kibana. |
| Все данные мониторинга Logstash. |
Шаблоны — это обычные шаблоны Elasticsearch, которые контролируют параметры по умолчанию и сопоставления для индексов мониторинга.
По умолчанию индексы мониторинга создаются ежедневно (например, .monitoring-es-6-2017.08.26). Вы можете изменить суффикс даты по умолчанию для индексов мониторинга с помощью параметра index.name.time_format. Этот параметр позволяет контролировать частоту создания индексов мониторинга определённым экспортером http. Этот параметр нельзя использовать с экспортерами local. Дополнительную информацию см. в разделе Настройки HTTP-экспортера.
Некоторые пользователи создают собственные шаблоны, которые соответствуют всем шаблонам индексов, что, следовательно, влияет на создаваемые индексы мониторинга. Важно не отключать хранение _source для индексов мониторинга. В противном случае функции мониторинга Kibana не будут работать, и вы не сможете визуализировать данные мониторинга для вашего кластера.
В следующей таблице перечислены конвейеры ingest, необходимые экспортеру для перенаправления данных мониторинга:
| Конвейер | Назначение |
|---|---|
| Обновляет данные мониторинга X-Pack, поступающие от X-Pack 5.0 - 5.4, для совместимости с форматом, используемым функциями мониторинга 5.5. |
| Пустой конвейер. |
Экспортеры выполняют настройку этих ресурсов, прежде чем отправлять данные. Если установка ресурсов завершится ошибкой (например, из-за ограничений доступа), данные не отправляются, и регистрируются предупреждения.
Пустые конвейеры оцениваются на координационном узле во время индексирования и игнорируются без дополнительных усилий. Это делает их безопасной и бессмысленной операцией.
Для кластеров мониторинга, на всех узлах которых отключена функция node.ingest, можно отключить использование конвейеров ingest. Однако это блокирует его предназначение — обновлять устаревшие данные мониторинга по мере улучшения наших сопоставлений со временем. Начиная с 6.0, конвейеры ingest являются обязательными для кластера мониторинга; вам необходимо включить node.ingest хотя бы на одном узле.
После того, как любой узел, работающий под управлением 5.5 или более поздней версии, настроил шаблоны и конвейеры ingest в кластере мониторинга, для просмотра всех последующих данных в кластере мониторинга необходимо использовать Kibana 5.5 или более поздней версии. Проще всего определить, произошла ли эта обновление, проверив наличие индексов, соответствующих .monitoring-es-6-* (или, точнее, наличие нового конвейера). Версии до 5.5 использовали .monitoring-es-2-*.
Каждый созданный экспортером ресурс имеет поле version, которое используется для определения необходимости замены ресурса. Значение поля version представляет самую последнюю версию функций мониторинга, которые изменили ресурс. Если ресурс был отредактирован кем-то или чем-то помимо функций мониторинга, эти изменения будут потеряны при следующем автоматическом обновлении.
© 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/7.17/es-monitoring-exporters.html
