Comments 21
Не сочтите за невежество, но Consul нужно выкатывать по всей инфре с агентом на каждой ноде, всё остальное — негуманный анти-паттерн. Consul для такого не предназначен и даже небольшая часть его потенциала не может быть реализована (конечно, возможно его использование в качестве распределенного KV-хранилища или механизма для распределённых локов, но моё субъективное мнение — в таком случае лучше взять etcd). Имея Consul на всём флоте, не нужно будет писать свои решения, можно использовать стандартные и существующие из коробки service definitions с healthcheck'aми и прочими радостями. При таком подходе на Consul можно строить что угодно, хоть DNS для инфры (для кэша лучше взять что-нибудь отдельное спереди, дабы не нагружать Consul-сервера и не вешать их на 53-й порт), хоть RR-балансировку (я, например, так обеспечиваю HA для куберовских kube-apiserver). C queries вообще можно реализовывать ещё более интересные вещи, я делал возможность через DNS получить текущего PostgreSQL-мастера в кластере Patroni.
Плюс, учитывая что у Prometheus есть конвенция, что метрики обычно отдаются по пути /metrics, я в SD просто забираю все сервисы, у которых есть тэг scrapable, и ставлю в значение job-лейбла имя сервиса через обычный релэйблинг. Одним job_name сразу всех зайцев, эдакий DRY.
Такого рода комментарий был самым ожидаемым при написании статьи. Я описал именно опытное решение, которое позволило в минимум телодвижений организовать удобный service discovery в Prometheus — «20% усилий дают 80% результата».
У меня сохраняется уверенность что такое же «местечковое» применение Consul было и есть не только у меня в инфраструктуре — когда Consul запускается чтобы решить конкретную задачу, типо кластеризации Traefik. В итоге этот же инстанс легко обрел дополнительный функционал в роли service discovery для Prometheus.
Пока статью писал задумался — почему бы и в правду не попробовать Consul на всю катушку. И сейчас анализирую рентабельность его применения.
Очень рекомендую, я тоже изначально в некотором роде следовал принципу Парето — нужно было что-то для организации динамического автоконфигурируемого DNS для VPC, взял Consul. После того как начал знакомиться с ним ближе, просто был ошарашен насколько продуманно он сделан и какой пласт задач способен решать. Не зря всё-таки в нашей индустрии вокруг HashiCorp сложился в некотором роде культ, они делают нереально крутые вещи.
Мы начали работать непосредственно с hashicorp
Я правильно понимаю, что у вас Consul Enterprise с честным суппортом? Если нет, то поделитесь пожалуйста issue на GitHub, очень интересно посмотреть на кейс, у меня разваливался консенсус серверов пару раз, но чтобы Raft наедался, такого не было.
А вот дальше самое инстересное – Prometheus очень любит RAM и CPU, так устроена его TSDB. Про это много в интернете написано.
Вопрос насчет того сколько он мониторит нод ставится неправильно. Prometheus собирается метрики с сервисов и так как делает это pull-моделью получается заодно мониторинг. Именно от количества метрик зависит насколько Prometheus будет загружен. Сервис может аккуратно отдавать 20-30 полезных и нужных метрик, а может 100-500 (Spring Boot Actuator) строк среди которых нужные только 20-30, но заберет по-умолчанию Prometheus все что есть в `/metrics`. Так что нагрузка на Prometheus зависит от большого количества факторов.
Теперь как сделал я – размазал нагрузку по нескольким Prometheus, а если точно по 2 в каждом окружении dev, test, prod. По 1-му в каждом Kubernetes кластере, который собирает метрики только того что живет в K8S(на CephFS) и еще по одному «инфраструктурному» Prometheus, который через Federation смотрит на Prometheus в K8S. Дополнительно все «инфраструктурные» Prometheus смотрят на `/metrics` друг на друга и обеспечивают кросс-мониторинг.
Grafana работает только с «инфраструктурными» Prometheus, а Federation позволяет при этом видеть и то что в K8S. А так же в Grafana заведены панели отвечающие за кросс-мониторинг всех инстансов Prometheus и если что то упадет, о проблеме становится известно.
Федерация — не самый оптимальный механизм агрегирования метрик. Лучше брать специализированное решение, я например в качестве "апстрима" для куберовских промов беру VictoriaMetrics, хотя там сейчас полно всякого, те же Thanos, Cortex и M3.
Кросс-мониторинг интересно, я обхожусь обычным watchdog (вечно файрящий алерт, отсутствие которого как раз и говорит что что-то не так). Есть ли у кросс-мониторинга какие-то скрытые плюсы? Watchdog кроме своей основной задачи ничего по сути и не умеет, но в целом здесь больше ничего и не надо.
Федерация — не самый оптимальный механизм агрегирования метрик.
Federation очень удобное и нативное решение, позволяющее горизонтально размазывать нагрузку на Prometheus, и в хранении и в выполнении запросов. Это же и можно считать базовым решением горизонтального масштабирования.
А вот насчёт внешних хранилищ, по имеющимся issue они сырые и есть ещё "детские болячки".
Присматриваемся к VictoriaMetrics, развивается отлично, но в архитектуре есть вещи которые смущают.
Есть ли у кросс-мониторинга какие-то скрытые плюсы?
Так как это Prometheus, то это не просто мониторинг, это сбор метрик. Инстансы перекрёстно собирают друг с друга метрики и анализ этих метрик превентивный. Prometheus и сам с себя может метрики собирать, но это как минимум странно и точно не надежно, в случае "ресурсного шторма".
А вот насчёт внешних хранилищ, по имеющимся issue они сырые и есть ещё «детские болячки».
Присматриваемся к VictoriaMetrics, развивается отлично, но в архитектуре есть вещи которые смущают.
Укажите пожалуйста, что именно вас не устраивает и что печалит?
К тому же чаты с разработчиками всегда открыт для идей и замечаний, ровно как и их гитхаб.
Вот телеграм — t.me/VictoriaMetrics_ru1
Если пройтись именно по issue, то особенно печалят:
И подобных багов достаточно много. Те что я привел свежие, а если смотреть всю историю багов, то появляются мысли о «сырости» продукта.
Анализируя все что описал, желание использовать VictoriaMetrics не пропадает, но как и с MS продуктами, вышел релиз, дождись SP1 и можно использовать, я бы подождал следующего major-релиза.
Первое что смущает именно архитектурно — это размазывание мониторинга по множеству сервисов. По мне, так мониторинг должен быть максимально надежным. А проще всего обеспечивать надежную работу сервиса(Prometheus) когда минимум компонентов.
У VictoriaMetrics есть single-node версия и кластерная версия. Single-node версия запускается из одного бинарника. Она включает в себя функциональность всех компонентов кластерной версии — vminsert, vmselect и vmstorage. Также она включает в себя функциональность vmagent по сбору Prometheus-compatible метрик (т.е. ей можно передать конфиг прометеуса в параметре -promscrape.config, чтобы заменить функциональность прометеуса для сбора метрик — см. эту документацию ). В будущем планируется интегрировать туда фукнциональность vmalert.
Если пройтись именно по issue, то особенно печалят:
- Data lost when one of HA prometheus shutdown
- VM count differs from prometheus
Если внимательно прочесть переписку по этим issues, то можно заметить, что там описываются специфические случаи использования VictoriaMetrics, которые решаются путем перезапуска VictoriaMetrics с правильным набором аргументов командной строки.
И подобных багов достаточно много
Хотелось бы увидеть ссылки на баги, чтобы не быть голословным.
Анализируя все что описал, желание использовать VictoriaMetrics не пропадает, но как и с MS продуктами, вышел релиз, дождись SP1 и можно использовать, я бы подождал следующего major-релиза.
Это не совсем правильная стратегия, т.к. в major-релизах обычно добавляется какая-нибудь новая функциональность, которая может что-нибудь поломать. Поэтому правильнее обновляться при выходе minor-релизов, т.к. в них обычно исправляются баги и вносятся мелкие улучшения, которые вряд ли что-то могут поломать.
Продублирую ссылку на всю историю багов из прошлого комментария, так как она похоже осталась незамеченной.
Активная разработка VictoriaMetrics ведется около года, примерно с мая-июня 2019, а зарегистрированных issue с лейблом «bug» больше 100. При этом продукт ничего нового не реализует, просто копирует и пересматривается подход в уже существующем Prometheus, а так же некие слои интеграции с другими TSDB.
Вот именно эта статистика пока и не очень двигает на уверенность что продукт «готов».
И да, согласен major-релиз в правилах SemVer 2.0 именно про новый функционал. Но акценты как раз был указан в «дождись SP1».
У VictoriaMetrics «некий SP1» я пока не наблюдаю. А вот как раз минорные релизы от версии к версии лишь добавляют все новый и новый функционал и потому надеюсь что они как-то зафиксируют фичи достигнув major-релиза и сосредоточатся на стабильности продукта.
В любом случае к людям, которые пишут Open Source, расходуя на это личное время, огромнейший респект всегда.
Продублирую ссылку на всю историю багов из прошлого комментария, так как она похоже осталась незамеченной.
Активная разработка VictoriaMetrics ведется около года, примерно с мая-июня 2019, а зарегистрированных issue с лейблом «bug» больше 100. При этом продукт ничего нового не реализует, просто копирует и пересматривается подход в уже существующем Prometheus, а так же некие слои интеграции с другими TSDB.
Вот именно эта статистика пока и не очень двигает на уверенность что продукт «готов».
В целом согласен с этими пояснениями. Есть несколько замечаний:
VictoriaMetrics активно разрабатывается с января 2018 года. Первый публичный анонс был осенью 2018 года. В мае 2019 года были открыты исходники.
Количество закрытых багов за год не говорит о качестве продукта. Оно может говорить только о нарастающей популярности продукта — люди находят баги в corner cases, а также о том, что VictoriaMetrics разрабатывается "в открытую" без попыток скрыть баги.
Если бы количество багов в проекте указывало на нестабильность продукта, то я сомневаюсь, что вы бы пользовались Consul'ом с более 3000 закрытых багов и более 500 открытых багов или Prometheus'ом с 3000 закрытых багов и более 250 открытых багов.
По поводу стабильности продукта советую ознакомиться с отзывами пользователей VictoriaMetrics.
Тоже смотрел в свое время на автодисковери Прометея в связке с консулом.
Сам Прометей с консулом работают в кубере, оттуда же же идёт скан портов на предмет экспортеров.
Не идеально но с задачей справляется, а главное без баш скриптов
https://github.com/nevidanniu/promenad
Посмотрел. Интересное решение, но моим требованиям автоматизации совсем не отвечает и скорее даже противоречит:
- Централизованное решения
- Вынесение функционала в 3 место
- Предварительное добавление сервиса для сканирования сети вручную
- Приостановка и удаление вручную
Очень напомнило решения из начала 2000. Тогда очень любили сканировать сеть считая это автоматизацией.
Задача была автоматизировать добавление новых экспортеров, хранится же все в консуле как в kv хранилище.
Централизованное решение:
метрики все равно выпуливает прометей, так что отправная точка где то рядом с ним. У нас это кластер кубернетес, рядом в том же неймспейсе и этот сервис.
Вынесение функционала в 3 место:
А где должна быть логика? Статик конфиг в Прометее? Автодисковери для обычных вм у него нет.
Предварительное добавление сервиса для сканирования сети вручную:
Не совсем так. Я добавляю подсеть. Дальше он сам ищет экспортеры в подсети и сам добавляет их в kv консула.
Приостановка и удаление вручную:
Останавливать ничего не требуется. Удаляешь сервис из консула — удаляется ендпоинт в Прометее.
Централизованное решение:
метрики все равно выпуливает прометей, так что отправная точка где то рядом с ним. У нас это кластер кубернетес, рядом в том же неймспейсе и этот сервис.
Вынесение функционала в 3 место:
А где должна быть логика? Статик конфиг в Прометее? Автодисковери для обычных вм у него нет.
Централизованное оно, потому что вся основная логика поиска и регистрации сервиса сконцентрирована в одном месте — в дополнительном сервисе. Без него или в случае ошибки, он встанет, что есть дополнительная точка отказа.
consul-service — это распределенная регистрация сервисов в Consul. Там где описан запуск сервиса, там же описана и его регистрация в Consul, без разнесения по нескольким сервисов.
p.s. Не ради рекламы, а ради сравнение подходов.
Предварительное добавление сервиса для сканирования сети вручную:
Не совсем так. Я добавляю подсеть. Дальше он сам ищет экспортеры в подсети и сам добавляет их в kv консула.
Подсети заводятся руками и каждый новый сервис(автор все считает их все exporters, но не все сервисы отдают метрики в prometheus через exporter, многие сами умеют это), заводятся отдельно и руками. Потом руками нужно их скрестить.
Приостановка и удаление вручную:
Останавливать ничего не требуется. Удаляешь сервис из консула — удаляется ендпоинт в Прометее.
Вручную, в виде дополнительного действия.
А еще:
— `LDAP_HOST` и `LDAP_BASE_DN` обязательные и без них не запуститься или не пустить в сервис. А как же админская учётка для гарантированного доступа.
— Смутил пример на скринах. Объявляется поиск node_exporter в подсети что именована как openshift. OpenShift — это K8S. В K8S node_exporter — это DaemonSetи и ни что иное. Про DaemonSet, а точнее дочерний pod, Prometheus узнает от kube-apiserver.
Либо я не до конца понимаю этот пример.
Уверен что со своей nevidanniu/promenad задачей справляется, но…
Простой service discovery в Prometheus через Consul