Комментарии 12
А можно скриншот из реальной практики?
А что бы вы хотели увидеть на скриншоте?
Я не сталкиваюсь в своей работе с этим и было бы интересно посмотреть интерфейс.
Это не совсем относится к теме доклада, а так же с учетом ограниченности времени на доклад (и так пришлось сокращать его).
Но я могу предложить пару видео, которые позволят познакомиться с интерфейсами продуктов, о которых я рассказывал.
Grafana: https://youtu.be/QDV4KfDPs1E
Prometheus: https://www.youtube.com/watch?v=VUQ6RudYh_w
Mimir - не имеет собственного интерфейса.
...То Recall в забор просуну,
то Precision покажу
Как вариант, можно использовать Prometheus с retention 1d.
А разве при включении remote_write не остается работать только локальный WAL на 2 часа, а tsdb отключается?
Нет. При включении remote_write, Prometheus продолжает работать как "обычный" Prometheus. При этом у Prometheus есть режим работы, который называется Prometheus agent mode, вот в этом режиме он работает так как вы описали.
Подробнее про это можно почитать, например, тут: https://prometheus.io/blog/2021/11/16/agent/
Спасибо за пост/доклад. В целом неплохо, хотя с service discovering несколько покоробило
Спасибо за пост, из того, что последнее время тут было про мониторинг (а было немало), самый содержательный.
Вопрос такой - а если сравнить Mimir с VictoriaMetrics? VM, вроде, то же самое место занимает в архитектуре системы мониторинга и позиционируют себя как более легковесное решение. Если мониторить не тысячи машин и даже не сотни, так что особых потребностей в масштабировании нет, - есть какие-то плюсы поднимать между Prometheus и Grafana всё-таки Mimir, а не VM?
Я сейчас на этапе "Серия 1" - один Prometheus и напрямую к нему одна Grafana. Но задумываюсь о том, что в случае потери связности между 3 разными площадками метрики терять как раз меньше всего хотелось бы, именно в такой неприятный момент они и нужны будут, чтобы разобраться. Ну и база Prometheus (которому самонадеянно приказано хранить метрики аж 3 года) растёт и её по-любому надо скоро будет куда-то складывать, не на локальный диск сервера... Так что думаю, в какую сторону развить всё это счастье.
Ох, на самом деле, сложный вопрос. Если уже заговорили о VM, то это действительно хорошее решение. Однако не стоит забывать о нюансах, которые важно понимать. Далее, стоит оценить, насколько существенны для вас эти особенности и сделать выбор.
Во-первых, VM использует упрощенную модель хранения данных. Подробнее об этом можно прочитать здесь: https://www.robustperception.io/evaluating-performance-and-correctness/.
Во-вторых, VM применяет собственный формат хранения данных, и на данный момент существует возможность перехода на VM, но обратной миграции нет.
В-третьих, VM формально шардирует данные, но фактически не поддерживает механизм решардирования. Другими словами, если у вас есть кластер из 3 vm-storage, вы не можете отключить один vm-storage и на его месте запустить новый, более мощный (а затем проделать то же самое с остальными), на новые vm-storage будут записываться только новые данные, а старые не перенесутся.
В-четвертых, в Mimir долгосрочное хранилище отделено (это S3), что делает систему более гибкой.
В итоге вам необходимо определить, насколько вы согласны с этими нюансами.
Мимо тёщиного дома я без метрик не хожу (обзор и видео доклада)