На данный момент такие связи определяются руками при помощи конфигурационного файла. А дальше самописный сервис на основе этого конфига обрабатывает сырые метрики и пушит обратно в Victoria Metrics красивые - одного типа, с одинаковыми лейблами и т.д. Возможно, при рефакторинге это можно облегчить.
Автоматическое определение по трейсам затруднено из-за различности метрик сервисов и более простым решением было это. А так - идея очень интересная.
Сырые данные приходят через обычные запросы к Victoria Metrics. Для диаграммы используется несколько запросов, которые возвращают связанные сущности и их идентификаторы (идентификаторы внутри графана-запроса, например "A", "B", "C" и т.д.).
Дальше уже в JavaScript эти результаты объединяются: по идентификаторам строится дерево родитель -> дочерний объект, после чего формируется sunburst.
Чтобы не усложнять PromQL запросы и не нагружать Grafana дополнительной логикой, для части расчётов используется собственный агрегатор, который подготавливает данные в более удобном виде. Он написан на Python и переписывает сложный запрос в более легкий внутри самой Victoria Metrics.
Sunburst диаграммы написаны на JavaScript в Business Charts. То есть они полностью кастомные. Насчет связей - связи также обрабатываются в скрипте. Добавляется query в графане - родитель, query - дочерняя, а затем по их идентификаторам можно выстроить связь.
Для упрощения запросов написано свое решение, которое максимально упрощает query для лучшего понимания и снимает лишнюю нагрузку с Grafana.
ELK в этой истории никуда не делся, просто статья получилась про мониторинг и алертинг, поэтому логирование осталось за рамками материала. Если будет интерес у читателей, вполне могу сделать отдельную статью про ELK и накопленный опыт его сопровождения.
Согласен. Миграция в данном случае стала скорее поводом пересмотреть подход целиком. Все старое один в один не переносилось - по каждому сервису проводилась ревизия: что-то удалено, а наиболее полезные проверки сохранены и адаптированы под новый контур. В результате целью была не просто замена хранилища метрик, а снижение шума, повышение качества сигналов и постепенный переход к сервисному мониторингу.
На данный момент такие связи определяются руками при помощи конфигурационного файла. А дальше самописный сервис на основе этого конфига обрабатывает сырые метрики и пушит обратно в Victoria Metrics красивые - одного типа, с одинаковыми лейблами и т.д. Возможно, при рефакторинге это можно облегчить.
Автоматическое определение по трейсам затруднено из-за различности метрик сервисов и более простым решением было это. А так - идея очень интересная.
Сырые данные приходят через обычные запросы к Victoria Metrics. Для диаграммы используется несколько запросов, которые возвращают связанные сущности и их идентификаторы (идентификаторы внутри графана-запроса, например "A", "B", "C" и т.д.).
Дальше уже в JavaScript эти результаты объединяются: по идентификаторам строится дерево родитель -> дочерний объект, после чего формируется sunburst.
Чтобы не усложнять PromQL запросы и не нагружать Grafana дополнительной логикой, для части расчётов используется собственный агрегатор, который подготавливает данные в более удобном виде. Он написан на Python и переписывает сложный запрос в более легкий внутри самой Victoria Metrics.
Sunburst диаграммы написаны на JavaScript в Business Charts. То есть они полностью кастомные. Насчет связей - связи также обрабатываются в скрипте. Добавляется query в графане - родитель, query - дочерняя, а затем по их идентификаторам можно выстроить связь.
Для упрощения запросов написано свое решение, которое максимально упрощает query для лучшего понимания и снимает лишнюю нагрузку с Grafana.
Спасибо!
ELK в этой истории никуда не делся, просто статья получилась про мониторинг и алертинг, поэтому логирование осталось за рамками материала. Если будет интерес у читателей, вполне могу сделать отдельную статью про ELK и накопленный опыт его сопровождения.
Согласен. Миграция в данном случае стала скорее поводом пересмотреть подход целиком. Все старое один в один не переносилось - по каждому сервису проводилась ревизия: что-то удалено, а наиболее полезные проверки сохранены и адаптированы под новый контур. В результате целью была не просто замена хранилища метрик, а снижение шума, повышение качества сигналов и постепенный переход к сервисному мониторингу.