Релиз открытой платформы мониторинга ошибок и производительности Gotcha 1.0

В начале сентября 2026 года состоялся первый мажорный выпуск открытой платформы мониторинга ошибок и производительности Gotcha . Это self-hosted решение в одном Go-бинарнике: трекинг ошибок, распределённый трейсинг, метрики, логи, профилирование, мониторинг аптайма и серверов. Исходный код Gotcha опубликован на GitHub под лицензией Apache License 2.0.

Проект совместим со штатными Sentry SDK и принимает OTLP. Интерфейс, уведомления, шаблоны писем и документация решения подготовлены на русском и английском. Данные хранятся в PostgreSQL и ClickHouse. Минимальные требования к серверной части — 2 vCPU и 2 ГБ ОЗУ.

Основные изменения и доработки в Gotcha 1.0: контракт совместимости заморожен (1.0.0). С этого релиза только назад совместимо меняются: имена переменных окружения, адреса приёма и форматы тел запросов, схема миграций, формат бэкапов, имена self‑метрик без пометки «временная», тело исходящего вебхука, контракт GOTCHA_AGENT_* и адреса уже опубликованных статус‑страниц. Всё, что это нарушает, ждёт мажорной версии. До 1.0 контракт мог меняться между релизами, и об этом говорилось прямо; больше не может. Что в обещание намеренно не входит — внутренние пакеты, внешний вид интерфейса, имена счётчиков с пометкой «временный», — сказано там же, вместе со сроками депрекации по каждому пункту: Политика версионирования . Практический смысл для того, кто держит инстанс: обновление перестаёт быть событием, к которому готовятся — прочитать обновление , подтянуть образ, поехали; страница проектов организации больше не показывает чужие проекты (1.0.0). В предикате доступа сработал приоритет операторов — AND связывает сильнее OR, — из‑за чего ветвь «доступ через команду» оставалась без сужения по организации: тот, кто состоит в команде в другой организации, видел на /orgs/{id}/projects и её проекты. Права при этом не расширялись — каждый показанный проект пользователь и так мог открыть. Предикат заключён в скобки в самом объявлении, что защищает и два других запроса, которые из него собираются; три устаревших адреса приёма удаляются в 2.0, а не в 1.0 (0.37.0). /logs, /profiles/pprof и /api/{project}/deployments/ продолжают работать: те же заголовки, тот же счётчик, те же ответы — изменился только документированный срок удаления. Причина — собственная политика депрекации: между объявлением об устаревании и удалением обязан пройти минимум один мажорный релиз, а устаревшими их объявили 31 августа. Ломать чужие интеграции релизом, который называется «обещание стабильности», было бы странно.

• Тестирование IT-систем
• Тестирование веб-сервисов
• IT-инфраструктура