Во время работы с конвеером данных, в результате работы которого у нас появлялись данные в Timescale, которые мы визуализировали в виде тепловых карт прошлой статье, у нас было задействовано много разных компонентов, каждый из которых норовил упасть или привнести свою лепту в задержку появления данных в базе и на фронт-энде.
Поэтому в моей обязанности было и ведение мониторинга, причем не только для знакомого мне стека как разработчику Spring Boot (в нашем случае это был Apache Camel), но вообще всего, до чего можно было дотянуться. Если с Timescale, Apollo Nodejs Graphql, MQTT, JMeter (там было постоянное нагрузочное тестирование на тест стенде) и сервисами на Golang проблем не возникло, после настройки экспорта их стандартных метрик в Prometheus в формате Micrometer удалось почти сразу же найти подходящие готовые дашборды на сайте Grafana, если с дашбордами под метрики k8s было еще проще - они шли как provisioned в helm-chart-е kube-prometheus-stack, то с остальным зоопарком оказалось сложнее.
Так, для Apache Camel и его кастомных метрик, сконфигурированных под каждый маршрут, пришлось существенно допиливать один из готовых дашбордов, приспособленных под визуализацию данных при включенном Spring Boot Actuator и собираемых с эндпойнта /actuator/prometheus
. Дашборд по мотивам этого приключения выложен в галлерею дашбордов с краткой инструкцией, как им воспользоваться.
Гораздо хуже была ситуация с Apache Spark. Для него включались метрики при помощи некой копипасты для его конфига, который позволяет отдать в формате Micrometer внутренние метрики "спарка", отфильтровав и немного их переименовав, и которая стала практически промышленным стандартом. В момент, когда эти метрики стали собираться, на нас вывалился огромный массив метрик, на которые надо сначала глазами посмотреть, прежде чем разбираться, о чем конкретная метрика и информативна ли она. Надо было как-то автоматизировать процесс - взять портянку выданных Apache Spark метрик и создать дашборд о десятках панелей, чтобы уже глядя в них разбираться. Это мягко говоря, против того подхода, когда дашборды в Grafana делаются плавно и очень осмысленно, избегая непонятного и лишнего, но нам это нужно было скорее в первую очередь для exploratory testing, чем для промышленного мониторинга.
Был написан код, который создавал JSON-конфиг для импорта данных как нового дашборда в Grafana, анализируя скопированный вывод экспортера метрик для Prometheus в фромате Micrometer. Делал он довольно просто и примитивно - оказалось, что присуствующие человекопонятные имена метрик, которые иногда приходят в разделе #HELP
формата Micrometer, совершенно неинформативны. Метрики команда запоминала по самому названию и написанию метрик, а если дашборду хотелось дать более "бизнесовое" имя, то это делалось сильно позже, не в момент создания дашборда.
Кроме того, быстро стало понятно, что анализ любой метрики лучше делать, глядя на 2 графика - нормального вида измеряемого показателя и его "первой производной" по времени - функции Grafana rate()
. При этом в заголовок дашборда, когда в нем много панелей, оказалось удобнее вывести rate(имя_метрики[5m])
чтобы мнговенно находить глазами сопоставление с ней оригинального графика со значениями.
Впоследствии добавили еще дашборд для наблюдения за Hadoop. К нему никаких плагинов для экспорта метрик не полагалось, поэтому пошли на хитрость. К Grafana можно подключить в качестве второго "прометеуса"... Loki. Далее, выбрав "именно такое Локи" в качестве "датасорса" (Loki подключенное как Loki не подойдет) можно добавлять алерты на запросы, которые в Loki ходят за счетчиком логов.
Например, можно попросить построить вот такую вот метрику:
count_over_time({app="hadoop"} |="INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Receiving"[5m])
Что выдаст некий график, сколько раз за 5 минут лог был записан, а этот лог признак стабильной работы. Затем с графиком можно строить производную, можно вешать оповещение на выставленные для него пороги, в общим, полный функционал метрики от Prometheus. Так удалось сделать алерты и на его работу.
Сделанные дашборды были загружены в мою скромную галлерею на grafana.com. Оказалось, что за прошедший год их даже кто-то скачивал, что означало лишь одно: граждане мониторящие продолжают сталкиваться с нехваткой готовых дашборд в ситуации, когда у них появляется целая куча новых метрик, за которыми ранее не следили. Ведь кроме стандартных метрик от приложений и фреймворков, разработчики могут насоздавать великое множество метрик уровня приложения, но делать красивые панели для каждой метрики в ручную им может и не захотеться. Если не сделать нам панель, эдак мы и за своими метриками следить расхотим, надо как-то упростить жизнь и сделать внедрение метрик и наблюдения за ними максимально простым.
Было решено сделать небольшую веб-утилиту, которая позволила бы проделать онлайн то же, что мы проделывали ранее в консольном приложении для метрик "спарка". Попробовать ее можно здесь: http://eljah.tatar/micrometer2grafana
UPD. Да, код ее открыт, если вдруг в вашей компании понадобится развернуть подобное с некоторыми изменениями, то вот, микроскопический java-проект под Tomcat 10 и jakarta.servlet: https://github.com/Eljah/micrometer2grafana
Что нужно сделать? Сначала скопируйте у себя текст метрик, как их отдает экспортер интересующего вас приложения
![Пример взят для Apache Camel под Spring Boot Пример взят для Apache Camel под Spring Boot](https://habrastorage.org/getpro/habr/upload_files/78b/c90/746/78bc90746ff900fa466dbe79bc3d1f5c.png)
Скопируйте в поле ввода. Выберите, хотите вы оригинальные метрики, "производную по времени" с указанным временем "шага" или оба варианта сразу, также надо ввести название datasource у вас в "графане", уникальный идентификатор и заголовок для нового дашборда (если вас не устраивают предложенные по умолчанию).
![С момента публикации, надеюсь, появятся дополнительные поля и настройки, если будет о том обратная связь С момента публикации, надеюсь, появятся дополнительные поля и настройки, если будет о том обратная связь](https://habrastorage.org/getpro/habr/upload_files/077/445/43c/07744543c94126d57cf34064d3f350ce.png)
Скопируйте возвращенный JSON, это ваш конфиг, который нужно импортировать в Grafana.
![Делать страницу с особым копирабельным выводом не хватило времени и упорства. По-моему, выделить и скопировать в 1 клик можно и для вывода с text/plain, а больше и не нужно ничего Делать страницу с особым копирабельным выводом не хватило времени и упорства. По-моему, выделить и скопировать в 1 клик можно и для вывода с text/plain, а больше и не нужно ничего](https://habrastorage.org/getpro/habr/upload_files/f85/856/34f/f8585634f2e815867f02f43c9174c8f3.png)
![Именно отсюда надо загружать конфиг-JSON Именно отсюда надо загружать конфиг-JSON](https://habrastorage.org/getpro/habr/upload_files/4d2/63b/91d/4d263b91d59cd40620aac5f049cfcd53.png)
После импорта, если вы выбрали одновременно и оригинальную метрику и производную, можно посмотреть, какую порой разную информацию можно получить в каждом случае:
![В первом случае видна динамика роста времени коннектов, но это малоинформативно, ведь _sum всегда будет копиться и расти. Нижняя метрика, показывающая, как менялась скорость роста этой метрики куда информативнее о работе системы. В первом случае видна динамика роста времени коннектов, но это малоинформативно, ведь _sum всегда будет копиться и расти. Нижняя метрика, показывающая, как менялась скорость роста этой метрики куда информативнее о работе системы.](https://habrastorage.org/getpro/habr/upload_files/e3b/452/708/e3b4527089119d788b091322d90b983e.png)
Если вы нашли эту статью, использовали утилиту и у вас появилась обратная связь, напишите в комментариях. Буду мониторить!