Мониторинг приложений k8s из операторского кластера

У нас есть несколько кластеров K8S, которые нам нужно отслеживать из одного операторского кластера (кластер A). Мы используем Prometheus на каждом кластере для мониторинга самого кластера, теперь, кроме того, мы хотим отслеживать с определенного API-интерфейса приложение, которое сообщит нам, является ли наш кластер (в соответствии с нашими конкретными услугами) функциональным или нет, я не говорю о мониторинге кластера, мы хотим, чтобы оператор контролировал 3 приложения в каждом кластере (все 3 приложения развернуты на всех наблюдаемые кластеры)

Кластер A (оператор) должен отслеживать службы / приложения в кластере B, C, D и т. Д.

например Кластер операторов будет вызывать деплоенное приложение в clusterA, например host://app1/status, чтобы получить статус 0 или 1 и сохранить статус в некоторой БД. (возможно, prometehusDB) и сообщать о них вне кластера.

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

  1. Используйте экспортер черного ящика - https://github.com/prometheus/blackbox_exporter

  2. Создавайте свои собственные программы (на golang), которым понравится cronjob и которые будут запускаться в кластере операторов с помощью prom lib.

https://github.com/prometheus/client_golang

Я имею в виду выполнение вызова отдыха и использование Prometheus api для сохранения статуса внутри Prometheus tsdb с помощью кода go github.com/prometheus/client_golang/prometheus/promhttp. но не знаю как ..

  1. Федерация ??

Кроме того, если мне удалось собрать все данные из кластеров в операторский кластер, как и где мне их хранить? в Prometheus db tsdb? другой путь ?

Что должно быть наилучшей практикой в ​​поддержку нашего дела? Как мы должны это сделать?


person Beno Odr    schedule 06.07.2020    source источник
comment
Есть ли причина не использовать здесь обычную федерацию Прометея?   -  person coderanger    schedule 06.07.2020
comment
@coderanger - спасибо за воспроизведение, мы уже рассматриваем это и хотим использовать Таноса, однако, поскольку у нас есть некоторые акушерские методы для отправки данных в локальную систему, мы сделаем это позже, теперь нам нужно использовать некоторую внутреннюю систему мониторинга, что вы предлагаете в случае обоих упомянутых мной вариантов?   -  person Beno Odr    schedule 06.07.2020


Ответы (2)


Я видел, что вы думали об использовании Таноса, это неплохо, и какое-то время мы запускали его в продакшене. Но это не соответствовало нашим требованиям, ваше кажется знакомым нашим, поэтому я предлагаю вам взглянуть на VictoriaMetrics, у вас есть хорошая статья только здесь: https://medium.com/faun/comparing-thanos-to-victoriametrics-cluster-b193bea1683

Также большой успех - их поддержка в Slack! Удачи в реализации!

person Mark Davydov    schedule 07.09.2020

В идеале вы бы инструментировали свой код и предоставляли совместимые с Prometheus метрики для любых отслеживаемых потребностей. Но есть что сказать о черном ящике и / или стороннем мониторинге / дымовом тестировании.

Модуль http в Blackbox Exporter, вероятно, то, что вам нужно (я использовал его раньше). Если это недостаточно гибко для тестирования, которое вам нужно, мне нравится запускать пользовательские сценарии тестирования в Lambda, которые записывают результаты в Cloudwatch (если работает в AWS, в противном случае используйте эквивалент в своей среде). Если вы этого не делали раньше, придется немного научиться, но это того стоит.

Если API-интерфейсы доступны извне, такие службы, как Pingdom и Site24x7, предлагают гибкие варианты тестирования (за определенную цену), и обычно рекомендуется использовать стороннюю организацию для хотя бы базового тестирования работоспособности в случаях, когда вся ваша среда выходит из строя. - вместе со всем вашим мониторингом!

Но похоже, что вы просто хотите выполнить базовый мониторинг стиля черного ящика, для которого Blackbox Exporter хорошо бы подошел. Ему понадобится хост для работы, а затем вам нужно будет добавить задание для него в конфигурацию очистки Prometheus. Лучше всего использовать каждый хост для одной цели, поэтому я бы выделил конкретный хост для запуска экспортера черного ящика (даже если это просто еще один контейнер в кластере).

person Benjamin Isaacson    schedule 10.09.2020