Алерты

О создании системы мониторинга мы задумались на этапе формирования продуктовых команд. Стало понятно, что наше дело эксплуатация в эти команды никак не попадает. Почему так?

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



Наша же команда, в свою очередь, работает с системами, которые очень сильно интегрированы между собой: между ними множество связей, это весьма большая инфраструктура. И от всех этих систем (которых у нас, к слову, огромное количество), зависит работа интернет-магазина.

Вот и получается, что наш отдел не относится ни к одной команде, а находится немного в стороне. Во всей этой истории наша задача понимать в комплексе, как работают информационные системы, их функциональность, интеграции, ПО, сеть, железо, и как все это связано между собой.

Платформа, на которой функционируют наши интернет-магазины, выглядит так:

• front
• middle-office
• back-office

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

В идеале наблюдение за состоянием здоровья всей платформы нужно автоматизировать. И мы пришли к мониторингу как к неизбежной части этого процесса. Изначально он был построен только для фронтовой части, при этом собственные системы мониторинга по слоям были и есть у сетевиков, администраторов ПО и аппаратного обеспечения. Все эти люди следили за мониторингом только на своем уровне, комплексного понимания тоже ни у кого не было.

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

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

Структура системы и стек

Мы начали с того, что выделили несколько слоёв мониторинга для наших систем, в разрезе которых нам потребуется собирать метрики. И все это нужно было объединить, что мы и сделали на первом этапе. Сейчас по этому этапу мы дорабатываем максимально качественный сбор метрик по всем нашим слоям, чтобы выстраивать корреляцию и понимать, как системы влияют друг на друга.

Отсутствие комплексного мониторинга на начальных этапах запуска приложений (так как мы начали строить его, когда большая часть систем была в эксплуатации) привело к тому, что у нас образовался значительный технический долг по настройке мониторинга всей платформы. Сосредотачиваться на настройке мониторинга какой-то одной ИС и детально прорабатывать мониторинг для неё мы не могли себе позволить, так как остальные системы остались бы на какое-то время без мониторинга. Для решения этой задачи мы определили список самых необходимых метрик оценки состояния информационной системы по слоям и начали его внедрять.

Поэтому слона решили есть по частям.

Наша система складывается из:

• hardware;
• операционной системы;
• software;
• UI-части в приложении мониторинга;
• бизнес-метрики;
• приложения интеграции;
• информационной безопасности;
• сети;
• балансировщика трафика.

В центре этой системы собственно мониторинг. Чтобы в общем понимать состояние всей системы, надо знать, что происходит с приложениями на всех этих слоях и в разрезе всего множества приложений.

Так вот, про стек.



Используем ПО с открытым исходным кодом. В центре у нас Zabbix, который мы используем в первую очередь как систему алертинга. Всем известно, что он идеально подходит для мониторинга инфраструктуры. Что здесь имеется в виду? Как раз те низкоуровневые метрики, которые есть у каждой компании, которая содержит свой ЦОД (а у Спортмастера свои ЦОДы) температура сервера, состояние памяти, рейда, метрики сетевых устройств.

Мы интегрировали Zabbix с мессенджером Telegram и Microsoft Teams, активно используемыми в командах. Zabbix покрывает слой фактической сети, железа и частично ПО, но это не панацея. Мы эти данные обогащаем из некоторых других сервисов. Например, по уровню аппаратного обеспечения мы напрямую по API коннектимся в нашей системе виртуализации и забираем данные.

Что ещё. Помимо Zabbix мы используем Prometheus, который позволяет мониторить метрики в приложении динамической среды. То есть, мы можем получать метрики приложения по HTTP endpoint и не переживать по поводу того, какие метрики в нее загружать, а какие нет. На основании этих данных можно прорабатывать аналитические запросы.

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

Во-первых, это внешние бизнесовые системы, Google Analytics, собираем метрики из логов. Из них мы получаем данные по активным пользователям, конверсии и всему прочему, связанному с бизнесом. Во-вторых, это система UI-мониторинга. О ней следует рассказать более подробно.

