Во время работы с конвеером данных, в результате работы которого у нас появлялись данные в 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

Что нужно сделать? Сначала скопируйте у себя текст метрик, как их отдает экспортер интересующего вас приложения

Скопируйте в поле ввода. Выберите, хотите вы оригинальные метрики, "производную по времени" с указанным временем "шага" или оба варианта сразу, также надо ввести название datasource у вас в "графане", уникальный идентификатор и заголовок для нового дашборда (если вас не устраивают предложенные по умолчанию).

Скопируйте возвращенный JSON, это ваш конфиг, который нужно импортировать в Grafana.

После импорта, если вы выбрали одновременно и оригинальную метрику и производную, можно посмотреть, какую порой разную информацию можно получить в каждом случае:

Если вы нашли эту статью, использовали утилиту и у вас появилась обратная связь, напишите в комментариях. Буду мониторить!