Возьмём типичный отчёт воронки интернет‑магазина: «Каталог → Товар → Корзина → Оформление заказа → Оплата». До последнего шага дошло 38% сессий, остальные 62% потерялись между «Оформлением» и «Оплатой». Для продуктовой аналитики эти 62% — повод для гипотезы «форма оформления слишком длинная» и задачи на редизайн. Для команды разработки те же 62% — конкретная JavaScript ошибка. Но пока данные о конверсии и данные об ошибках лежат в разных системах, выбор между ними происходит наугад. Как перестать «угадывать» почему отвалились пользователи и какую в этом роль играет Customer Journey Map разберу в статье.

Трейс ИИ-агента можно открыть в обычном "дереве" и найти медленный вызов или спан с ошибкой. Но по дереву трудно восстановить логику запуска: сколько раз агент обращался к модели, какие инструменты вызывал, где повторил шаг и какой ответ в итоге увидел пользователь.

В Proto Observability Platform уже были дерево, граф, флейм-граф и другие представления трейса. Они продолжали решать инфраструктурные задачи, но ответы о поведении агента приходилось собирать вручную из десятков спанов, транспортных вызовов и повторяющихся тел сообщений. Мы увидели это сначала на OpenTelemetry Demo 3.0, затем при отладке собственного «AI-аналитика» в связке с нашим MCP-сервером.

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

Вызов инструмента ИИ-агентом легко теряется между моделью, MCP-клиентом, сервером и внешним API. В конце июля сразу два события показали, каким способом индустрия собирается решать эту проблему. Новая спецификация MCP закрепила передачу W3C Trace Context и начала выводить собственный механизм логирования из протокола в пользу OpenTelemetry. Одновременно сообщество OpenTelemetry назвало наблюдаемость ИИ-агентов одним из следующих направлений развития проекта. Разбираемся, что уже стало частью стандартов, что пока остаётся дорожной картой и почему эти события стоит рассматривать вместе.

Для проверки сквозного трейсинга GenAI-приложения мы взяли OpenTelemetry Demo 3.0. В обновлённом стенде уже были сервисы chatbot, agentи mcp, а также ИИ-спаны. Оставалось направить телеметрию по OTLP в ProtoOBP и открыть готовую цепочку вызовов. Но все спаны приехали, а единой истории не получилось: один пользовательский запрос распался на два трейса на границе MCP.

Автоматическая HTTP-инструментация связь не восстановила. Мы проследили traceparent до MCP _meta, нашли место потери контекста и добавили небольшой слой над ClientSession. После исправления цепочка собралась в единый трейс из 27 спанов.

В статье покажем исходный разрыв, код исправления и проверку результата по клиентскому и серверному спанам и карте связей.

Спросите себя, что было результатом расследования сбоя десять лет назад, пять, год. Ответ будет примерно одинаковый – скриншот графика в рабочем чате и фраза «похоже, это база». Давайте посмотрим, что поменялось в 2026-м и как выглядит разбор аварии с помощью ИИ-агента.

В данной статье я хочу рассказать про то, как технически устроены бот-атаки типа парсинг цен на e-commerce сайтах, какие механизмы используют атакующие, как противостоять бот-атакам самостоятельно и с помощью прикладных решений. 

Я поделюсь практическим опытом нашей компании в защите e-commerce приложений и продемонстрирую реальные кейсы противодействия парсинга и бот-атакам. 

В рамках статьи я сосредоточусь на атаках, которые относятся к типу Scraping по классификации OWASP. Детальную классификацию автоматизированных угроз веб-приложениям можно изучить в документе OWASP Automated Threats to Web Applications. Конечно, противодействие бот-атакам данного типа позволит остановить и другие автоматизированные атаки, но в нашей практике мы видим, в основном, именно атаки типа price scraping – автоматизированный сбор информации о товарах и ценах, или парсинг цен. Я не рассматриваю юридические и морально-этические вопросы парсинга цен в данной статье.

Всем привет! За последние пять лет мы достаточно часто сталкивались с запросами на мониторинг Java приложений. Собрав основные моменты по мониторингу Java, мы решили написать данный пост.

Сегодня мы с вами рассмотрим, что такое Full Stack мониторинг и чем он отличается от привычного “уху” понятию мониторинга, нюансы Full Stack мониторинга для Java и сложности мониторинга микросервисных приложений на Java. Расскажем, как мы реализуем Full Stack мониторинг с помощью OpenSource стандартов и платной платформы. 

Давайте определимся, что мы называем Full Stack мониторингом?

Full stack мониторинг – это подход в мониторинге производительности приложений, который подразумевает под собой мониторинг всего стека, что включает в себя:

Мониторинг приложений – сбор метрик приложения, сбор трейсов транзакций, обеспечение видимости на уровне кода и т.д.