Когда-то мы начинали с мануального тестирования и оно перерасло в автотесты функционала и интеграций. Из него мы и сделали мониторинг, оставив только основной функционал, и завязались на маркеры, которые максимально стабильны и не часто меняются со временем.

Новая структура команд подразумевает, что вся деятельность по приложениям замыкается на продуктовых командах, поэтому чистым тестированием мы заниматься перестали. Вместо этого мы из тестов сделали UI-мониторинг, написанный на Java, Selenium и Jenkins (используется как система запуска и генерации отчетов).

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

Наконец, в-третьих, источником данных является централизованная система логирования. Для логов используем Elastic Stack, а потом эти данные можем затягивать в нашу систему мониторинга по бизнес-метрикам. В дополнение ко всему этому работает наш собственный сервис Monitoring API, написанный на Python, который опрашивает по API любые сервисы и забирает в Zabbix данные из них.

Еще один незаменимый атрибут мониторинга визуализация. У нас она строится на основе Grafana. Среди прочих систем визуализации она выделяется тем, что на дашборде можно визуализировать метрики из разных источников данных. Мы можем собрать верхнеуровневые метрики интернет-магазина, например, количество заказов, оформленных за последний час, из СУБД, метрики производительности ОС, на которой запущен этот интернет-магазин, из Zabbix, а метрики инстансов этого приложения из Prometheus. И все это будет на одном дашборде. Наглядно и доступно.

Отмечу про безопасность мы сейчас допиливаем систему, которую впоследствии будем интегрировать с глобальной системой мониторинга. На мой взгляд, основные проблемы, с которыми сталкивается e-commerce в сфере информационной безопасности, связаны с ботами, парсерами и брутфорсом. За этим нужно следить, потому что они все это может критично повлиять как на работу наших приложений, так и на репутацию с точки зрения бизнеса. И выбранным стеком мы эти задачи успешно покрываем.

Ещё важный момент уровень приложений собирается Prometheusом. Сам он он у нас тоже интегрирован с Zabbix. И ещё у нас есть sitespeed, сервис, который позволяет нам соответственно смотреть такие параметры, как скорость загрузки нашей страницы, боттлнеки, отрисовка страницы, загрузка скриптов и прочее, он тоже по API интегрирован. Так метрики у нас собираются в Zabbix, соответственно, алертим мы также оттуда. Все алерты пока уходят на основные способы отправки (пока это email и telegram, ещё подключили недавно MS Teams). В планах прокачать алертинг до такого состояния, чтобы умные боты работали как сервис и предоставляли информацию по мониторингу всем желающим продуктовым командам.

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



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

И с помощью метрик мы видим тенденцию потребления ресурсов нашими информационными системами. И уже на их основании можем что-то планировать. На уровне виртуализации мы собираем данные и видим информацию по доступному количеству ресурсов в разрезе ЦОДов. А уже внутри ЦОДа видна и утилизация, и фактическое распределение, потребление ресурсов. Причем как со standalone-серверами, так и виртуальными машинами и кластерами физических серверов, на которых все эти виртуалки бодро крутятся.

Перспективы

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

Наша задача в конечном счете сделать правильные алерты. Например, если случилась проблема с аппаратной частью, опять же, с виртуальной машиной, а там было важное приложение, и сервис был никак не зарезервирован. Мы узнаем, что виртуальная машина умерла. Затем будут алертить бизнес-метрики: пользователи куда-то пропали, конверсии нет, UI в интерфейсе недоступен, ПО и сервисы тоже умерли.

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

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

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

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

Помимо мониторинга по системам, которые мы эксплуатируем, и сбора метрик, которые на нашей стороне расцениваются как важные, система мониторинга позволяет собирать данные для продуктовых команд. Они могут влиять на состав метрик в рамках информационных систем, которые мониторятся у нас.

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

