Релиз 202 Proto Observability Platform

Обновлено 31.07.2026
Версия 202 добавляет отчёты по электронной почте по расписанию, окна обслуживания с подавлением оповещений, отметки изменений и регламентных работ прямо на графиках, выгрузку трейсов в открытых форматах, оповещение о пропадании данных, флейм-граф трейса, анализ кардинальности метрик, улучшенный журнал аудита для служб информационной безопасности и приём ошибок из открытых Sentry SDK.

Дата выпуска: 07.31.2026

Приводим краткое описание нового функционала, доступного с этим релизом.

Новые возможности 🎉

✨ Отчёты по электронной почте

В платформе появился раздел Отчёты — вкладка раздела Дашборды и отчёты. Отчёт собирается из готового дашборда и приходит получателям на почту в виде PDF-документа — по расписанию или по нажатию кнопки.

Краткое описание возможностей:

  • Отчёт собирается из любого пользовательского дашборда: выбираются дашборд, отчётный период и список получателей.
  • Расписание отправки с указанием часового пояса, плюс отправка вручную в любой момент.
  • История отправок: когда отчёт уходил и с каким результатом.

./images/202-reports.png

Подробнее в руководстве Отчёты по электронной почте.

✨ Гибко настраиваемые окна обслуживания

Новый раздел Окна обслуживания в меню Инциденты и алерты позволяет заранее объявить период регламентных работ, чтобы плановые изменения не поднимали инциденты.

Краткое описание возможностей:

  • Режимы «Сейчас», «Однократно» и «Регулярно» с указанием часового пояса и даты окончания серии повторений.
  • Область действия окна: хосты, сервисы и бизнес-приложения (группы сервисов).
  • Предпросмотр охвата — ещё до сохранения видно, какие именно объекты попадут в окно.
  • Во время окна срабатывания по выбранным объектам не создают инциденты и не рассылаются по каналам оповещения, но остаются в истории алертов с пометкой «обслуживание» — аудит не теряется.
  • В списке алертов подавленные срабатывания помечены отдельным значком; в карточке видно, каким окном обслуживания вызвано подавление.

./images/202-maintenance-windows.png

Подробнее в руководстве Окна обслуживания.

✨ Отметки изменений и регламентных работ на графиках

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

Краткое описание возможностей:

  • Полоска отметок под графиком: релизы, развёртывания и другие изменения, попавшие в видимый интервал времени.
  • Полоса окна обслуживания на самом графике; регулярные окна показываются на весь период повторений.
  • Близкие отметки объединяются в группу со счётчиком — полоска остаётся читаемой на любом масштабе, а во всплывающей подсказке перечислены все события группы.

./images/202-chart-annotations.png

✨ Флейм-граф трейса

В детальном просмотре трейса появилась вкладка Флейм-граф: ширина блока пропорциональна длительности операции, а вложенность повторяет структуру вызовов.

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

./images/202-trace-flame-graph.png

Подробнее в руководстве Анализ трейсов.

✨ Выгрузка трейса в открытых форматах

В просмотре трейса появилось меню Экспорт: выбранный трейс сохраняется в файл в одном из открытых форматов — OTLP/JSON, Zipkin v2 JSON или Jaeger JSON.

Трейс можно приложить к обращению в поддержку, передать команде разработки или открыть в стороннем средстве анализа — данные остаются переносимыми.

Подробнее в руководстве Анализ трейсов.

✨ Анализ кардинальности метрик

В Обозревателе метрик добавлена вкладка Кардинальность — она показывает, что именно занимает место в хранилище метрик.

Инструмент помогает найти метки, «взрывающие» объём хранения (идентификаторы запросов, пользователей или сессий, попавшие в метки), до того как это скажется на скорости работы и месте на дисках.

./images/202-metrics-cardinality.png

✨ Улучшенный журнал аудита

Журнал аудита переработан в более мощный инструмент для службы информационной безопасности и для аудиторских проверок.

Краткое описание возможностей:

  • Отдельные потоки для изменений и доступа к данным, новые фильтры для быстрого доступа к важным событиям отказов доступа и изменений в системе.
  • Для изменений прав доступа и окон обслуживания видно состояние «до» и «после» с перечнем изменённых полей — понятно, что именно поменялось.
  • Экспорт событий в CSV и JSON.

./images/202-audit-log.png

✨ Оповещение о пропадании данных (No-Data)

Добавлено семейство встроенных правил «источник замолчал»: платформа замечает, что сервис или экземпляр приложения перестал присылать метрики, и поднимает оповещение. Правила собраны в отдельную группу No-Data и настраиваются как обычные правила алертинга.

