Не так давно мы решили запустить свой собственный MCP-сервер для GoCD. Ну а что, у всех есть MCP, а у нас не было. И у GoCD не было такого, который бы подошел нам. Мы уже больше месяца им активно пользуемся. Сам проект тоже живет и развивается — его версия за это время выросла до 1.2.0: https://github.com/Ivinco/gocd-mcp

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

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

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

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

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