Реформа системы мониторинга

Цельсу уже 6 лет, и за это время мы обросли довольно большим количеством клиентов из разных стран. У каждого клиента есть свои особенности:

• Тип подключения - по DICOM-протоколу, с помощью десктопного приложения, по API, гибридные схемы
• География и часовые пояса - Москва, регионы России от Ленобласти до Магадана, Беларусь, Индия, Пакистан, ОАЭ
• Модальность - ММГ, ФЛГ, РГ ОГК, КТ ОГК, КТ ГМ, МРТ ОМТ
• Схема деплоя - облако, локальный деплой, гибридный деплой
• Схема бэкенда на нашей стороне - старая интеграция или новая микросервисная архитектура
• Версия сервиса
• Набор патологий и других настроек
• Особенности данных - качество изображений, правила заполнения тегов
• Отсутствие или наличие во входящем потоке нерелевантных изображений
• Инфобезопасность - логин/пароль, защищённое соединение с использованием WireGuard, IPSec или VipNet
• Наличие доступа с нашей стороны - полный доступ к исследованиям и БД, частичный доступ, фактическое отсутствие доступа к машинам и нашим сервисам
• Размер потока - от нескольких исследований в день до нескольких тысяч 
• Этап работы - промышленная эксплуатация, опытная эксплуатация, демо-доступ

За всеми этими интеграциями нужно следить. Какие-то более критичные в плане времени обнаружения и устранения проблем, какие-то менее, но по итогу мы должны уметь вовремя детектировать проблемы, подключать нужных людей и возвращать сервисы к нормальному функционированию. В этом году мы серьёзно усовершенствовали и унифицировали нашу систему мониторинга. Цели ставились следующие:

• Значительно сократить количество ручного труда -  например, для ежедневного мониторинга локального региона нужно зайти на машину через VPN, зайти в БД, выгрузить статистику по ошибкам, и так для каждого региона
• Сократить количество ложных алертов - алерт, по которому не требуется никаких действий, почти наверняка не должен существовать
• Минимизировать количество пропущенных нами инцидентов, о которых мы узнаём от клиентов
• Упростить, формализовать и документировать систему алертов и мониторинга - что делать в каждой конкретной ситуации

В основном этим процессом заведовал мой коллега Антон Голубев, ему же спасибо за некоторые иллюстрации к этому посту и ревью текста.

Инструменты

Переход на сервис статистики

Каждый облачный клиент и каждая модальность раньше жили только в своей базе данных со своей структурой, и описано всё это было в многостраничном талмуде, который, естественно, почти никогда не обновлялся вовремя. Теперь в рамках каждого сервиса существует сервис статистики, который приводит данные к единому виду и красиво складывает в единую базу с несколькими табличками:

• Customers - информация о кастомерах (клиентах), подключенных к ИИ-сервисам
• Researches (этот неверный перевод слова “исследования” - в смысле КТ, рентгены, МРТ, однажды прилип и никак не отлепится) - основная информация об обработке: айди исследования, успешность, категория ошибки и так далее
• AI_result_summary - основные результаты работы сервиса: найденные патологии, вероятности, измерения
• Research_common_tags - информация о DICOM-тегах исследований
• Tracked_operations - таймстэмпы начала выполнения разных операций по ходу работы ИИ-сервиса

Такая структура позволила перейти на единый дашборд, в котором можно выбрать любую среду, продукт и клиента. Здесь можно получить информацию о количестве обработанных исследований, видах ошибок, времени выполнения разных операций и о результатах работы ML-моделей.

Улучшение StreamTV

В этом году мы сильно прокачали наш сервис для мониторинга потока исследований, написанный на Streamlit. У него есть два основных сценария использования (и несколько дополнительных):

1) Если нужно найти конкретное исследование (или целую кучу), причём даже необязательно знать, каким клиентом оно было прислано. Его можно скачать или открыть ответ ИИ-сервиса в веб-вьюере.

То же самое можно делать и в Телеграме, это удобнее для врачей-консультантов.

2) Если хочется промониторить поток по конкретному клиенту или найти исследования по фильтрам - например, с определённой патологией.

Локальные регионы в общей БД

Пожалуй, самой большой болью в процессе мониторинга является наличие локальных развёртываний в регионах. По сути, в регионе ставится сервер с GPU, мы проходим через бюрократические дебри и получаем доступ к серверу региона - обычно доступ по SSH с использованием VipNet (отечественный криптошлюз для организации защищённого шифрованного обмена трафиком). Дополнительно можно попросить открыть другие порты помимо стандартного 22.

До этого каждый день дежурный заходил на каждый сервис и выгружал из БД статистику по обработкам за день. Теперь же захотелось, чтоб все эти БД были доступны в нашей Графане. Для этого было использовано две техники:

• Foreign data - позволяет получить доступ к данным, которые находятся вне нашего инстанса Постреса. Исходные данные при этом не копируются, запрос выполняется в БД клиента, и мы получаем только ответ на запрос. 

