0. Фон

Недавно я использовал PushGateway (далее PGW) для мониторинга доступа к компонентам потоковой обработки. В результате я столкнулся с множеством подводных камней, поэтому хотел бы поделиться ими здесь.

1. Зачем нажимать (PGW)

Предыдущая реализация извлечения, то есть раскрытие сервисного порта в процессе, следовала протоколу Prometheus (далее именуемому Prom) и позволяла Prom извлекать данные.

Но есть проблема, порт нужно выделить. Наша команда раньше использовала множество проблемных реализаций: распределенные блокировки, хранилище с несколькими состояниями и т. д. Но ей по-прежнему не удается избежать проблем с утечкой портов и непроизводительным использованием (механизм топологической высокой доступности заставит его переключаться между разными машинами, поэтому прежде чем назначенный порт машины бесполезен). Хотя мы также можем отслеживать жизненный цикл топологии, это непросто — в более крупных сценариях топология уровня k является нормальной, но эффективно отслеживать жизненный цикл топологии уровня k, похоже, является большой проблемой.

Мои коллеги сказали мне, что k8s, возможно, сможет решить мою проблему, и я постараюсь следить за внедрением этого технологического стека в будущем.

Мы просто хотим реализовать мониторинг и не хотим беспокоиться о других вещах.

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

В конце концов, push требует, чтобы отслеживаемый сервис знал адрес системы мониторинга, поэтому эту информацию необходимо установить в отслеживаемом сервисе. Таким образом, отслеживаемая служба будет в определенной степени зависеть от службы мониторинга; в то время как pull требует, чтобы система мониторинга знала адреса всех отслеживаемых служб, поэтому для каждой дополнительной отслеживаемой службы служба мониторинга должна распознавать ее с помощью некоторых средств, например в качестве поддержки prom. Целевая служба динамически получается из системы обнаружения служб, а flink поддерживает использование диапазона портов для подтверждения местоположения отслеживаемой службы.

Что касается сравнения других моделей push и poll, мы можем проверить таблицу ниже и провести сравнения в соответствии с нашими собственными сценариями:

На официальном сайте Прома также сообщается, что PGW не применим в большинстве случаев, за исключением:

Usually, the only valid use case for the Pushgateway is for capturing the outcome of a service-level batch job. A "service-level" batch job is one which is not semantically related to a specific machine or job instance (for example, a batch job that deletes a number of users for an entire service). Such a job's metrics should not include a machine or instance label to decouple the lifecycle of specific machines or instances from the pushed metrics. This decreases the burden for managing stale metrics in the Pushgateway. See also the best practices for monitoring batch jobs.

существоватьbest practicse for monitoring batch jobsсередина,Также упоминалось:

There is a fuzzy line between offline-processing and batch jobs, as offline processing may be done in batch jobs. Batch jobs are distinguished by the fact that they do not run continuously, which makes scraping them difficult.

В репозиторий GitHub включено следующее введение:

The Prometheus Pushgateway exists to allow ephemeral and batch jobs to expose their metrics to Prometheus. Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway. The Pushgateway then exposes these metrics to Prometheus.

мое делосистемасуществуетephemeral job(mean the jobs may not exist long enough)Это тоже мой выборPGWважные причины。

2. На какие ловушки вы наступили?

После первоначального подключения к PGW,Все необходимые данные имеются. В результате студенты-испытатели обнаружили, что данные внезапно исчезли во время теста.,я взглянул,Создано большое количество топологий для потоковых задач.,PGW уволился напрямую,В журнале естьout of memoryслова。

После еще двух тестов я обнаружил, что по мере увеличения топологии PGW потребляет все больше памяти и процессора.

Потом я вспомнил, что говорилось на официальном сайте:

The Pushgateway never forgets series pushed to it and will expose them to Prometheus forever unless those series are manually deleted via the Pushgateway's API.

Но я это четко настроилdeleteOnShutdown Эта конфигурация,Объяснение на официальном сайте есть.：Specifies whether to delete metrics from the PushGateway on shutdown.,Но когда я повторно запускаю PGW,Я обнаружил, что соответствующие показатели не были удалены!

Наша команда прошла поиск,Нашел одинIssue：issues.apache.org/jira/browse…

Некоторые думают, что PGW должен использовать TTL, но PGW считает, что это не очень хороший метод. И я думаю, что это то, что Flink должен исправить. Я не знаю, почему это не было исправлено, и в официальной документации сайта нет упоминания об этой ошибке.

Я отправил исправление к документации Flink.,Я надеюсь, что смогу присоединиться как можно скорее——github.com/apache/flin…

3. Резюме

В этой статье рассказывается о подводных камнях, с которыми столкнулась наша команда при объединении PushGateway с Flink, и обсуждается наше первоначальное намерение выбрать PGW. После этого я планирую обратить внимание на InfluxDB и использовать его как пуш-энд для замены PGW. Еще я заметил, что экология новой версии InfluxDB тоже неплохая. В ней есть панели, визуализация данных и сигналы тревоги. простая база данных временных рядов в сочетании с собственной экологией будет становиться все более похожей на prom+grafana.

3.1 Ссылки

• blog.sflow.com/2012/08/pus…
• prometheus.io/docs/practi…
• prometheus.io/docs/practi…
• ci.apache.org/projects/fl…