Так как мы вне потока создания ценностей команды, их релизов и планирования, мы постепенно приходим к тому, что релизы всех систем бесшовные и их можно выкатывать ежедневно, не согласовывая при этом с нами. А нам важно отслеживать эти релизы, потому что потенциально они могут повлиять на работу приложения и что-то сломать, а это критично. Для управления релизами мы используем Bamboo, откуда по API получаем данные и можем видеть, какие релизы в каких информационных системах вышли и их статус. И самое важное в какое время. Маркеры о релизах мы накладываем на основные критичные метрики, что визуально является весьма показательным в случае проблем.

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

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

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

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

Предыстория

Последние пару лет рынок систем мониторинга будоражила аббревиатура AIOps. Все вендоры начали гнаться за использованием искусственного интеллекта в своих сложных и дорогих системах. Термины root cause analysis, correlation, ML-tools, anomaly detection, incident prediction, noise reduction основательно и, наверное, уже навсегда поселились на маркетинговых материалах и сайтах различных систем мониторинга.

Как мы знаем, рекламные буклеты одно, а инженерные будни другое. Наверное, многие сталкивались с ситуацией, когда обещания продавцов тех или иных технологических новинок сталкивались, как Титаник с айсбергом, с практикой внедрения, особенно в сложном ИТ-окружении больших компаний. Поэтому я изначально смотрел с большим скепсисом и не разделял ажиотажа вокруг этой темы. Тем более, когда есть такие железобетонные решения как Zabbix, Prometheus и Elastic. Но хайп хайпом, скепсис скепсисом, а мы все-таки инженеры и должны все проверять и изучать на практике, а не задаваться вопросом верить/ не верить в magic button от именитых вендоров и многообещающих стартапов. И вот, после очередной презентации от интегратора и обещаний за немаленькие деньги рая на нашей грешной земле инженеров эксплуатации нас собралась небольшая инициативная группа, которая решила пощупать, что все-таки из себя представляет эта магия искусственного интеллекта и машинного обучения в нашей практике. Таким образом, родились материалы и даже небольшой pet-проект, которыми я бы хотел поделиться с вами.

Жизненная проблема служб мониторинга

Самая распространенная проблема систем мониторинга это адский шум, которые они создают при своей работе. От потока генерируемых сообщений захлебываются все дежурные службы. И в какой-то момент инженеры начинают воспринимать этот шум как обычное явление и перестают обращать внимание на очередную мигающую красную плашку. Результат всегда один и тот же: красное лицо и опущенные в пол глаза начальника службы мониторинга на совещании у ИТ-директора. Следующий раунд это более умные настройки типа три подряд проваленные проверки, триггерные зависимости и т.п. Это помогает, но возрастает риск пропустить проблему и все равно приходиться начинать свой день с просмотров графаны и кибаны, этих вечных спутниц системного администратора. Иначе опять красное лицо.

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

Для данной статьи далее приводятся результаты наших наработок на реальных открытых данных. В качестве таких данных мы взяли HTTP-проверки сайтов основных ритейлеров. Самая яркая выборка получилась у Магнита, отдельное ему спасибо за это. Кстати, на downdetector его нет, а, наверное, стоило бы добавить ;)

Классика

Для нашего примера берем интервал времени
2020-10-14 14:00 +03:00 минус 38 часов (ранее данных не было), т.е. [2020-10-12 23:00:00 +03:00 2020-10-14 14:00 +03:00]. За этот период всего прошло проверок: 3612.

Если брать стандартный алгоритм оповещения по порогам (threshold), который формирует оповещение, если предыдущее значение было 0, а текущее 1, то на такой выборке сформировалось бы 179 оповещений. При этом имеем самую высокую оперативность в оповещении о проблемах (см. рис. 1: распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным оповещения
).

Рис. 1. Распределение оповещений по классическому пороговому алгоритму. Время в UTC. Синим показаны проваленные проверки, красным оповещения.

Если использовать алгоритм вычисления порога данных, при котором оповещение приходит только в случае проваленных подряд 3-х проверках, то по данной выборке сформировалось бы 44 оповещения (см. рис. 2). При этом задержка алерта уже составит как минимум 4 интервала проверки. Также мы рискуем напороться на проблему отсутствия алерта для ряда вида 0110010011101010, которую, можно частично решить, установив дополнительный триггер на % проваленных за период времени (обычно 1 час), что опять-таки приведет к потере оперативности.

