Мониторинг производительности приложений: зачем нужен APM

Сервис тормозит, и это всё, что известно. Клиент пишет, что оформление заказа висит по полминуты, но в какой момент и на каком запросе, никто не скажет. Логи молчат, на сервере вроде бы всё в норме: процессор не загружен, памяти хватает. О сбое команда узнаёт последней, от того же клиента, а не от системы. Знакомая картина у многих, кто вырос из простого сайта в полноценный веб-сервис. Ниже разберём, как APM снимает эту слепоту, чем он отличается от привычного Zabbix, и что мы поняли на своих проектах, пока внедряли New Relic.

Что такое APM простыми словами

APM расшифровывается как Application Performance Monitoring, мониторинг производительности приложений. Если инфраструктурный мониторинг следит за железом и операционной системой, то APM смотрит внутрь самого приложения: какой запрос сколько выполнялся, в какой метод код провалился на секунду, какой SQL положил базу.

Представьте кассу в супермаркете. Инфраструктурный мониторинг говорит, что касса включена, свет горит, транспортёр крутится. APM показывает другое: очередь стоит, потому что у третьей кассы сканер перечитывает штрихкод по пять раз, и вот конкретный товар, на котором всё зависает. Первый отвечает на вопрос жив ли сервер. Второй - почему пользователю медленно.

На практике APM собирает три вещи. Метрики (время отклика, количество запросов в секунду, доля ошибок), трейсы (полный путь одного запроса через все слои приложения и внешние сервисы) и события (выброшенные исключения, медленные SQL-запросы, обращения к чужим API). Из этого складывается картина, где видно не только что всё плохо, но и где именно.

Чем APM отличается от мониторинга инфраструктуры

Частая путаница: у нас есть Zabbix, зачем ещё что-то. Zabbix и Prometheus - прекрасные инструменты, но они отвечают на другой вопрос. Они смотрят на ресурсы: загрузку CPU, свободное место на диске, доступность порта, объём оперативной памяти. APM смотрит на код и пользовательский опыт. Разница хорошо видна в реальном инциденте. Сервер по всем инфраструктурным метрикам здоров: нагрузка 20%, памяти вагон, диск свободен. А страница личного кабинета грузится восемь секунд. Zabbix тут молчит, потому что с его точки зрения всё отлично. APM показывает, что запрос делает 340 обращений к базе на одной странице - классический N+1 запрос, когда вместо одного JOIN код в цикле дёргает базу на каждую строку. Вот как эти уровни соотносятся:

Полноценная наблюдаемость - это все уровни вместе. Инфраструктурный мониторинг обычно у команды уже есть. APM закрывает самый дорогой слепой участок между железом и жалобой клиента.

Почему мы выбрали New Relic

Когда встал вопрос, чем закрыть этот участок на одном из наших проектов, мы смотрели несколько инструментов. Остановились на New Relic по нескольким причинам, и не все они очевидны из рекламных материалов. Автоинструментация. Агент ставится в приложение и начинает собирать трейсы почти без правок кода. Для существующего проекта, который не проектировали под наблюдаемость, это экономит много времени. Не нужно вручную обкладывать замерами каждый метод. Трассировка до метода и SQL. New Relic показывает разложение медленного запроса по слоям: сколько заняла бизнес-логика, сколько внешний вызов, сколько конкретный SQL. Именно так мы находили N+1 запросы, которые в коде выглядели безобидно. Apdex. Это индекс удовлетворённости пользователя скоростью, от 0 до 1. Вы задаёте порог (например, отклик до 0,5 секунды - хорошо, до 2 секунд - терпимо, дольше - плохо), а система считает долю довольных запросов. Одно число, которое понятно и разработчику, и руководителю, в отличие от абстрактных миллисекунд. Распределённый трейсинг. Если сервис распилен на микросервисы, один запрос проходит через несколько из них. New Relic сшивает эти куски в единую цепочку, и видно, на каком именно сервисе застревает запрос. Без этого в микросервисной архитектуре поиск тормоза превращается в гадание.

Отдельно скажем про минус: New Relic - западный SaaS, данные уходят в облако вендора, а с оплатой из России сейчас сложно. Поэтому ниже отдельный блок про то, чем его заменить в российском контуре. Выбор инструмента всегда упирается в требования по данным, а не только в удобство.

Как мы внедряли APM по шагам

Порядок, который сложился у нас на проектах, выглядит так.