• View - позволяет создать “виртуальную таблицу” из нескольких таблиц, к который мы можем обращаться по простому имени. Опять же, никакого реального перемещения данных не происходит, запросы к реальным таблицам выполняются каждый раз при обращении. Дополнительно поддерживется таблица соответствий “регион - foreign table”, это позволяет запрашивать только те внешние таблицы, которые нужны для данного запроса.

Алерты в Маттермосте через Графану и отдельный сервис

Правила большинства бизнес-алертов (отсутствие потока на клиенте, превышение времени обработки или процента ошибок) задаются в Графане. При срабатывании приходит сообщение в Маттермост, из Гугл-календаря автоматически забирается и тегается текущий дежурный. Плюсом такой схемы является, что правила алертов можно оперативно поправить прям в Графане. Прям из алерта можно по щелчку перейти в связанный дашборд для более детального изучения ситуации. 

Часть алертов через Графану делать не очень удобно, поэтому мы подняли свой сервис, который раз в заданное время собирает инфу и в случае срабатывания письмо с алертом отправляется на сервисный имейл, откуда его забирает Mail2most и по заданным правилам переправляет в нужный канал. Чтобы отредактировать такие алерты, нужно сделать новый коммит и пушнуть его в мастер.

Помимо бизнесовых алертов есть ещё два типа, они вынесены в отдельные каналы:

• Инфраструктурные - есть коннект к серверу клиента, consumer lag в Кафке
• MLьные - алерты через Sentry по работе сервиса нейронки (ошибки кода, ошибки предобработки исследований и так далее)

Процессы

Правила мониторинга

Инструменты - это только полдела. За всеми алертами и дашбордами должен кто-то следить. Раньше алертами в основном заведовала команда бэкенда, и нагрузка была очень большая - 5 направлений, по каждому направлению куча разных клиентов. По новым правилам входным звеном для всех бизнесовых (не инфраструктурных) алертов является дежурный соответствующий ML-команды (например, маммографии). Оставлять алерт без ответа нельзя - либо нужно предпринять действие, либо предложить изменение правила алерта.

Также появилась куча документации, описывающей суть разных алертов и правила разрешения каждого из них.

Тонкая настройка алертов

Каждый фейковый алерт пробивает очередную брешь во всей вашей тщательно выстроенной системе мониторинга. С каждым разом дежурный будет обращать всё меньше внимания на нотификацию из Маттермоста.

Поэтому первые несколько недель алерты активно донастраивались - в основном в сторону ослабления. В Графане создали различные Mute Timings, и распределяем алерты по разным группам срабатывания.

Есть, конечно, и обратные случаи - если произошёл инцидент, а наши алерты его пропустили или сильно опоздали, мы тут же решаем, что нужно сделать, чтоб такая ситуация больше не повторилась - например, добавить новый алерт. Недавно в Яндекс.Клауд был большой сбой, на такое событие наши алерты просто не были заточены. Из-за этого мы потеряли несколько часов потока, скопились большие очереди на обработку. Хотя в данном конкретном случае мы вряд ли что-то быстро бы смогли сделать, но хотя бы можно было оповестить клиентов.

Можно было бы подумать про динамическую настройку трешхолдов, но пока с этим заморачиваться не хочется, текущая система работает более-менее нормально.

Что дальше?

Текущая система работает весьма неплохо - сократилось количество критических проблем, которые прошли мимо системы мониторинга, а новые инструменты позволяют быстрее понять, в чём беда, и как её пофиксить. Но есть ещё пара вещей, которые хотелось бы добавить.

Поиск по логам

Теоретически все логи всех команд складываются в ELK, но на практике всё несколько сложнее. Если я хочу отследить путь исследования с конкретным айдишником - например, чтобы понять, на каком этапе было затрачено больше всего времени на обработку, мне нужно понять, в какой индекс мне сходить, чтоб посмотреть логи бэка, понять, в какой индекс мне сходить, чтоб посмотреть логи ML, и потом всё это как-то свести в общую картину. Идеальная картинка выглядит так - вбиваю в StreamTV айди исследования, и вижу все логи и временную разбивку по нему. Работа в этом направлении уже началась.

ИИ-вики

Недавно мы создали сервис на основе LLM и RAG, который позволяет чатиться со всей документацией компании - и официальной, и неофициальной (например, чаты). Сейчас к нему подключены Notion, Google-документы, таблицы и презентации, чаты Mattermost, сайты компании и Московского эксперимента, репозитории всех проектов, на очереди Telegram-чаты. Он позволяет значительно быстрее находить ответы на многие вопросы, в том числе связанные с мониторингом и разрешением инцидентов - например, как получить доступ к тому или иному серверу или БД. Об этом сервисе подробнее расскажу в следующий раз.

Text2SQL пока не впилили в сам сервис, но выглядит интересно для проектной команды, которая не владеет SQL. Позволяет задавать вопросы базе данных на русском языке.