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

Представьте: сайт тормозит, пользователи жалуются, а вы не понимаете, в чём дело. Стандартные логи и метрики сервера не показывают, какой именно SQL-запрос выполняется 3 секунды или почему контроллер зависает на 2 секунды. APM (Application Performance Monitoring) решает эту проблему — он отслеживает производительность на уровне кода. В одном из проектов на Laravel мы обнаружили, что медленный запрос к orders таблице занимал 3.2 секунды из-за отсутствия индекса. APM показал это через 5 минут после установки. Мы настраиваем APM, чтобы вы видели полную картину: от HTTP-запроса до ответа базы данных. APM даёт ответы на вопросы: какой эндпоинт самый медленный? какая функция жрёт процессор? где происходит утечка памяти? С APM вы не гадаете — вы знаете. Наш опыт включает внедрение для 20+ проектов с нагрузкой до 1 млн запросов в день — 5+ лет на рынке.

Какие проблемы решает APM?

• Медленные SQL-запросы. Один неоптимизированный запрос может добавлять секунды к времени ответа. APM показывает полный стек вызовов и время выполнения каждого запроса.
• N+1 запросы ORM. Типичная проблема Laravel и Django: цикл по коллекции порождает сотни запросов к базе. Трассировки выявляют это мгновенно.
• Узкие места в коде. Flamegraph профилирования показывает, какая функция потребляет больше всего процессора или памяти.
• Ошибки и исключения. APM автоматически собирает stack trace и связывает с конкретным запросом.

Как работает трассировка запросов?

Каждый входящий HTTP-запрос получает уникальный идентификатор (trace ID). На каждом этапе — контроллер, сервис, ORM, SQL, Redis — создаются спаны. Спаны содержат время начала, длительность, статус и атрибуты (например, SQL-текст). Все спаны объединяются в трассировку, которая визуализируется как waterfall-диаграмма. Мы используем сэмплирование (10–20% запросов), чтобы не перегружать продакшен.

Какие метрики производительности контролировать?

Ключевые метрики для оценки качества работы приложения:

Эти SLO-метрики помогают объективно оценить, как приложение справляется с нагрузкой.

Почему OpenTelemetry — лучший выбор?

OpenTelemetry — это вендор-нейтральный стандарт сбора трассировок и метрик. Один SDK отправляет данные в любую APM-систему: Jaeger, Zipkin, Datadog, New Relic, Grafana Tempo. Вы не зависите от одного вендора и можете сменить бэкенд без переписывания кода.

// bootstrap/telemetry.php
use OpenTelemetry\API\Globals;
use OpenTelemetry\SDK\Trace\TracerProviderFactory;
use OpenTelemetry\Contrib\Otlp\OtlpHttpSpanExporter;

$exporter = OtlpHttpSpanExporter::fromConnectionString(
    'http://otel-collector:4318',
    'myapp',
    '1.0.0'
);

$tracerProvider = (new TracerProviderFactory())->create($exporter);
Globals::registerInitializer(fn() => $tracerProvider);

Мы подключаем middleware для трассировки HTTP-запросов и слушатели для SQL-запросов. Всё это работает без изменения бизнес-логики.

import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';

const sdk = new NodeSDK({
  resource: new Resource({
    'service.name': 'myapp-api',
    'service.version': process.env.APP_VERSION || '1.0.0',
  }),
  traceExporter: new OTLPTraceExporter({
    url: 'http://otel-collector:4318/v1/traces',
  }),
  instrumentations: [getNodeAutoInstrumentations({
    '@opentelemetry/instrumentation-express': { enabled: true },
    '@opentelemetry/instrumentation-pg': { enabled: true },
    '@opentelemetry/instrumentation-redis': { enabled: true },
  })],
});
sdk.start();

Гарантируем, что инструментация не влияет на производительность продакшена — мы используем сэмплирование (например, 10% запросов).

Что входит в настройку APM?

1. Анализ инфраструктуры — определяем точки сбора данных: HTTP, SQL, Redis, очереди.
2. Установка OpenTelemetry SDK — настройка для вашего стека (PHP, Node.js, Python, Go).
3. Интеграция с бэкендом — подключение Grafana Tempo, Sentry Performance или другого инструмента.
4. Создание дашбордов — визуализация latency, error rate, Apdex, SLO.
5. Настройка алертов — оповещения при превышении порогов (p95 > 1 с, error rate > 1%).
6. Документация и обучение — описание архитектуры сбора и инструкции для команды.

Сроки реализации

Стоимость рассчитывается индивидуально в зависимости от сложности. Мы оцениваем проект бесплатно.

Почему стоит внедрить APM?

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

Свяжитесь с нами, чтобы мы оценили ваш проект. Закажите настройку APM под ключ — получите полный контроль над производительностью. Получите консультацию по настройке APM для вашего проекта — мы оценим сложность и предложим оптимальное решение.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.

Почему события GA4 дублируются и как это исправить?

Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.

Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.

Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.

Как настроить data layer, чтобы не потерять данные?

GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Название товара',
      price: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.

Как Яндекс.Метрика дополняет веб-аналитику?

Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.

Что даёт product analytics в Amplitude?

Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.

Мониторинг качества данных

Аналитика без мониторинга — чёрный ящик. Настраиваем:

• GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
• Alerting в GA4 — аномалия в количестве событий purchase (резкое падение = что-то сломалось)
• GTM Preview в staging-окружении перед продакшеном
• Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается

Что проверяем после каждого деплоя

• Все ли рекомендуемые события присутствуют в DebugView
• Нет ли задвоений (считаем количество purchase на 100 сессий)
• Не изменилась ли структура dataLayer после обновления фронтенда

Что входит в работу

Процесс и сроки

1. Аудит текущих тегов и данных (2 дня)
2. Дизайн событийной схемы (2 дня)
3. Разработка Data Layer и настройка тегов (3–5 дней)
4. QA в Preview Mode и на staging (2 дня)
5. Деплой и настройка дашбордов (1 день)

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.