Рис. 2. Распределение оповещений по 3-м проваленным подряд проверкам. Синим показаны проваленные проверки, красным оповещения.

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

А что ML?

Прежде чем пойдем дальше, сразу бы хотелось оговориться, что мы не являемся Data Scientist и перед нами не стояла задача выбора оптимального метода. Наша задача заключалась в том, чтобы, во-первых, найти любой метод, который соответствовал 3-м критериям:

1. Давал бы практическую пользу. В нашем случае реально бы снижал количество алертов, при этом не пропуская проблемы.
2. Был бы реализуем без серьезных вычислительных затрат, и, соответственно, его можно было бы встроить в пайплайн обработки собираемых метрик.
3. Результаты, получаемые на выходе, можно было бы "качественно" интерпретировать и предсказать. Т.е. по сути метод должен быть достаточно простым и хотя бы "на ощупь" понятным без глубокого погружения в теорию вероятности, нечеткую логику и прочие радости высшей математики, частично подзабытые с университетской скамьи.

В нашем случае таким методом стал DetectIidSpike из библиотеки ML.NET. Основная идея данного метода: проверить укладывается или нет каждое новое значение на временном ряде в существующую выборку. Если не укладывается, то обозначить такое значение как аномалию. Другими словами для каждого нового значения проверяется "нулевая" гипотеза и если она подтверждается, то детектируется аномалия. После чего новое значение переобучает модель.
Отсюда очень важным для нормальной работы метода DetectIidSpike являются его два параметра:

• confidence достоверность обнаружения аномалии в диапазоне [0, 100]. Чем больше значение, тем по сути шире полоса и, соответственно, тем больше значений будут восприниматься, как нормальные;
• pvalueHistoryLength размер скользящего окна для вычисления p-value. Данный критерий как раз-таки используется в алгоритме для подтверждения "нулевой гипотезы", она же аномалия.

Теперь посмотрим, как данный алгоритм работает на практике. В рассматриваемом примере у нас HTTP-проверки сайтов, т.е. на выходе имеем единицы и нули. Для нашего алгоритма это вот не совсем подходящий материал. Здесь желательно иметь дело все-таки не с бинарными значениями. Для этого мы применили агрегацию данных по временным интервалам, т.е. превратили нашу последовательность из нулей и единичек на интервале 5 мин в число: отношение проваленных проверок к общему количеству проверок в этом интервале. Здесь велико было искушение взять просто количество проваленных, но это в корне неправильно, т.к. соседние интервалы могут отличаться по количеству проверок. Это может происходить как по причине динамических настроек проверок (например, при проблеме чаще идут проверки), так и по банальной причине задержек в проверках и пограничных "конфликтах", когда проверки попадают в соседние интервалы.

После этих подготовительных операций мы потоково направляем получаемые данные в наш прототип детектора аномалий в виде заданий. Стратегия запуска задания заключается в том, чтобы загрузить модель, рассчитанную в предыдущем раунде проверок, проверить является ли значение пиком (аномалией), провести дообучение модели полученным значением и сохранить измененную модель обратно на диск (или в память). Для этого наш планировщик раз в 5 мин формирует список заданий на вычисление в детекторе аномалий. Агенты, подключенные к планировщику по websockets протоколу, получают задания и выполняют их. На выходе мы имеем аномалии и оповещения, а сама система агентов очень легко масштабируется (у нас kubernetes реплики).

На приведенной выборке при настройках алгоритма (confidence: 95, pvalueHistoryLength: 5), мы в итоге получили 36 аномалий. Следует учитывать, что аномалией считается также резкое снижение количества проваленных проверок, т.е. за аномалии принимается восстановление работоспособности. Отфильтровав сообщения о восстановлении, имеем итоговые 24 оповещения. (Кстати, метод в библиотеке имеет соответствующую настройку).