Мониторинг инфраструктуры – метрики хостов, процессов, контейнеров и т.д.

Мониторинг конечных пользователей – сбор метрик с браузера пользователя, мобильного приложения, синтетические проверки и т.д.

Привет, друзья! Приглашаем на вебинар, посвященный продукту для углубленного мониторинга баз данных – DBmarlin, который:

– контролирует производительность баз данных – MySQL, MariaDB, PostgreSQL, Oracle, MS SQL Server, развернутых как в своей инфраструктуре, так и у облачного провайдера (AWS, Azure);

– предоставляет детальную видимость работы серверов, на которых развернуты БД;

– собирает statements и wait states, благодаря чему вы видите, на что именно тратится время внутри БД во время исполнения SQL запроса;

– автоматически обнаруживает изменения в объектах схемы БД, параметрах БД, собирает планы выполнения запросов, чтобы вы видели их влияние на производительность.

- регистрирует релизы и другие события для анализа их влияния на БД.

При возникновении проблемы с запросом к БД, инструменты мониторинга и APM, не специализирующиеся на БД, покажут вам SQL-запрос в трейсе, который долго исполнялся. Все, что вы сможете увидеть – это текст SQL запроса и длительность его исполнения. Причина, по которой он был таким медленным остается неизвестной. DBmarlin покажет, в чем именно была проблема в БД - вы увидите, например, что вызывает блокировку.

На вебинаре мы покажем и расскажем:

– Какие задачи должен решать современный продукт для мониторинга баз данных?

– Кто выигрывает от улучшения мониторинга СУБД (спойлер – не только DBA).

– Что отличает продукт DBMarlin от конкурентов?

Регистрация доступна прямо на этой странице ниже или по ссылке.

Сегодня мы хотим обсудить практическую сторону внедрения концепций Service Level Objectives и Service Level Indicators. Рассмотреть, что входит в понятия SLI, SLO и Error budget, как рассчитывать эти показатели, как за 7 шагов внедрить их отслеживание и как в последствии контролировать эти показатели на примере инструмента Instana.

Определимся с терминологией

Service Level Indicator (SLI) – это количественная оценка работы сервиса, как правило, связанная с удовлетворенностью пользователей производительностью приложения или сервиса за заданный период времени (месяц, квартал, год). А если говорить конкретнее – это индикатор пользовательского опыта, который отслеживает одну из многочисленных возможных метрик (рассмотрим их ниже) и, чаще всего, представляется в процентном эквиваленте, где 100 % - означает отличный пользовательский опыт, а 0% - ужасный.

Service Level Objectives (SLO) – это желаемое, целевое значение нашего SLI или группы SLI. При установке SLO необходимо указывать реально достижимое значение для каждого конкретного SLI. Ниже мы рассмотрим логику установки SLO на примере конкретных SLI.

Также важно понимать, что SLO – это наш внутренний показатель качества работы сервиса и/или приложения, в отличие от Service Level Agreement (SLA), который обычно устанавливается бизнесом как внешнее обязательство по доступности сервиса перед клиентами компании.

Всем привет. Сегодня мы хотели бы поговорить про выявления аномалий в микросервисной среде. Данный пост является краткой выжимкой нашего 40 минутного доклада, который мы делали на онлайн конференции DevOps Live 2020 и, чтобы не писать лонгрид, мы решили сфокусироваться на обзоре инструментов выявления аномалий в распределении значений метрик для автоматизации мониторинга микросервисов, которые возможно быстро начать использовать любой команде.

Тема детектирования аномалий сейчас очень актуальна, так как с переходом на микросервисы для SRE и DevOps приоритет задач, связанных с преобразованием алертов в осмысленный сигнал, снижением MTTD и упрощением настройки алертов в мониторинге распределенных сред значительно повысился.

На прошлой неделе мы выложили пост про то, как мы мониторим backend и микросервисную инфраструктуру с помощью Instana, и пообещали написать продолжение про мониторинг frontend.

В итоге мы решили не ограничиваться обзором Instana в качестве инструмента контроля frontend, а копнуть немного глубже и рассказать, для чего вообще нужен End User Monitoring, с какими проблемами производительности фронта мы сталкиваемся чаще всего, какие мы используем сценарии работы с собранными данными, и как Instana помогает нам контролировать пользовательский опыт в целом.

В данном техническом обзоре мы детально познакомимся с продуктом Instana – инструментом для автоматического мониторинга производительности микросервисной инфраструктуры, Kubernetes и пользовательского опыта, который использует наша компания в проектах на протяжении последнего года.

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

Мы прошли этот путь больше года назад, когда изучали инструменты, которые стоит использовать вне стандартной связки Prometheus + Grafana. Обзор получился объемным, поэтому разбили на две части.