✨ Приём ошибок из Sentry SDK

Платформа принимает ошибки напрямую из приложений, в которых уже используются открытые Sentry SDK (Python, JavaScript/Node.js, Java, Go, PHP, Ruby, .NET и другие). Чтобы начать отправлять ошибки в платформу, достаточно указать в SDK её адрес (DSN) — переписывать код приложения или менять библиотеку не нужно.

Краткое описание возможностей:

  • Подключение выполняется сменой одной строки настройки, приложение продолжает использовать привычный Sentry SDK.
  • Автоматическая группировка ошибок по типу и месту возникновения в коде.
  • Ошибки попадают в стандартный раздел Ошибки модуля APM — со стек-трейсами, сообщениями, счётчиками, первым и последним появлением и динамикой во времени.
  • Привязка к сервису — по ключу DSN или по тегам события.
  • Быстрый старт: анализ ошибок работает в первый же день, а полноценный трейсер для трейсов и метрик можно подключить к тому же сервису позже.

Подробнее в руководстве Приём ошибок из Sentry SDK.

✨ Виджет «Соты здоровья»

В конструкторе дашбордов появился новый тип виджета — «Соты здоровья»: плотная раскладка из шестиугольников, где каждая ячейка окрашена по состоянию объекта (здоров / предупреждение / критично / нет данных). Сотни объектов помещаются на один экран, проблемные видны сразу.

Виджет добавлен на встроенные дашборды платформы, встроенный дашборд «Обзор» переработан.

./images/202-overview-honeycomb.png

✨ Инциденты как источник данных для дашбордов

Данные модуля Инциденты доступны в конструкторе виджетов — можно собрать собственный дашборд надёжности и показывать его руководству или смежным командам.

Доступны количество инцидентов, открытые и решённые, разбивка по критичности, MTTR (среднее время до устранения), средняя и максимальная длительность, количество затронутых ресурсов и связанных срабатываний. Разрезы — по времени создания, состоянию (детектирование, диагностика, решение, закрытие), критичности и охвату влияния.

✨ Переход с дашборда в ресурсно-сервисную модель

На встроенных дашбордах объектов (сервисы, хосты, Kubernetes, базы данных, очереди сообщений и другие) в панели инструментов появилась кнопка РСМ. По клику открывается карточка ресурса — класс, жизненный цикл, критичность, атрибуты — и граф его прямых связей с переходом «Открыть в РСМ».

Раньше связь была односторонней: из ресурсно-сервисной модели можно было перейти на дашборд, а обратно — нет.

Подробнее в руководстве Ресурсно-сервисная модель.

✨ Переработанная панель «Детали записи» в Обозревателе логов

Панель детального просмотра записи лога полностью переработана — запись читается глазами, без ручного разбора JSON.

Краткое описание возможностей:

  • Шапка с уровнем важности, временем с точностью до миллисекунд, строкой «сервис @ хост» и копированием всей записи.
  • Вкладки «Поля» и «Исходный JSON»; текст сообщения вынесен в шапку и сворачивается.
  • Умное отображение сообщения: JSON форматируется и подсвечивается, JSON внутри текста разворачивается по кнопке, обычный текстовый лог получает сдержанную подсветку (уровень, класс HTTP-статуса, IP-адреса, результаты операций).
  • Наборы меток и теги вида ключ:значение раскладываются в читаемые пары; копирование всегда отдаёт исходную строку.
  • Поиск по полям записи.

./images/202-log-record-details.png

Подробнее в руководстве Обозреватель логов.

✨ Готовые дашборды для мониторинга GitLab и GitLab Runner

Добавлены встроенные дашборды GitLab и GitLab Runner — доступны в каталоге сразу после установки, без ручного импорта. В обоих есть переключатель между несколькими серверами или раннерами.

✨ Единый каталог источников «Инфраструктура»

Раздел Инфраструктура переработан в единый каталог.

./images/202-infrastructure-catalog.png

📖 Руководство по управлению сэмплированием трейсов

Добавлено руководство по управлению сэмплированием трейсов: как устроен отбор трейсов и приоритет сэмплирования, где настраиваются доля сбора, правила по сервисам и операциям и лимиты частоты (для трейсеров ProtoOBP и Datadog, а также Nginx), как принудительно сохранять трейсы критичных бизнес-процессов и как избежать потери спанов при сборке бизнес-процессов.

Подробнее в руководстве Управление сэмплированием трейсов.