Рис. 3. Аномалии и проваленные проверки (confidence: 95, pvalueHistoryLength: 5) Синим показаны относительные значений проваленных проверок, красным оповещения

Как видно из графика (рис. 3), при недостаточном уровне обучения модель генерировала большое количество аномалий вначале, которое значительно сократилось на последующем интервале после достаточного обучения. А также, что имеет первостепенное значение, не были упущены практически никакие проблемы и полученный детектор аномалий достаточно оперативно реагировал на возникающие провалы (закрашенные области).

Для сравнения на рис. 4 приведен результат работы модели со скользящим окном pvalueHistoryLength=12 и достоверностью confidence: 98. Здесь результат: 14 аномалий.

Рис. 4. Аномалии и проваленные проверки (confidence: 98, pvalueHistoryLength: 12)

Краткий вывод

Таким образом, применяя метод DetectIidSpike нам удалось снизить количество оповещений практически в два раза (24 против 44) по сравнению с проверкой на 3 подряд проваленные проверки, и в 7,5 раз (24 против 179) с однократным трешхолдом. При этом, самое главное, не теряя в качестве и оперативности. А это говорит нам о том, что методы ML могут нам действительно на практике помочь в задачах мониторинга. По крайней мере, приведенный метод точно :)

P.S.: Если у вас есть идеи или конкретные методы ML, которые вы опробовали для решения проблемы флуд-алертинга, пишите в комментариях. Будет интересно попробовать.

P.P.S.: Ниже приведу еще несколько скриншотов из нашего pet-проекта с реальными данными проведенных проверок и сгенерированных аномалий. Можете посмотреть насколько эффективно или неэффективно (for whom how) работает алгоритм (желтый кружок аномалии на выбранном интервале).

Всем привет! Меня зовут Дмитрий, я релиз-инженер вкоманде CI/CD Speed Авито. Вот уже несколько лет мы сколлегами отвечаем за всё, что связано срелизами наших мобильных приложений и не только. Впрошлый раз я рассказывал онашей системе релизов мобильных приложений наоснове контракта. Сегодня речь пойдет отом, как мы автоматизировали сбор информации изFirebase оновых фатальных ошибках вмобильных приложениях.

Проблематика

Впроцессе написания программ неизбежно возникают ошибки. Некоторые изних могут быть фатальными и приводить ккрашу приложения. Длясбора, анализа и исправления таких ошибок используются специальные системы мониторинга.

Раньше, как и многие нарынке мобильных приложений, мы использовали Fabric, длякоторого vadimsmal и YourDestiny написали очень удобный клиент Fabricio. Набазе этого клиента унас была создана система мониторинга, которая заводила Jira-задачи нановые фатальные ошибки, искала ответственных поGit-Blame и сообщала обошибках вcпециальный слак-канал.

Нокомпания Google решила прекратить развитие проекта Fabric, объявила дату закрытия и предложила всем желающим мигрировать наих платформу Firebase, что мы благополучно и сделали.

Система автоматического мониторинга крашей перестала работать, и нам пришлось возвращаться кпостоянному ручному мониторингу. Припервичном изучении документации выяснилось, что уFirebase нет публичного API дляполучения необходимой информации, и придётся искать обходные пути.

Получаем данные

Google Cloud Functions

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

Исследование документации Firebase привело нас кGoogle Cloud Functions или же облачным функциям. Это serverless FaaS отGoogle, который позволяет запускать ваш код воблачной инфраструктуре Google. УFirebase-Crashlytics есть встроенная интеграция соблачными функциями (намомент написания статьи данная функциональность помечена как deprecated). Вы можете написать call-back наодин изтрёх crashlytics-ивентов и дальше обрабатывать его как вашей душе угодно. Особенно нас интересуют два ивента onNew(новое событие crashlytics) и onVelocityAlert (резкий рост события crashlytics).

