Налаштування 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 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.

Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 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: null,
      currency: null
    }]
  }
});

Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-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 день)

Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.