Высокий уровень observability в наше время — такое же необходимое условие для любого проекта, как и высокая доступность или производительность. Мы стараемся собрать и сохранить максимум метрик, чтобы понимать, в каком состоянии находится наша система и куда это состояние дрейфует. Собираем максимум логов, чтобы понимать, что происходило. Но даже когда логов и метрик настолько много, что для них собираются свои логи и метрики, иногда этого бывает недостаточно. Иногда нужно понимать не ЧТО и КОГДА, а ПОЧЕМУ.

В мире Kubernetes такой источник есть — events: именно они отвечают, почему под перезапустился, почему не смог подняться, почему не встал на ноду. Парадоксально, но эти чрезвычайно важные сведения довольно неудобно извлекать, а по умолчанию через час они уже исчезают. С этим обычно мирятся — ровно до утра, когда нужно объяснить, почему ночью упали сборки. Дальше история одного такого утра: начинается она с двух неудачных пайплайнов, заканчивается часовым окном нестабильности, задевшим 46 namespace'ов, и ни одной улики к моменту расследования в кластере уже не остаётся.

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

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