Вголове сразу же родилась схема. Настраиваем интеграцию Firebase-Google Cloud Functions, шлём оттуда все новые краши сразу всвой сервис, и там уже обрабатываем. Берём пример издокументации, вносим несколько доработок и получаем следующий код наJS который загружаем вGoogle Cloud:

const functions = require('firebase-functions');const rp = require('request-promise');function sendEvent(event) {    return rp({        method: 'POST',        uri: functions.config().crashlytics.crash_collector_url,        body: event,        json: true,    });}exports.NewIssueEvent = functions.crashlytics.issue().onNew(async (issue) => {    await processEvent(issue, 'NewIssueEvent')});exports.RegressedEvent = functions.crashlytics.issue().onRegressed(async (issue) => {await processEvent(issue, 'RegressedEvent')});exports.VelocityAlertEvent = functions.crashlytics.issue().onVelocityAlert(async (issue) => {await processEvent(issue, 'VelocityAlertEvent')});const processEvent = async (event, type) =>{    if (isActualEvent(event)) {        await sendEvent(event);        console.log(`Posted ${type} ${event.issueId} successfully to crash collector`);    }    else{        console.log(`It's old event or not Avito. Do nothing`);    }}const isActualEvent = (event) =>{    const {appInfo} = event;    const {appName, latestAppVersion} = appInfo;    const version = latestAppVersion &&  parseFloat(latestAppVersion.split(' ')[0]);    console.log(`Event appName: ${appName} version: ${version}`);    return appName === 'Avito' && version > 60.0}

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

Но втекущей реализации нам не хватает данных. ВFirebase-Crashlytics есть fatal события (собственно фатальные ошибки-краши) и non-fatal (остальные события которые по той или иной причине логируются в crashlytics). Все летящие кнам ивенты насобытие onNew не имеют признака фатальности, ктому же нам хотелось как-то фильтровать события поколичеству затронутых пользователей и частоте возникновения, но этой информации всобытиях нет.

BigQuery

Google позволяет экспортировать данные изFirebase вBigQuery. BigQuery облачное хранилище, предоставляющее удобную платформу дляхранения и обработки данных. На момент исследования всередине 2019года был доступен только один тип синхронизации cFirebase Batch Table.

Нужно отметить ключевые особенности данного типа синхронизации:

1. Синхронизация происходит раз всутки, приэтом нет гарантии, когда она будет завершена.
2. Нельзя настроить тип экспортируемых событий экспортируется и fatal и non-fatal.
3. Чем дольше живёт таблица, тем больше вней данных (ваш кэп) и тем дороже стоят услуги хранения.

Дорабатываем изначальную схему:

После получения ивента внашем сервисе идём вBigQuery и получаем недостающую информацию: признак фатальности, число задетых пользователей и так далее. При этом запросы кBigQuery отправляем не накаждый новый ивент, а периодически. Длянас оптимальная частота запросов раз вдень после 17:00, так как заэто время выгрузка данных изFirebase-Crashlytics вBigQuery успевала завершиться, и можно было получить информацию повсем необработанным ивентам простым запросом:

SELECT issue_id, is_fatal, COUNT(*) as crashes_counter, COUNT(DISTINCT installation_uuid) AS affected_users FROM `android.firebase_crashlytics.{table}` WHERE issue_id in ( {issues_id_string} ) GROUP BY issue_id, is_fatal LIMIT 1000

Внимательный читатель может заметить, что тут образовывается временной лаг между фактическим появлением краша и получением нами информации онём. Чтобы не пропускать редкие, но действительно важные краши, которые резко растут и задевают сразу много пользователей, унас по-прежнему оставалось событие onVelocityAlert вGoogle Cloud Function. Подокументации это событие вызывается исключительно нафатальные ошибки вработе приложения, если ошибка привела ксбою N сеансов пользователей запоследний час. Пофакту же onVelocityAlert не работало, мы зарепортили это вGoogle, нас внесли вовнутренний трекер, и наэтом всё.

Слак

