Настройка New Relic для мониторинга сервера: APM, инфраструктура, алерты

Представьте: ваш сайт внезапно начинает тормозить, а пользователи жалуются на ошибки. Логи не показывают явной причины, а нагрузка на сервер в норме. Без наблюдаемости вы можете часами искать иголку в стоге сена. New Relic даёт прозрачность каждой транзакции — от HTTP-запроса до SQL-запроса к БД.

Один из наших клиентов — интернет-магазин с 10 тыс. заказов в день — столкнулся с ростом TTFB до 3 секунд. После настройки New Relic выяснили, что виноват неоптимальный кэш Redis. Оптимизация заняла 2 часа, а TTFB упал до 300 мс. Такая диагностика без мониторинга заняла бы дни, а потери клиентов составили бы тысячи.

Зачем нужен мониторинг сервера?

Без мониторинга вы действуете вслепую. Если сайт тормозит в конкретный момент, вы не знаете — виноват ли сервер, база данных или внешний API. New Relic собирает метрики в реальном времени: CPU, RAM, дисковые операции, сетевые задержки. Это позволяет быстро найти корень проблемы.

Проблемы, которые решает New Relic

• APM отслеживает каждую транзакцию: время выполнения, количество вызовов, ошибки. Вы увидите, какой эндпоинт самый медленный.
• Infrastructure мониторинг показывает загрузку сервера: если CPU 90% — возможно, нужен апгрейд или оптимизация.
• Browser мониторинг фиксирует реальный пользовательский опыт: LCP, CLS, INP. New Relic даёт рекомендации по улучшению.

New Relic Pro позволяет хранить данные дольше и выставлять более гибкие алерты. Для большинства проектов достаточно бесплатного тарифа, но при высокой нагрузке мы рекомендуем Pro.

Как мы настраиваем New Relic: процесс

1. Анализ: определяем критические транзакции, эндпоинты, серверы.
2. Установка Infrastructure агента на всех серверах.
3. Установка APM агента для PHP и/или Node.js.
4. Настройка кастомных метрик для бизнес-событий (например, оформление заказа).
5. Создание NRQL алертов на ошибки и медленные запросы.
6. Интеграция с CI/CD: мониторинг версий после деплоя.
7. Передача документации и обучение команды.

Установка и настройка агентов

Установка Infrastructure агента выполняется одной командой:

curl -Ls https://download.newrelic.com/install/newrelic-cli/scripts/install.sh | \
  bash && sudo NEW_RELIC_API_KEY="NRAK-..." \
         NEW_RELIC_ACCOUNT_ID="1234567" \
         /usr/local/bin/newrelic install

После установки настраивается конфигурация /etc/newrelic-infra.yml:

license_key: your-license-key
display_name: web01.example.com
custom_attributes:
  environment: production
  app: myapp
  region: eu-west-1

Для PHP устанавливаем APM агент и добавляем настройки в php.ini:

wget https://download.newrelic.com/php_agent/archive/10.x.x/newrelic-php5-10.x.x-linux.tar.gz
tar -xzf newrelic-php5-*.tar.gz
cd newrelic-php5-*/
sudo ./newrelic-install install

extension = newrelic.so
newrelic.license = "your-license-key"
newrelic.appname = "MyApp (Production)"
newrelic.distributed_tracing_enabled = true
newrelic.transaction_tracer.enabled = true
newrelic.transaction_tracer.threshold = 500

Для Node.js достаточно установить модуль newrelic и добавить require('newrelic') первой строкой в точке входа. Конфигурация через переменные окружения.

Кастомные метрики и NRQL алерты

Кастомные метрики позволяют отслеживать бизнес-показатели. Пример на PHP:

newrelic_custom_metric('Custom/OrderProcessing/Duration', $durationMs);
newrelic_custom_metric('Custom/Orders/Total', $order->total);
newrelic_record_custom_event('OrderPlaced', [
    'orderId'  => $order->id,
    'userId'   => $user->id,
    'total'    => $order->total,
    'items'    => $order->items->count(),
]);

Алерты на основе NRQL позволяют мгновенно реагировать на аномалии. Например, алерт на процент ошибок: SELECT percentage(count(*), WHERE error IS true) FROM Transaction WHERE appName = 'MyApp (Production)' SINCE 5 minutes ago. Или дашборд с топ-20 медленных запросов к БД.

Типичные ошибки при настройке New Relic

• Неверная лицензия или API-ключ. Агент не может авторизоваться, данные не отправляются. Проверьте, что ключ активен и соответствует аккаунту.
• Не включён distributed tracing. Транзакции не связываются между сервисами, теряется полная картина. Включите через опцию newrelic.distributed_tracing_enabled = true для PHP или config.distributed_tracing.enabled: true для Node.js.
• Слишком низкий порог алертов. Постоянные ложные срабатывания вызывают усталость команды. Настройте пороги на основе статистики (например, по 95-му перцентилю).

Что даёт наблюдаемость New Relic?

После настройки вы получаете полную картину производительности: время ответа каждой транзакции, загрузку сервера, реальный пользовательский опыт. Это позволяет сократить время диагностики с часов до минут. Например, вы можете увидеть, что 95-й перцентиль времени ответа вырос до 2 секунд, и сразу найти причину — медленный запрос к БД или зависший внешний API.

Сроки и объём работ

Базовая настройка (Infrastructure + APM) занимает 1 день. Если нужны кастомные метрики и алерты — 2-3 дня. Мы передаём документацию и обучаем вашу команду. После запуска предоставляем 2 недели технической поддержки.

Почему выбирают нас?

Мы на рынке более 5 лет, настроили мониторинг для 50+ проектов на разных стеках (PHP, Node.js, Python). Наши инженеры имеют сертификацию по наблюдаемости. Гарантируем, что после настройки вы будете получать алерты о проблемах до того, как они повлияют на пользователей. New Relic в 2 раза быстрее конкурентов выявляет первопричину сбоев. Свяжитесь с нами, чтобы обсудить ваш проект. Закажите настройку мониторинга New Relic и получите прозрачность вашего приложения.

Настройка веб-аналитики: 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.