Комментарии 16
Годно. Красиво.
Но следующий этап познания дзена мониторинга: дашборды по окончанию вау-эффекта никто не смотрит.
И тем более никто не смотрит на них вовремя. Мониторинг - это грамотные и своевременные алерты. Всё остальное - для ретроспективного post-mortem.
Являюсь сотрудником Т-Банка, коллега получается. В последнее время много зависал в этой борде, за две недели провел там наверное часов десять точно. Хочу выразить безмерный респект за эту работу, видно что делали от души
Особенно понравилась секция Queries, очень помогла при поиске запросов, которые выжирали CPU базы
Красотища!
А технические подробности о том как собираются и обрабатываются метрики будут? Понятно, что есть много способов, но интересно как именно вы это сделали.
На эту тему, думаю, отдельная статья будет. Если кратко: node_exporter, postgres_exporter - эти метрики идут в один пром и пробрасываются в Victoria metrics (общебанковское хранилище метрик). Метрики со статистических представлений Postgres собираются и хранятся отдельным Prometheus инстансом, в виду своей высокой кардинальности. Собираются кастомными запросами с помощью вот такого экспортера - https://github.com/burningalchemist/sql_exporter
Насколько я понимаю это пересказ доклада с pgconf
Но что здесь, что там ни слова о реализации (что под капотом), поэтому лично я не могу сказать ВАХ как круто. Имея кучу данных можно нарисовать что угодно и как угодно, но важны алерты и техническая реализация.
Для 10к баз метрик должно быть много. Можете раскрыть насколько быстро работает отрисовка отдельных дашбордов? Т.е. например, <3sec, 3-5 sec, 5-10sec, 10s+ ?
На самом деле достаточно быстро. Конечно бывают моменты легких лагов(когда много желающих)) Помогает, что все высококардинальные метрики у нас на отдельном проме. Плюс что большинство секций по умолчанию свернуты (данные грузятся именно при открытии). Ну и большинство этих дашбордов под конкретный инстанс (т.е. переменная сильно отсекающая по селективности для promql запроса, всегда определена). Вот обзорный дашборд по всей инфре работает существенно медленнее. На примере дашборда DB Performance за суточный диапазон грузится в среднем за секунду-две, и на раскрытие нужной секции секунда-две. Жалоб на это от пользователей нет. Самая тяжелая панель тут - таблица с запросами. Там аггрегации, плюс много колонок (соответственно promql запросов) и плюс сами метрики запросов самые высококардинальные из всех. Вот она может и до минуты собираться в зависимости от выбранного диапазона.
Спасибо за отличную статью!
Планируете ли опубликовать данное хозяйство в общий доступ?
Планируете ли рассказать, как эти метрики собираются в вашей системе?
Для хранения журнала лога СУБД используете loki?
Немного не в тему можно спросить ?
10000 patroni инстансов... zalando (авторы patroni) с 1400 создали свой pg оператор и ушли в k8s. Не рассмотриваете такой вариант ? Врядли у вас там bare metal все инстансы высконагруженные.
Сорри , просьба чуть уточнить .
А где расположен репозиторий ?Отдельный выделенный сервер , так ведь . А на серверах СУБД - агенты ?Периодичность сбора данных ?
Извините, очень большая статья , с телефона не совсем удобно - что по истории выполнения запросов и истории ожиданий ? Ожидания на уровне СУБД , БД или отдельного запроса ?
Так же и по блокировкам - история и дерево блокировок доступны ?
Что в черном ящике, или Как разработчику понять, что требует оптимизации в БД PostgreSQL