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