programming
profit
kdb
Написал мониторинг. Поставил, стало быть, prometheus. Штук десять разных систем льют в него данные.
А проблема в том, что я не люблю ихний pull, то есть когда он ходит сам за данными, а я ему отдаю по запросу. Потому что у меня там кластер, динамическое всё, кубернетезы, нужно использовать чужие костыли, service discovery всётакое, делать динамический список таргетов. Всё как завещали отцы.
Сделал я pushgateway, то есть как не рекомендовали отцы. И из скриптов туда заливаю данные, а потом сам прометеус их оттуда готовенькими всасует. А данные у меня разные есть, но как известно, данные данным рознь. Таковая система работает с данными типа "загрузка ЦПУ", но плохо работает с данными "запросов в секунду", потому что их хорошо агрегировать "запросов в минуту", "в час" итд. Прометеус это умеет, но в системе с пуш гейтвей не работает, потому что если я например буду каждую секунду в гейтвей заливать цифру "запросов-в-секунду", они не будут там накапливаться, а только последнее хранится. Потом раз в полминуты эти данные забираются уже прометеусом и сами понимаете. Это не синхронизируется в принципе. И не лечится. Так задизайнено. Keep it simple. Ну я приблизительно синхронизировал, порядок совпадает и ладненько. Всякие там jobs, instances как положено.
Потом пошел значит через API запросы гонять и рисовать стало быть graphviz граф на ПЕТОНЕ, в котором на дугах нарисовано к-во запросов в минуту час итд, а в квадратиках загрузка процов итп. Получилось пресимпатишно. НО.
1) куча запросов к прометеусу за данными — тормозит, сотня запросов к прометеусу на 1 отрисовку
2) pushgateway со своими нерешаемыми проблемами.
ДОЛГО ЛИ КОРОТКО
Короче, выкинул прометеус нафиг. Больше ничего не трогал. Оставил как есть все сенсоры на всех 10 сервисах, которые пушают мне свои цифры. И загрузку, и к-во запросов за отчетный период (раз в полминуты лью например).
Взял в руки kdb+. Написал парсер заливаемых данных (POST query). Написал табличку в памяти которая хранит всё что в нее кладут, без вопросов, для последних нескольких миллионов записей, подчищая.
Вместо 100 запросов за данными к прометеусу, теперь запускаю 1 раз весь отрисовочный код, собираю в коллекцию все запросы которые были сделаны (запросы структурно оставил те же самые, токо в kdb syntax перевел), а отдаю нули. Потом 1 раундтрип к кдб с массивом запросов. Потом второй проход снова запускаю отрисовочный код, на этот раз он реально рисует: запросы свои запрашивает, но никто никуда не ходит — все ответы уже на руках.
Результат:
Код отрисовки стал двухпроходной (к-во и структура кода не изменилось, 7 строк ПЕТОНА добавилось которые запускают 2 прохода).
Весь код на kdb+, заменивший прометеус, состоит из 8 (восемь!) строк: пять строк REST сервер беcпарольный, который принимает метрики. 3 строки второй сервер, запароленный, в нем собственно определение таблицы 1 строка, к нему приходят с отрисовочного кода запросы за данными, и две строки утильных функций с повторяющимся кодом для агрегации.
Код, отправляющий данные с сервисов, — без изменений.
8 строк на нормальном языке ваш прометеус, миллениалы.
Да, и алерты на кдб проще будет прикручивать: нормальный язык, а не конечно любопытный, но ограниченный язык запросов к прометейной базке.
