Тут вопрос в том, что подразумевается под мониторингом
В моём понимании мониторинг - это инструмент, который в реалтайме может сообщить и том, что где-то что-то сломалось и надо срочно бежать чинить.
Здесь же речь об инструменте, который позволяет на регулярной основе в автоматическом режиме получать отчёты о каких-то нетипичных вещах, при чем их "нетипичность" определяется исключительно на основе данных за последние полтора месяца. Здесь нет необходимости ловить такие явления в тот же миг, как они начали происходить, достаточно смотреть раз в день (раньше пробовали раз в час, но это избыточно).
А уж реализация такого инструмента может быть любой - кому-то достаточно отчётов, которые метабейз умеет из коробки отправлять на почту. Мы, кстати, сначала им и пользовались, но быстро стало понятно, что автоматический расчёт аномалий уместить в SQL-скрипты очень сложно, да и это тупо неудобно, легче делать всё в питоне и слать куда-то в Slack
Если, конечно, есть кому регулярно разгребать false positive/negative
Мой рабочий день обычно и начинается с того, что я открываю чатик с аномалиями, смотрю на картинки от бота и разгребаю их)
На самом деле занимает это прям мало времени - по части событий сразу видно, что false-positive (событий мало, разброс исторически большой, событие минорное). Если понятно, что что-то сильно поменялось - чаще я всё-таки в курсе предстоящих изменений, поэтому не сложно сопоставить изменения в продукте с аномалиями в событиях аналитики. Ну а если уж сходу не становится понятно, что произошло - идём в дашборд, локализуем проблему, быстро чекаем релизы, призываем разработчиков нужной команды (по названию ивента понятно, в какой части продукта он находится и какая команда за него отвечает).
Но и это не всегда приходится делать, т.к. разработчикам детектор аномалий тоже нравится и многие из них сами заглядывают в чатик с аномалиями и смотрят, что же там происходит :) Часто к тому моменту, как я захожу посмотреть аномалии, уже кто-то успевает отписаться в треде и скинуть ссылку на задачку, в которой вносили изменения
Если не секрет, сколько срезов (метрик / временных рядов) таким образом анализируется?
Вообще не секрет - где-то в районе тысячи
3 платформы * ~300 событий * N дополнительных параметров (например, события доски анализируются также в разрезе параметра board_type). Но некоторые из этих 300 событий приходят очень редко (меньше 100 в сутки), поэтому их отфильтровываем, чтоб не шуметь всякими ложно-положительными срабатываниями
Тут вопрос в том, что подразумевается под мониторингом
В моём понимании мониторинг - это инструмент, который в реалтайме может сообщить и том, что где-то что-то сломалось и надо срочно бежать чинить.
Здесь же речь об инструменте, который позволяет на регулярной основе в автоматическом режиме получать отчёты о каких-то нетипичных вещах, при чем их "нетипичность" определяется исключительно на основе данных за последние полтора месяца. Здесь нет необходимости ловить такие явления в тот же миг, как они начали происходить, достаточно смотреть раз в день (раньше пробовали раз в час, но это избыточно).
А уж реализация такого инструмента может быть любой - кому-то достаточно отчётов, которые метабейз умеет из коробки отправлять на почту. Мы, кстати, сначала им и пользовались, но быстро стало понятно, что автоматический расчёт аномалий уместить в SQL-скрипты очень сложно, да и это тупо неудобно, легче делать всё в питоне и слать куда-то в Slack
Мой рабочий день обычно и начинается с того, что я открываю чатик с аномалиями, смотрю на картинки от бота и разгребаю их)
На самом деле занимает это прям мало времени - по части событий сразу видно, что false-positive (событий мало, разброс исторически большой, событие минорное). Если понятно, что что-то сильно поменялось - чаще я всё-таки в курсе предстоящих изменений, поэтому не сложно сопоставить изменения в продукте с аномалиями в событиях аналитики. Ну а если уж сходу не становится понятно, что произошло - идём в дашборд, локализуем проблему, быстро чекаем релизы, призываем разработчиков нужной команды (по названию ивента понятно, в какой части продукта он находится и какая команда за него отвечает).
Но и это не всегда приходится делать, т.к. разработчикам детектор аномалий тоже нравится и многие из них сами заглядывают в чатик с аномалиями и смотрят, что же там происходит :) Часто к тому моменту, как я захожу посмотреть аномалии, уже кто-то успевает отписаться в треде и скинуть ссылку на задачку, в которой вносили изменения
Спасибо, рад, что оказалось полезно)
Вообще не секрет - где-то в районе тысячи
3 платформы * ~300 событий * N дополнительных параметров (например, события доски анализируются также в разрезе параметра board_type). Но некоторые из этих 300 событий приходят очень редко (меньше 100 в сутки), поэтому их отфильтровываем, чтоб не шуметь всякими ложно-положительными срабатываниями