Вопрос или проблема
Моя задача — установить и настроить Telegraf примерно на 20 Windows серверах в так называемой «Безопасной зоне», открыть метрики на http-порту каждого сервера, чтобы их считывал Telegraf, работающий на машине в «Пограничной зоне», и открывать объединенный поток на его http-порту для сбора Prometheus, работающим «где-то там», за границей.
-
Возможно ли это вообще?
-
Разумно ли это, или есть лучшее решение?
-
Стоит ли использовать плагин inputs.http на «Центральном Telegraf»?
-
Я вижу имя хоста в потоке каждой машины. Сможет ли Prometheus правильно связать метрики с конкретным источником, основываясь на этих именах хостов?
-
Я слышал о каком-то автообнаружении.
Можно ли, вместо жесткого кодирования всех входящих URL, просто указать подсеть/маску и позволить Telegraf обнаруживать все слушающие порты 9273 на ней?
Пока что этот «Центральный Telegraf» открывает только собственные метрики, хотя я добавил несколько URL в [[inputs.http]], проверил, что все URL доступны из Центрального, прошел проверку синтаксиса –test и перезапустил сервис Windows. Все еще вижу только локальные метрики на TCP 9273 у “Центрального Telegraf”.
Спасибо, Андрей
Ответ или решение
Уважаемый Андрей,
Ваш вопрос затрагивает комплексную задачу по сбору и агрегированию метрик в безопасной зоне с использованием Telegraf и Prometheus, и я постараюсь ответить на каждую составляющую вашего вопроса, предоставив теоретическую основу, примеры, а также применимость решений в вашем конкретном случае.
1. Возможность реализации:
Теория: Да, собрать метрики с помощью Telegraf с нескольких серверов и агрегировать их в пограничной зоне для последующего сбора Prometheus возможно. Эта архитектура типична для среды с жесткими требованиями безопасности, где границы зон разделяются для минимизации рисков.
Пример: Пользователь может установить Telegraf на каждом сервере в безопасной зоне, слушая метрики на HTTP-порте, скажем, 9273. Затем, при помощи центрального инстанса Telegraf в пограничной зоне, вы можете агрегаировать эти метрики и предоставить доступ Prometheus для сбора.
Применение: Вам необходимо настроить Telegraf в пограничной зоне с использованием входного плагина inputs.http для получения данных с HTTP-портов серверов в безопасной зоне. Это позволит сконцентрировать данные в одном потоке, который может быть обработан Prometheus.
2. Разумность решения или альтернатива:
Теория: Предложенное вами решение вполне разумно, однако существуют и альтернативные подходы, такие как использование агента Prometheus, но это требует прямого доступа к серверам, что может быть не безопасно в вашей ситуации.
Пример: Использование агента Prometheus для прямого сбора метрик исключает слой Telegraf в пограничной зоне, но требует доверенной сетевой среды между серверами.
Применение: Учитывая, что ваша задача подразумевает границы зон, использование Telegraf в качестве посредника обеспечивает дополнительный уровень безопасности и гибкость в управлении метриками.
3. Использование плагина inputs.http:
Теория: Плагин inputs.http в Telegraf предназначен для сбора данных через HTTP запросы. Это позволяет централизации метрик, получаемых с разных источников.
Пример: Настройте ваш центральный Telegraf для многократных inputs.http источников, указывая URL каждого сервера в безопасной зоне, например, http://servername:9273/metrics.
Применение: Убедитесь в правильности настроек каждой конфигурации URL и тестируйте их доступность перед развертыванием в производственной среде. Например, используйте команду curl для проверки каждого источника.
4. Вопросы атрибуции для Prometheus:
Теория: Prometheus способен различать и правильно атрибутировать метрики при условии, что каждая метрика содержит уникальные идентификаторы, такие как hostname или иной идентификатор инстанса.
Пример: Параметры, включенные в метрику, например, instance="yourserver:9273", позволяют Prometheus корректно распределять данные по источникам.
Применение: Убедитесь, что каждое приложение на Telegraf в безопасной зоне правильно конфигурировано для предоставления hostname или иного уникального маркера.
5. Возможности автообнаружения:
Теория: Теоретически возможно автоматическое обнаружение сервисов, однако в контексте Telegraf и Prometheus данная функциональность может частично отсутствовать и требовать дополнительных настроек или внешних решений.
Пример: В некоторых инструментах для мониторинга существуют модули для автообнаружения, но они часто сложны в настройке и могут не поддерживаться в стандартных конфигурациях Telegraf.
Применение: В условиях безопасности лучше вручную настроить список серверов, избегая автоматизированных решений, чтобы минимизировать уязвимости и исключить потерю контроля над связью с серверами.
Подведем итог: ваша задача реализуема и соответствует распространенной архитектуре, используемой для разделения безопасных и небезопасных зон. Правильная конфигурация центрального Telegraf и защита каналов связи обеспечат успешную агрегацию метрик для дальнейшего анализа с помощью Prometheus. Если у вас возникнут дополнительные вопросы, всегда полезно обратиться к официальной документации или опытному консультанту по сетевой безопасности и мониторингу.
С уважением,
[Ваше Имя]
IT-эксперт