1. Установить агента и получить базовую картину. Первые же трейсы обычно вскрывают пару очевидных проблем, о которых никто не подозревал.
2. Определить ключевые транзакции. Не всё одинаково важно. Оформление заказа, авторизация, оплата, поиск - вот что мониторим в первую очередь. Служебная страница помощи может подождать.
3. Настроить Apdex-пороги под реальность продукта. Для внутренней панели и для витрины магазина разумные пороги отличаются.
4. Найти и разобрать первые узкие места. Обычно это N+1 запросы, отсутствие индексов в базе, синхронные обращения к внешним API, которые надо было делать асинхронно.
5. Поставить алерты на то, что действительно важно. Про это отдельный разговор ниже, потому что здесь ломается большинство внедрений.
6. Повторить замер после оптимизаций. Мониторинг ценен тем, что показывает эффект правок в цифрах, а не на ощущение стало быстрее.

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

Что мониторить обязательно

Соблазн после установки APM - следить за всем подряд. Это тупик: сотня графиков, на которые никто не смотрит. Минимальный набор, который реально работает, короче.

• Доступность сервиса - жив ли он снаружи, а не только изнутри.
• Время отклика ключевых страниц, причём в перцентилях, а не в среднем (про среднее ниже в вопросах).
• Доля ошибок - процент запросов, завершившихся сбоем.
• Пропускная способность - сколько запросов в секунду держит сервис.
• Очереди и фоновые задачи - не копится ли необработанное, не встали ли воркеры.
• Внешние зависимости - время ответа платёжного шлюза, 1С, СМС-сервиса.
• Бизнес-метрики - заказы в минуту, успешные оплаты, регистрации.

Последний пункт недооценивают, а он самый показательный. Технические метрики могут быть зелёными, а заказы упали вдвое, потому что сломалась кнопка оплаты в одном браузере. График заказов в минуту ловит такое быстрее любого технического алерта.

Как настроить алерты, чтобы команда их не игнорировала

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

• Алерт только на то, по чему кто-то реально начнёт действовать. Если на уведомление нет реакции, его не должно быть.
• Пороги от бизнеса, а не от технаря. Не процессор выше 80%, а оформление заказа медленнее трёх секунд у каждого десятого клиента.
• Разные каналы по критичности. Упала оплата - звонок дежурному. Подросло время отклика - сообщение в рабочий чат, разберут утром.
• Защита от дребезга. Алерт срабатывает, если проблема держится несколько минут, а не на одиночный всплеск.
• Регулярная ревизия. Раз в месяц смотрим, какие алерты сработали впустую, и убираем шум.

Цель простая: когда пришло уведомление, ему верят и идут смотреть. Достигается это не технологией, а дисциплиной в настройке.

Сколько стоит APM и чем его заменить в России

Вопрос цены упирается в модель. Западные SaaS считают деньги за объём собранных данных и число пользователей, и на нагруженном проекте счёт растёт быстро. Российские решения и open source меняют структуру затрат: где-то платите за лицензию по объёму, где-то за собственную инфраструктуру и людей, которые всё это поддерживают. Инструменты, на которые стоит смотреть в 2026 году:

• New Relic (newrelic.com) - зрелый full-stack APM с автоинструментацией и трейсингом. Данные в облаке вендора. Есть бесплатный тариф на 100 ГБ данных в месяц и одного пользователя. Кому подходит: командам без ограничений на передачу данных за рубеж и с возможностью зарубежной оплаты.
• Datadog (datadoghq.com) - очень широкий охват: APM, логи, инфраструктура, поведение пользователей в браузере. Помодульная оплата, на большом объёме дорого. Данные в облаке. Кому: крупным распределённым командам за пределами РФ.
• Ключ-Астром (ruscomtech.ru) - российский APM и observability из реестра отечественного ПО, адаптирован под наш технологический стек, есть SaaS и установка в свой контур. Кому: тем, кому важны реестр ПО и данные внутри России.
• GMONIT (gmonit.ru) - российский APM с автоинструментацией, работой в реальном времени и распределённым трейсингом. Данные остаются в РФ. Кому: командам, которым нужен российский вендор и быстрый старт без ручной обвязки кода.
• Prometheus + Grafana (prometheus.io, grafana.com) - open source связка для метрик и дашбордов, при желании достраивается логами и трейсами. Данные полностью у вас, лицензий нет. Кому: командам с инженерной экспертизой, готовым держать и настраивать стек самостоятельно.
• Sentry (sentry.io) - фокус на ошибках в коде и лёгкой трассировке, есть self-hosted. Кому: как дополнение к APM, чтобы ловить исключения и регресс после релизов.

