Комментарии 8
Следует добавить, что в указанном примере нет никакой персистенции данных (или я ее не увидел) — т.е. каждый перезапуск контейнера/кубернетеса будет приводить к обнулению данных. Неприятно, но для демонстрации возможностей — вполне достаточно. Для продакшена все придется делать совсем по-другому.
Ну, и добавлю, что из TICK стэка реально чудесен только телеграф. Коллеги из https://t.me/metrics_ru утверждали, что они сталкивались с случайными его зависаниям, когда вроде телеграф работает, а метрики не льются, но я лично достоверных таких случаев не знаю. А вот InfluxDB — это боль. Сама идея иметь графито-подобную базу — она хороша. Но вот с реализацией есть нюансы. Эти постоянные смены формата базы (отсутствие обратной совместимости), отсутствие кластеризации (есть только в платной версии), отсутствие внятного тулинга и нюансы с потреблением памяти (не раз видел, как инфлакс давился вроде бы обычными запросами, только на большую глубину истории) ставят большой вопрос о пригодности к эксплуатации этой БД в продуктовой среде. Хотя я знаю крупные компании, которые с этой БД живут.....
И уж я мог бы не упоминать, что это вечная битва — statsd вариант отправки метрик и prometheus формат с опросом метрик снаружи (и есть ощущение, что прометеус вариант именно в применении к долгоживущим сервисам победил)
Мне вот непонятно как в общем случае собирать метрики типа количества запросов и время их обработки опросом. Превратить стейтлесс приложение в стейтфулл, чтобы оно набирало эти данные и хранило между запросами того же Прометеуса? Писать в логи и сделать из анализатор, который будет отдавать Прометеусу метрики?
Первый кейс похож на правду. Ну, будет у него (у каждого инстанса приложения) свой буфер. Перезапускаемся — у нас счетчик сбрасывается, но и пофиг. Если это случается не слишком часто — проблемы не будет. Если часто — да, мы попросту будем видеть фуфломицин, а не данные. Т.е. счетчик запросов у нас нарастает, пока мы не ребутнем приложение. Можно попробовать его сбрасывать в момент, когда у нас прометеус приходит за данными, но если у нас несколько прометеусов скрейпят один таргет, то нам придется их как-то отличать. Вот разработчики нетдата столкнулись с этой же проблемой и им пришлось закостылить https://github.com/netdata/netdata/tree/master/backends/prometheus
Далее. Если у тебя несколько инстансов приклада — ты сам должен решить ОК ли это, если у каждого инстанса своя метрика, или ты хочешь агрегированную.
Ну, и в конечном счете — всегда ПРОЩЕ считать статистику запросов не на приложении самом, а не прокси перед ним (ingress, service mesh).
Писать в логи и сделать из анализатор, который будет отдавать Прометеусу метрики?
не будет ли это слишком ресурсоемко? Плюс это ставит вопрос гарантированности доставки логов, иначе нельзя будет верно посчитать количество запросов
И это мы еще не говорим про обработку батч-джобов (кратковременных) или потоковой обработки данных.
Ну вот с точки зрения учёта нескольких инстансов и кратковременных и потоков, снимать метрики через через логи (централизованные или частично централизованные, типа stdout/stderr докер логов на каждой ноде кластера) наиболее разумным видится как с точки зрения минимальных изменениях в приложениях, а то и вообще без них, так и с точки зрения сохранности метрик для нескольких инстансов Прометеуса и между запусками.
На прокси может быть и лучше с какой-то точки зрения, но особо дела не меняет с точки зрения сбора, по-моему, кроме того что возможности конфигурирования часто сильно ограничены, а написаны прокси на нестандартных для команды языках типа Си или Гоу. Ну и у приложения есть более точные метрики типа время ответа базы данных
Я думаю, что нам нужен Владимир Гурьянов
А какую литературу / обучалки порекомендуете, когда основные понятия уже прочитаны / прощупаны по верхам, и надо уже начать углубляться, что бы лучше понимать, как оно всё работает (как проводить диагностику, траблшутинг, какие-то best practices и т.п.)?
-
Развертывание в Docker и Kubernetes образа StatsD+Grafana