Улучшения ✨

  • Разделы Алерты и Инциденты объединены в один пункт меню Инциденты и алерты — работа с оповещениями и разбор инцидентов больше не разнесены по разным местам интерфейса.
  • Добавлены встроенные правила алертинга RabbitMQ (12 правил).
  • В настройках канала оповещения по электронной почте появилась кнопка «Отправить тестовое письмо» — параметры почтового сервера проверяются сразу при настройке, а не в момент первой реальной тревоги.
  • Улучшено распознавание устройств в модуле Цифровой Опыт (DEM): добавлена классификация ботов — поисковые, скрейперы, SEO и отдельно AI-краулеры (GPTBot, ClaudeBot, PerplexityBot, Bytespider, краулеры Яндекса), а также распознавание встроенных браузеров мобильных приложений (поисковые приложения, мессенджеры, приложение Яндекса и другие) — трафик реальных браузеров теперь отделяется от трафика внутри приложений. Новые характеристики видны в секции «Устройство» карточки трейса и спана.
  • Каталог ресурсов ресурсно-сервисной модели фильтруется по тегам — в инсталляциях с большим числом ресурсов нужный срез (окружение, команда, критичность) отбирается без ручного поиска.

Инструкция по обновлению с версии 201

Для Заказчиков с single host инсталляцией

Необходимо использовать новый файл docker-compose-202.yaml.

В случае каких-либо сложностей обратитесь к основной инструкции по установке или к команде поддержки партнёра или вендора.

  1. Скачайте файл protoobp-backend-dist-singlehost-202.tar.gz:

    curl --header "PRIVATE-TOKEN:<your_token>" "https://git.proto.group/api/v4/projects/125/packages/generic/protoobp-backend-dist/202/protoobp-backend-dist-singlehost-202.tar.gz" --output protoobp-backend-dist-singlehost-202.tar.gz

    где <your_token> — ваш пароль, указанный в лицензионном сертификате, полученном ранее от вендора.

  2. Распакуйте содержимое архива в папку с существующей инсталляцией (по умолчанию /opt/protoobp):

    tar -xzvf protoobp-backend-dist-singlehost-202.tar.gz -C /opt/protoobp

  3. Команды ниже рекомендуется выполнять, переключившись на привилегированную учётную запись:

    sudo su

  4. Перейдите в каталог продукта (/opt/protoobp) и выполните pull новых образов:

    cd /opt/protoobp && docker compose -f docker-compose-202.yaml pull

  5. Важно (202). Удалите временные данные Kafka:

    rm -rf /opt/protoobp/data/kafka/*

  6. Важно (202). В версии 202 добавлены два сервиса отчётности — чтобы отчёты уходили получателям, задайте в файле .env параметры почтового сервера:

    POBP_REPORT_RUNNER_SMTP_HOST=                # адрес почтового сервера
POBP_REPORT_RUNNER_SMTP_USER=                # учётная запись отправителя
POBP_REPORT_RUNNER_SMTP_PASSWORD=            # пароль отправителя, секрет

    Других обязательных переменных нет: порт (587), режим TLS, адрес отправителя, таймауты и интервалы имеют рабочие значения по умолчанию. Без параметров почтового сервера платформа запустится штатно, но отчёты отправляться не будут.

    Служебная учётная запись отчётности заводится автоматически при старте, но её пароль одинаков во всех инсталляциях. В промышленной эксплуатации его следует перевыпустить и указать новое значение в .env переменной POBP_REPORT_RUNNER_KEYCLOAK_CLIENT_SECRET.

  7. Важно. При использовании собственных SSL-сертификатов раскомментируйте соответствующие строки для сервисов proto-nginx и proto-auth в docker-compose-202.yaml.

  8. Важно. При использовании настроек SSO раскомментируйте или измените соответствующие строки для сервиса proto-auth.

  9. Остановите предыдущую версию продукта:

docker compose -f docker-compose-201.yaml down
  1. Запустите новую версию продукта:
docker compose -f docker-compose-202.yaml up -d

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

При первом запуске автоматически применяются миграции хранилища версии 202 (окна обслуживания, отчётность, журнал аудита) — дополнительных действий не требуется.

Обратите внимание. Журнал аудита переведён на новую схему со сроками хранения 365 дней для изменений и 90 дней для обращений на чтение. Обновление выполняется без перезаписи данных: записи, накопленные в предыдущих версиях, сохраняются и хранятся 365 дней, но не содержат новых полей (состояние «до/после», категория события).

Для Заказчиков с multi host инсталляцией

Инструкции по обновлению будут предоставлены контактными лицами со стороны поддержки партнёра или вендора.