Цены и состав рынка меняются быстро (срез - июль 2026), актуальные тарифы уточняйте на сайтах, а курсы валют сами понимаете. Логика выбора одна: чем строже требования к данным (персональные данные, 152-ФЗ, госсектор, реестр отечественного ПО), тем весомее аргумент за российское решение или self-hosted в своём контуре. Западный SaaS удобен там, где нет ограничений на данных и есть чем платить. Прикинуть полную стоимость владения помогает не только ценник лицензии, но и время инженеров на поддержку.

Мониторинг, нагрузка и поддержка

APM редко живёт сам по себе. Он часть более широкой инженерной культуры, и три вещи рядом усиливают друг друга. Нагрузочное тестирование показывает предел: при скольких запросах в секунду сервис начинает деградировать. APM во время такого теста показывает причину: какой именно метод или запрос упирается в потолок первым. Тест отвечает, выдержит ли сервис, а трейс подсказывает, что чинить перед следующим пиком. Дальше идёт связь с поддержкой и SLA. Если вы обещаете клиенту доступность 99,9% и отклик до двух секунд, кто-то должен эти цифры видеть и защищать. Без APM обещание в договоре превращается в фигуру речи, потому что нечем измерить факт. С APM у дежурной смены есть приборы, а у бизнеса - основания для разговора о гарантиях. Отдельно стоит держать в голове деградацию на объёмах данных. Прототип и молодой сервис летают, пока в базе тысяча записей. На миллионе тех же записей всплывают запросы без индексов и та самая проблема N+1. Мы подробно разбирали это в материале про доведение прототипа до промышленной эксплуатации - мониторинг ровно тот инструмент, который ловит момент, когда сервис начал захлёбываться на росте.

Главное

Короткая выжимка, чтобы вернуться и не перечитывать всё.

• APM смотрит внутрь приложения - на код, запросы и пользовательский опыт, а не на железо. Zabbix и APM закрывают разные слепые зоны, они не заменяют друг друга.
• Главная ценность - трассировка: видно, на каком методе, SQL или внешнем вызове застревает конкретный запрос. Так находятся N+1 и отсутствие индексов.
• Мониторить нужно ключевые транзакции, доступность, время отклика в перцентилях, долю ошибок, очереди и бизнес-метрики. Не всё подряд.
• Алерты работают только при дисциплине: уведомление на то, по чему реально действуют, пороги от бизнеса, регулярная чистка шума.
• Выбор инструмента упирается в требования к данным. New Relic и Datadog удобны, но это западный SaaS. В российском контуре смотрят на Ключ-Астром, GMONIT или self-hosted связку Prometheus и Grafana.

Частые вопросы

Чем APM отличается от обычного логирования? Логи - это разрозненные записи о событиях, которые ещё надо суметь связать между собой. APM автоматически сшивает путь одного запроса через все слои, считает метрики и подсвечивает аномалии. Логи отвечают что произошло в конкретной точке, APM - где во всей цепочке медленно или сломано. Почему нельзя смотреть на среднее время отклика? Среднее прячет проблемы меньшинства. Если у 90% пользователей отклик 0,2 секунды, а у 10% - 12 секунд, среднее выйдет чуть больше секунды и покажется нормальным. А каждый десятый клиент при этом мучается. Поэтому смотрят перцентили: p95 и p99 показывают, как быстро сервису отвечает худшая часть запросов. Нужен ли APM небольшому сервису? Если это витрина с оплатой, личный кабинет или B2B-портал, на котором завязаны деньги клиентов, то да, хотя бы в минимальном виде. Начать можно с бесплатного тарифа или open source. Простому статичному сайту-визитке хватит внешнего мониторинга доступности. Что такое N+1 запрос, который вы упоминаете? Это когда код вместо одного запроса к базе делает один запрос за списком, а потом ещё по одному на каждый элемент списка. Для страницы с сотней товаров получается 101 обращение к базе вместо двух. Визуально страница просто медленная, а в трейсе APM это видно сразу. Можно ли обойтись российскими или бесплатными инструментами? Да. Для контура с требованиями по данным есть Ключ-Астром и GMONIT из отечественных, а для команд с инженерной экспертизой - self-hosted связка Prometheus, Grafana и Sentry. Разница в основном в том, сколько своего времени команда готова вложить в поддержку вместо оплаты готового сервиса. Если сервис тормозит, а причину найти нечем, мы поможем поставить мониторинг, разобрать узкие места и настроить осмысленные алерты - в том числе на российских и open source инструментах, если данные нельзя отдавать наружу. Обсудить задачу можно на почте mail@drsofter.ru, в Telegram @drsofter или через форму на drsofter.ru. Разработку, DevOps и техподдержку 24/7 ведёт одна команда, поэтому мониторинг мы закладываем в проект с самого начала, а не в авральном режиме после первой аварии.