Почему мы устали грепать логи: история создания Exlogare
Красный пайплайн в GitLab — не баг, а рутина: десятки тысяч строк лога, и только один человек знает, где искать. Зачем мы сделали Exlogare и почему верим, что триаж логов должен делать код, а не ночная смена.
Красный индикатор в merge request вы уже видели сотни раз. Открываете job в GitLab CI/CD, жмёте Browse у лога — и перед вами не «ошибка», а поток сознания инфраструктуры: ретраи, ворнинги сборщика, шум тестового раннера и где-то внизу одна строка, из‑за которой всё встало.
Мы много лет жили в этом цикле. Exlogare появился не как «ещё один дашборд», а как попытка убрать человека из роли живого grep там, где машина читает лучше.
Скрытый налог на разработку
Когда пайплайн падает, страдает не только релиз. Страдает фокус: senior-инженер или дежурный DevOps переключается с задачи, которую он реально хотел закончить, на охоту за сигналом в логе. Час ушёл — и это не «поиск корневой причины», это рутинный триаж: отделить флейк от регресса, кэш от сети, тест от инфраструктуры.
Такие часы редко попадают в roadmap. Их не видно в Jira, их не оценивают на планировании. Но они складываются в недели на уровне команды — и именно они делают CI/CD «тяжёлым», хотя пайплайны по определению должны ускорять поставку.
Сигнал вместо шума
Мы не верим в волшебную кнопку «ИИ всё починит». Мы верим в другое: лог — это сырьё, и его нужно готовить так же аккуратно, как метрики для алертинга. Сначала выкинуть повторяющийся шум, выделить окно, где реально упало, прогнать через слой, который умеет отличать классы ошибок — и только потом отдавать человеку короткий, проверяемый разбор (RCA), а не простыню на пять экранов.
Человеку нужен ответ на три вопроса: что сломалось, где смотреть и с чего начать фикс. Всё остальное — приложение к делу.
Как это выглядит с GitLab
Exlogare подключается к вашему GitLab по API: webhook, OAuth с опросом (polling) или комбинация — как позволяет ваш регламент безопасности. Когда пайплайн переходит в failed, мы забираем логи упавших job'ов, не храним сырой лог (обрабатываем в памяти и отбрасываем после анализа), публикуем структурированный RCA — в merge request, issue или в мессенджер (Slack, Telegram, Matrix), если так настроена маршрутизация.
Идея простая: разбор должен жить там, где команда уже обсуждает код, а не в отдельной вкладке, которую никто не пересылает.
Попробуйте на своём репозитории
Первые 20 автоматических разборов — без карты: подключите проект, специально «сломайте» пайплайн и посмотрите, как в MR появляется готовый к действию контекст. Если после этого захотите масштабировать на всю команду — загляните в тарифы или напишите нам.