Настройка GraphQL Monitoring (Apollo Studio / GraphQL Hive)

После перехода с REST на GraphQL команды часто теряют контроль над производительностью. Типичная картина: запрос тормозит, но непонятно, какой резолвер виноват. N+1 запросы маскируются под нормальные ответы, а несовместимое изменение схемы ломает мобильное приложение. Мы внедрили мониторинг GraphQL для 50+ проектов — от стартапов до enterprise — и знаем, какие инструменты реально работают в production. В одном случае p95 latency операций выросла с 200 до 800 мс за неделю. Только трассировка резолверов показала, что проблема в новом обработчике user.orders, который делал 50 отдельных запросов к базе. Мониторинг помог выявить это за час, сократив время диагностики с часов до минут, и после устранения N+1 latency упала на 60%.

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

• Невидимость полевого использования: Apollo Studio показывает, какие поля реально запрашивают клиенты. Это помогает удалить deprecated поля без страха.
• Медленные резолверы без трассировки: OpenTelemetry с Jaeger/Tempo позволяет увидеть, какой именно обработчик тормозит — до уровня аргументов.
• Breaking changes схемы: автоматическая проверка обратной совместимости при каждом деплое предотвращает падение production.

Как мы это делаем: стек и конфиги

Apollo Studio (GraphOS)

// Установка npm install @apollo/server @apollo/server/plugin/usageReporting
import { ApolloServer } from '@apollo/server'
import { ApolloServerPluginUsageReporting } from '@apollo/server/plugin/usageReporting'

const server = new ApolloServer({
  typeDefs,
  resolvers,
  plugins: [
    ApolloServerPluginUsageReporting({
      // APOLLO_KEY из переменных среды
      sendVariableValues: {
        // Не отправлять чувствительные переменные
        exceptNames: ['password', 'token', 'secret']
      },
      sendHeaders: {
        exceptNames: ['Authorization', 'Cookie']
      },
      // Выборка трассировок (100% дорого, 10% достаточно для анализа)
      fieldLevelInstrumentation: 0.1
    })
  ]
})

Согласно документации Apollo Studio, платформа предоставляет: разбивку p50/p95/p99 latency по операциям, field usage, schema checks с реальными клиентскими запросами, алерты по деградации.

GraphQL Hive (self-hosted альтернатива)

# Docker Compose для GraphQL Hive docker run -d \
 -e HIVE_TOKEN=your-token \
 -e TARGET=your-org/your-project/production \
 ghcr.io/kamilkisiela/graphql-hive/cli:latest

import { useHive } from '@graphql-hive/client'
import { envelop, useSchema } from '@envelop/core'

const getEnveloped = envelop({
  plugins: [
    useSchema(schema),
    useHive({
      enabled: true,
      token: process.env.HIVE_TOKEN,
      usage: {
        sampleRate: 1.0,
        exclude: ['IntrospectionQuery']
      },
      reporting: {
        author: 'CI Pipeline',
        commit: process.env.GIT_SHA
      }
    })
  ]
})

OpenTelemetry трассировка резолверов

Для self-hosted мониторинга с Jaeger/Tempo используем плагин, который создаёт span на каждый обработчик. Это позволяет видеть полную картину запроса, включая вызовы к базам данных. OpenTelemetry — бесплатный open-source, затраты только на хостинг коллектора (~$30-50/мес).

Сравнение Apollo Studio vs GraphQL Hive

Apollo Studio удобнее для быстрого старта, но GraphQL Hive может быть экономичнее при больших объёмах (до 40% экономии за счёт self-hosted).

Типичные метрики мониторинга

Как выбрать между Apollo Studio и GraphQL Hive?

Если нужно быстрое облачное решение без администрирования — Apollo Studio. Если требования к data residency или бюджет большой — выбирайте Hive. Мы помогаем с выбором на этапе аудита.

Почему стоит добавить OpenTelemetry дополнительно?

OpenTelemetry даёт полную трассировку запроса, включая вызовы к сторонним API и базам данных. Apollo Studio/Hive видят только GraphQL-слой. Сочетание даёт 100% видимость. Это также позволяет выявить влияние на Core Web Vitals за счёт оптимизации TTFB.

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

• Слишком низкий sample rate (менее 1%) — статистически недостоверные p99.
• Отсутствие фильтрации чувствительных данных — утечка credentials через метрики.
• Игнорирование schema change alerts при деплое — риск breaking changes.

Процесс работы по настройке

1. Аналитика: аудит текущей схемы, выявление узких мест с помощью @apollo/rover или graphql-inspector.
2. Проектирование: выбор инструмента (Apollo Studio, Hive или OpenTelemetry), проектирование метрик (p50/p95/p99, error rate, Prometheus метрики).
3. Реализация: интеграция плагина, настройка трассировки резолверов, публикация схемы.
4. Тестирование: проверка на staging, сравнение показателей до/после. В одном проекте снизили p95 latency с 2с до 300 мс.
5. Деплой и алерты: настройка уведомлений в Slack/Telegram при деградации (например, p95 latency > 500ms), а также Grafana дашборды.

Что входит и сроки

Настройка GraphQL мониторинга занимает от 2 до 5 рабочих дней в зависимости от сложности схемы и выбранного решения. Включает: подключение Apollo Studio или GraphQL Hive с публикацией схемы, трассировку резолверов через OpenTelemetry (Jaeger/Tempo), Prometheus метрики + Grafana дашборд с панелями «Top Slow Operations», «Error Rate», «Slowest Resolvers», настройку алертов и автоматических проверок обратной совместимости, документацию по эксплуатации.

Инвестиции в мониторинг окупаются в среднем за 2-3 месяца — сокращение времени на поиск проблем и предотвращение инцидентов экономит бюджеты. Обращайтесь к нам для настройки мониторинга под ваш проект. Получите консультацию по выбору инструментов и быстрой интеграции.