Comments 8
Мы для оповещений используем Moira. Модель с тэгами мне тоже больше нравится, но на наших масштабах не сменить так просто технологию.
Только складывается ощущение, что кое-где автор специально через пень-колоду настраивал отображение метрик в grafana чтобы набрать иллюстративного материала)
И об акцентах:
На мой взгляд, если пользователь осознанно выбирает неподходящий способ отрисовки «Null value» в метриках, то такой кейс никак нельзя озаглавливать «Графики врут». Скорее следует сделать сделать упор на то, что нужно изучать инструмент (grafana в этом случае) прежде чем ставить галочки в настройках. Иначе получается, что это не юзер откровенно накосячил, а что злобные машины ополчились против человеков.
Правильный вывод из статьи должен быть такой: метрики нужны для учёта того, что меняется. Для учёта единичных событий метрики не подходят.
Дело не в cargo programming, а в том, что вы используете спидометр для учёта пробега. Уже чувствуете бессмыслицу, так ведь? Все те библиотеки написаны так именно потому что они предназначены для измерения скорости, а не пробега. Для графика скорости имеет смысл и экспоненциальное сглаживание, и алиасинг. Для пробега эти методы не имеют никакого смысла. Для учёта пробега следует использовать другие методы и средства, будь это одометр или Elastic Stack какой.
Спасибо за статью. Grafana прекрасный инструмент но вот consolidation совершенно не очевидный аспект. Приходится каждому пользователю отдельно объяснять почему его метрика при зуммировании меняется в два раза. Многие отказываются от использования графаны потому что не хотят об этом постоянно думать и переходят на другие графики когда есть возможность (вместо jmx смотрят jvm метрики в аппдинамикс например). Очень неудачно.
Ещё раз отличная статья. Хотелось бы чтобы попалась раньше, до того как набил своих шишек.
Один вопрос — когда есть несколько процессов w3wp одного веб приложения (веб-сад), как Вы разграничиваете от какого из инстансов прилетает метрика?
например загрузка по CPU?
Насколько я знаю, в Metrics.NET есть возможность собирать данные с внутренних счетчиков производительности, но если процессов несколько, то и инстансов счетчиков будет несколько (w3wp, w3wp#1), а библиотека будет брать данные только с первого счетчика (w3wp).
Есть в винде такой performance counter, называется ID Process. Там лежит маппинг из имени процесса (w3wp#1) в process id. Мы просто читаем из него все инстансы по префиксу name, где name — имя нашего процесса, и выбираем из найденных тот name, которому правильный pid соответствует. Этот процесс периодический, значение name кэшируется на пару минут.
Если интересно, есть даже код: pastebin.com/AVAy6EUK
Как обложить сервис метриками и не облажаться