Экспортеры
Elastic Agent и Metricbeat рекомендуются для сбора и отправки данных мониторинга в кластер мониторинга.
Если вы ранее настраивали методы сбора устаревшего типа, перейдите к использованию Elastic Agent или 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/8.17/es-monitoring-exporters.html