Нас вполне устраивал временной лаг приполучении обычных фатальных ошибок, но совсем не хотелось пропустить пожар. Впоисках возможности получения VelocityAlert мы пришли кинтеграции Firebase-Crashlytics и слака. Вконсоли Firebase вы можете достаточно просто и быстро настроить отправку событий вопределённый слак-канал, втом числе событий VelocityAlert. Это было почти то, что мы искали. Интеграция позволяла оперативно получать информацию отом, что всё плохо, но приэтом нельзя было фильтровать события поверсии. Витоге канал больше напоминал свалку.

Тогда мы решили использовать канал ссырыми VelocityAlert как источник данных длясервиса. Слушать этот канал, подтягивать изнего новые сообщения сVelocityAlert и уже науровне сервиса фильтровать.

Новая схема выглядела так:

Обрабатываем данные

Систочником данных вроде определились. Теперь нужно эти данные обрабатывать.

Напомню, что наша старая система наFabric делала сданными окрашах:

1. Искала ответственного поGit-Blame.
2. Создавала задачу наисправление.
3. Оповещала оновом событии в специальный слак-канал.

Первое отчего мы решили отказаться это автоматическое создание задачи и поиск ответственного поGit-Blame. Поопыту, автоматически созданные задачи отправлялись накладбище Jira, и кним редко кто возвращался, а поиск поGit-Blame иногда давал сбой, что ещё больше повышало шансы забыть задачу. А вот оповещения вслак мы решили развивать, этот канал коммуникации показал себя наиболее эффективным.

Обработку решили реализовать набазе сервиса мобильных релизов Nupokati. Он собирает информацию поновым крашам, раз вдень покрону запрашивает дополнительные данные изBigQuery, фильтрует краши пофатальности и частоте возникновения нас не интересуют единичные сбои и отправляет daily report вслак поактуальной версии приложения.

Пример daily report

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

Помимо daily report мы отлавливаем VelocityAlert дляактуальной версии и тут же репортим опожаре вслак-канал и ответственному законкретный релиз инженеру. Втреде определяется, насколько взрыв фатален, и что сним делать.

Google Cloud Functions всё

Около года мы успешно эксплуатировали новую систему автоматического сбора и алертинга фатальных ошибок вмобильных приложениях. Уже практически забыли, как заходить вFirebase и смотреть краши. Как вдруг было объявлено, что интеграция Firebase-crashlytics и Google Cloud Functions deprecated и её работа будет приостановлена 1октября 2020года. Нужно было оперативно дорабатывать решение и отказываться отоблачных функций. Приэтом хотелось обойтись минимальными изменениями вработающей системе.

Так мы просто убрали Cloud Functions и доработали запрос наполучения данных изBigQuery. Вся остальная система осталась прежней: daily report, velocityAlerts, фильтры поколичеству задетых пользователей и слак-каналы. Новый запрос получает сразу все уникальные краши понужной версии и отправляет их впоток обработки.

SELECT issue_id, issue_title, is_fatal, COUNT(issue_id) as crashes_counter, ARRAY_AGG (distinct application.display_version) AS versions, COUNT(DISTINCT installation_uuid) AS affected_users FROM `android.firebase_crashlytics.{table}`WHERE is_fatal=true GROUP BY issue_title, issue_id, is_fatal HAVING ARRAY_LENGTH(versions)=1 AND "{version}" in UNNEST(versions)ORDER BY crashes_counter DESC

Итоги

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

Несколько советов тем, кто захочет повторить наш путь:

• Использование BigQuery платное, но есть песочница, вкоторой можно поэкспериментировать.
• Оптимизируйте запросы кBigQuery. Процессинг данных не бесплатный, он впрямом смысле имеет денежное выражение согласно тарифам.
• Дляоптимизации затрат нахранение данных вBigQuery уменьшайте время жизни таблиц, это есть внастройках. Длянас оптимальным отказался период жизни таблицы впять дней.
• Уже после создания нашей системы появился BigQuery streaming. Нанём можно собрать аналогичную систему или даже лучше.
• Внимательней читайте документацию кGoogle Cloud Platform. Это очень мощная платформа смножеством инструментов и возможностей.