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

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

Долгое время основным инструментом мониторинга у нас был Nagios. Те, кто имеет опыт работы с ним, знают, что это хороший инструмент, но его GUI абсолютно не функционален. Поэтому мы использовали nagios API от проекта Zorkian и самописный GUI. У нас были вопросы по производительности и к API, и к нашему собственному GUI, однако в целом нам этого хватало. Но по мере роста количества проектов добавлялись новые системы мониторинга: Zabbix, Prometheus. А поскольку мы предоставляем услугу по поддержке 24/7, то нам крайне важно, чтобы дежурный инженер получал актуальную информацию о событиях с разных систем из разных проектов на одном экране. Так мы пришли к пониманию, что нам нужен алерт менеджер, который способен агрегировать  алерты из разных инструментов мониторинга.

Требования

Мы довольно четко понимали требования, которые выдвигали к алерт менеджеру. Во-первых, самое главное: он должен поддерживать одновременную работу с несколькими системами мониторинга, как минимум с Nagios, Prometheus, Zabbix. Во-вторых, он должен быть достаточно простым в развертывании и обслуживании. У нас нет ресурсов, чтобы выделить целую команду на систему мониторинга и управления алертами. В-третьих, графический интерфейс должен быть минималистичным и в то же время максимально информативным. На экране должно помещаться достаточное количество алертов, а их статус, уровень severity и основная информация должны восприниматься с первого взгляда. Должен обеспечиваться быстрый доступ к более подробной информации, а интерфейс не должен быть перегружен малозначимыми данными. Кроме того обязателен механизм группировки алертов по разным признакам и возможность  действий над группой алертов, таких как назначение ответственного инженера, постановка в список игнорирования, удаление и др. Должна присутствовать интеграция с разными системами оповещения (Slack, Telegram, звонки на мобильные номера). Большим бонусом будет наличие механизма хранения исторических данных и возможность получения статистики по алертам. Ну и при всем при этом желательно, чтобы это было open source решение, ну или хотя бы продукт с небольшой ценой.

Поиски

В первую очередь мы, естественно, начали исследовать существующие системы, которые могли бы удовлетворить всем нашим требованиям.  Мы рассмотрели следующие продукты: AlertOps, Opsgenie, BigPanda, Freshworks Freshastatus, Grafana, Liongard, OnPage, PagerDuty, Splunk-On-Call, xMatters. Я не буду здесь подробно разбирать по критериям каждый из этих продуктов. Но по ряду причин нам не подошел ни один из них. И вовсе не потому, что они недостаточно хороши и мы решили, что способны сделать что-то лучше. Это все зрелые продукты, над которыми работают большие команды. Но по тем или иным причинам нам они не подошли. Где-то хромала интеграция с разными системами, какие-то инструменты в целом решают другие проблемы. Интерфейс некоторых из них не удовлетворял нашим требованиям в части минималистичности и информативности. Большую часть из этих инструментов довольно тяжело интегрировать в уже действующую инфраструктуру без внесения правок в системы мониторинга и существующие алерты. Можно еще придумать какие-то причины, но в целом это все сравнение выглядело так, что все большие продукты - это контейнеровозы, которые бороздят просторы мирового океана и обслуживаются сотней членов экипажа. Нам же нужна лодка. Просто лодка.

Решение

Не найдя подходящей лодки, мы решили собрать свою собственную. Так родился проект Tenis — Team Event Notification and Interoperability System. Вообще-то, поскольку мы планировали создавать его в виде подключаемых модулей, название было Pluggable Event Notification and Interoperability System, но аббревиатура получалась совсем неприличной.

Tenis представляет из себя несколько элементов. Ядро системы — бэкенд модуль. Это Python приложение, которое в качестве хранилища использует MongoDB. Он управляет алертами, принимая их от источников, сохраняя в базе и передавая в веб-интерфейс пользователей. Также здесь сосредоточена логика по эскалации событий до непосредственного оповещения инженеров через мессенджеры или голосовой звонок. Алерты собираются плагинами. На сегодняшний момент в разработке находятся плагины под Nagios, Prometheus и Zabbix. Это небольшие самостоятельные приложения, которые получают алерты от систем мониторинга, преобразовывают их под единый формат и отправляют на бэкенд. Они могут располагаться отдельно от бэкенда, а их количество не ограничено. Таким образом мы решили вопрос с тем, чтобы собирать алерты из разных проектов, разных компаний в одну панель мониторинга. Также с помощью плагинов осуществляется обратное взаимодействие с системами мониторинга, если нужно выполнить, например, повторный запуск чека или получить новое значение метрики. Согласно идеологии приложения, которую мы в него вкладываем, мы стремимся к тому, чтобы модули не зависели от нашего бэкенда в технологическом плане. Коммуникация между ними осуществляется посредством API. И, потенциально, пользователи должны иметь возможность писать свои собственные плагины и свободно подключать их к системе.  Так, например, наш плагин для связи с Nagios написан на Python, а для работы с Prometheus – на Go.

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

Технологический стек мы выбирали по двум критериям – минимальная достаточность и уровень компетенций. Поскольку в своей ежедневной практике мы чаще всего работает с Python и Go, то именно эти языки и были выбраны для реализации проекта. Был еще вариант написать все на Bash, но вроде бы как принцип гуманизма уже окончательно утвердился во всех  самых распространенных идеологиях, поэтому от такого варианта мы отказались сразу.

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

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

Внешний вид

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

Алерты визуально с помощью цвета отображают уровень severity, что помогает моментально оценивать обстановку, и содержат только необходимый минимум информации: проект, к которому относится конкретный алерт, имя хоста или instance, на котором он сработал, ответственного инженера, если он назначен, имя алерта, время срабатывания и краткое описание сути проблемы. 

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

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

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

Заключение

Таким образом, с помощью проекта Tenis мы надеемся сделать работу по мониторингу и реагированию на инциденты максимально простой и удобной. Это очень простой, минималистичный инструмент, который полностью покрывает наши потребности. На данный момент проект находится на ранней стадии разработки и готовится к первому этапу альфа-тестирования. После того, как Tenis будет испытан в реальных рабочих процессах, будет собрана и обработана обратная связь от наших инженеров, мы планируем выставить его в Open Source. Кому, кроме нас, он может пригодиться? Нам кажется, что это будет прекрасный инструмент для небольших команд поддержки, для команд, которые обслуживают несколько независимых друг от друга инфраструктур. Для тех, кому не нужно 90% функционала, предлагаемого большими продуктами. Наверное, кто-то скажет, что мы изобретаем собственный велосипед. И, возможно, будет прав. Но в конце концов мы можем себе позволить его сделать, и нам это нравится. К тому же, велосипед - не такое уж и плохое средство для передвижения в случае, если вам нужен именно он. Ну или лодка.