Сбор и масштабирование метрик в PHP Symfony highload: 200k RPM, 50+ серверов и zero overhead с Telegraf UDP

«Redis умирает на 200k RPM, Prometheus не успевает скрейпить 50 серверов, а бизнес требует real-time дашборды. Знакомо?»

Пятница, 18:00. Дашборд в Grafana показывает timeout’ы при сборе метрик. Redis, который хранит данные для prometheus_client_php, жрёт 8GB памяти и 100% CPU. Prometheus не успевает опросить все 50+ серверов за отведённые 15 секунд. А в понедельник запускается Black Friday…

Эта статья — о том, как на одном из проектов перешли с pull на push модель для мониторинга PHP-приложения в highload, почему выбор пал на UDP + Telegraf вместо классического подхода, и как теперь собираем метрики PHP с 50+ серверов без единого timeout’а.

Архитектура: Pull vs Push для метрик в PHP

Проблема: почему Prometheus PHP Client не всегда подходит для highload

Начнём с типичного сценария. У вас есть PHP-приложение на Symfony, нужны метрики для мониторинга. Первое, что приходит в голову — prometheus_client_php. Отличная библиотека, но есть нюансы:

// Классический подход с prometheus_client_php $registry = new CollectorRegistry(new Redis()); $counter = $registry->getOrRegisterCounter('app', 'requests_total', 'Total requests'); $counter->inc(['method' => 'GET', 'endpoint' => '/api/users']); 

Что здесь происходит под капотом:

1. Каждая метрика сохраняется в Redis/APC/in-memory storage

2. Prometheus периодически скрейпит endpoint /metrics

3. При скрейпинге происходит чтение всех метрик из хранилища

Где начинаются проблемы

Масштабирование: При 50+ серверах Prometheus должен опрашивать каждый. С ростом числа серверов это становится узким местом.

Хранилище метрик: Redis добавляет латенси, APC работает только в рамках одного сервера, in-memory не переживёт рестарт FPM.

Сложность конфигурации: Нужно настроить service discovery в Prometheus для всех серверов, следить за их доступностью.

Производительность: На 200k RPM каждый вызов Redis для инкремента счётчика — это overhead.

Решение: Push-модель через UDP для мониторинга PHP в highload

Мы пошли другим путём: отправляем метрики через UDP протокол в Telegraf, который уже сам разбирается, куда их дальше передать.

Почему именно UDP?

1. Fire & forget: Отправили пакет и забыли. Никаких ожиданий ответа, никаких таймаутов.

2. Минимальный overhead: UDP-пакет улетает за микросекунды.

3. Fault tolerance: Если Telegraf упал, приложение продолжает работать.

4. Простота: Не нужны connection pools, retry-логика, circuit breakers для метрик.

Важно: Да, UDP может терять пакеты. Но для метрик это не критично — потеря 0.01% данных не исказит общую картину на дашборде.

TelegrafMetricsBundle: реализация

Все это добро я собрал в простенький TelegrafMetricsBundle — Symfony-бандл для отправки метрик через UDP.

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

composer require yakovlef/telegraf-metrics-bundle 

Конфигурация в config/packages/telegraf_metrics.yaml:

telegraf_metrics:     namespace: 'my_app'  # Префикс для всех метрик     client:         url: 'http://localhost:8086'  # InfluxDB URL (для конфигурации клиента)         udpPort: 8089  # UDP порт Telegraf 

Архитектура бандла

Бандл построен на трёх ключевых компонентах:

// MetricsCollectorInterface - контракт для DI interface MetricsCollectorInterface {     public function collect(string $name, array $fields, array $tags = []): void; }  // MetricsCollector - реализация через InfluxDB UDP Writer class MetricsCollector implements MetricsCollectorInterface {     private UdpWriter $writer;      public function __construct(Client $client, string $namespace)     {         $this->writer = $client->createUdpWriter();     }      public function collect(string $name, array $fields, array $tags = []): void     {         // Отправляем метрику в формате InfluxDB Line Protocol         $this->writer->write(             new Point("{$this->namespace}_$name", $tags, $fields)         );     } } 

Интеграция с Symfony DI происходит автоматически:

services:     # Автоматическая регистрация через autowiring     Yakovlef\TelegrafMetricsBundle\Collector\MetricsCollectorInterface:          '@telegraf_metrics.collector' 

Практические кейсы использования

1. Мониторинг API endpoints

class ApiController {     public function __construct(         private MetricsCollectorInterface $metrics     ) {}      public function getUsers(): JsonResponse     {         $startTime = microtime(true);                  try {             $users = $this->userRepository->findAll();             $responseTime = (microtime(true) - $startTime) * 1000;                          $this->metrics->collect('api_request', [                 'response_time' => $responseTime,                 'count' => 1             ], [                 'endpoint' => '/api/users',                 'method' => 'GET',                 'status' => '200'             ]);                          return new JsonResponse($users);                      } catch (\Exception $e) {             $this->metrics->collect('api_error', ['count' => 1], [                 'endpoint' => '/api/users',                 'error_type' => get_class($e),                 'status' => '500'             ]);             throw $e;         }     } } 

2. Бизнес-метрики в e-commerce

class OrderService {     public function createOrder(OrderDto $dto): Order     {         $order = new Order($dto);         $this->em->persist($order);         $this->em->flush();                  // Отправляем бизнес-метрики         $this->metrics->collect('order_created', [             'amount' => $order->getTotalAmount(),             'items_count' => $order->getItemsCount(),             'count' => 1         ], [             'payment_method' => $order->getPaymentMethod(),             'currency' => $order->getCurrency(),             'user_type' => $order->getUser()->getType()         ]);                  return $order;     }          public function processPayment(Order $order): void     {         $startTime = microtime(true);                  try {             $result = $this->paymentGateway->charge($order);                          $this->metrics->collect('payment_processed', [                 'amount' => $order->getTotalAmount(),                 'processing_time' => (microtime(true) - $startTime) * 1000,                 'count' => 1             ], [                 'gateway' => $this->paymentGateway->getName(),                 'status' => 'success'             ]);                      } catch (PaymentException $e) {             $this->metrics->collect('payment_failed', [                 'amount' => $order->getTotalAmount(),                 'count' => 1             ], [                 'gateway' => $this->paymentGateway->getName(),                 'error_code' => $e->getCode()             ]);             throw $e;         }     } } 

3. Мониторинг фоновых задач

class EmailConsumer implements MessageHandlerInterface {     public function __invoke(SendEmailMessage $message): void     {         $startTime = microtime(true);                  try {             $this->mailer->send($message->getEmail());                          $this->metrics->collect('consumer_processed', [                 'processing_time' => (microtime(true) - $startTime) * 1000,                 'count' => 1             ], [                 'consumer' => 'email',                 'status' => 'success',                 'priority' => $message->getPriority()             ]);                      } catch (\Exception $e) {             $this->metrics->collect('consumer_failed', ['count' => 1], [                 'consumer' => 'email',                 'error' => get_class($e)             ]);             throw $e;         }     } } 

4. Circuit Breaker паттерн с метриками

class ExternalApiClient {     private int $failures = 0;     private bool $isOpen = false;          public function call(string $endpoint): array     {         if ($this->isOpen) {             $this->metrics->collect('circuit_breaker', ['count' => 1], [                 'service' => 'external_api',                 'state' => 'open',                 'action' => 'rejected'             ]);             throw new CircuitBreakerOpenException();         }                  try {             $response = $this->httpClient->request('GET', $endpoint);                          $this->failures = 0;             $this->metrics->collect('circuit_breaker', ['count' => 1], [                 'service' => 'external_api',                 'state' => 'closed',                 'action' => 'success'             ]);                          return $response->toArray();                      } catch (\Exception $e) {             $this->failures++;                          if ($this->failures >= 5) {                 $this->isOpen = true;                 $this->metrics->collect('circuit_breaker', ['count' => 1], [                     'service' => 'external_api',                     'state' => 'open',                     'action' => 'opened'                 ]);             }                          throw $e;         }     } } 

Агрегация метрик в Telegraf

Одна из киллер-фич Telegraf — встроенная агрегация через плагин basicstats. Вместо отправки сырых данных в Prometheus, можно агрегировать их прямо в Telegraf:

Пример конфигурации Telegraf с агрегацией

# /etc/telegraf/telegraf.conf  # Input: принимаем метрики по UDP [[inputs.socket_listener]]   service_address = "udp://:8089"   data_format = "influx"  # Aggregation: агрегируем метрики каждые 10 секунд [[aggregators.basicstats]]   period = "10s"   drop_original = false   stats = ["count", "mean", "sum", "min", "max", "stdev"]      # Агрегируем только метрики API   namepass = ["my_app_api_*"]  # Output для Prometheus [[outputs.prometheus_client]]   listen = ":9273"   metric_version = 2   path = "/metrics"      # Батчинг для оптимизации   metric_batch_size = 1000   metric_buffer_limit = 10000  # Output для InfluxDB (опционально) [[outputs.influxdb_v2]]   urls = ["http://localhost:8086"]   token = "your-token"   organization = "your-org"   bucket = "metrics"      # Батчинг для снижения нагрузки   flush_interval = "10s"   metric_batch_size = 5000 

Подводные камни и как их обойти

UDP теряет пакеты — и это нормально

Проблема: При высокой нагрузке возможна потеря пакетов.

Решение: Мониторьте метрики самого Telegraf. Если потери критичны — увеличьте UDP буферы или добавьте батчинг на стороне приложения.

Помним главное: Потеря 0.01% метрик лучше, чем падение приложения из-за недоступного Redis.

Размер UDP пакета: почему ваши метрики могут не долетать

Проблема: UDP пакет ограничен ~65KB, при большом количестве тегов можно превысить лимит.

Решение: Ограничьте количество уникальных тегов, используйте короткие имена:

// Плохо: длинные теги с высокой кардинальностью $this->metrics->collect('api_request', ['time' => 100], [     'user_email' => $user->getEmail(), // Высокая кардинальность!     'request_id' => uniqid(),          // Уникальное значение каждый раз     'full_endpoint_path_with_parameters' => $request->getUri() ]);  // Хорошо: короткие теги с низкой кардинальностью $this->metrics->collect('api_request', ['time' => 100], [     'endpoint' => '/api/users',  // Группировка     'method' => 'GET',           // Всего 5-7 значений     'status' => '200'            // Всего 5-10 значений ]); 

Меньше уникальных тегов = меньше размер пакета = надёжнее доставка.

Альтернативные сценарии использования

VictoriaMetrics вместо Prometheus

Для highload-систем Prometheus может становиться узким местом: высокое потребление памяти, долгие запросы при большом объёме данных и отсутствие кластерного режима «из коробки». VictoriaMetrics полностью совместима с Prometheus-протоколом, но эффективнее в хранении, быстрее обрабатывает длинные запросы и поддерживает горизонтальное масштабирование, что делает её более надёжным выбором для систем с сотнями тысяч метрик в секунду.

Отправка в несколько систем одновременно

# Дублируем метрики в разные системы [[outputs.prometheus_client]]   listen = ":9273"  [[outputs.influxdb_v2]]   urls = ["http://influxdb:8086"]  [[outputs.graphite]]   servers = ["graphite:2003"] 

Roadmap и текущие ограничения

Что уже работает

Production-ready
Интеграция с Symfony 6.4+ и 7.0+
Поддержка Prometheus / VictoriaMetrics
Zero-overhead доставка метрик

Важно: Несмотря на отсутствие тестов в текущей версии, бандл уже больше года работает на проде на нескольких highload проектах.

Выводы: что мы получили и чему научились

Переход на push-модель через UDP + Telegraf для мониторинга PHP дает нам три ключевых тейка:

Производительность как конкурентное преимущество

Снижение latency в 60 раз (с 3ms до 0.05ms) — это не просто цифры. На 200k RPM это экономит 10 минут CPU-времени в час, что позволяет обрабатывать на 15% больше запросов на том же железе.

Масштабирование без головной боли

Линейное масштабирование — добавление новых серверов теперь занимает 30 секунд. Просто деплоим приложение с тем же UDP endpoint. Никаких изменений в Prometheus, никакого service discovery.

Антихрупкость системы

Изоляция сбоев — система метрик может полностью упасть, но приложение продолжит работать. За годы эксплуатации это спасло нас несколько раз во время инцидентов с инфраструктурой мониторинга.

Метрики в PHP — это не роскошь, а необходимость для понимания, что происходит в production. Подход с Telegraf UDP позволил забыть о проблемах масштабирования и сосредоточиться на том, что действительно важно — на бизнес-логике и пользовательском опыте.

Да, мы пожертвовали гарантированной доставкой каждого пакета. Но взамен получили систему, которая выдерживает любые нагрузки и не становится точкой отказа в самый критический момент — когда начинается пик на проекте

Если у вас есть опыт мониторинга PHP в highload или вопросы по настройке метрик через Telegraf — делитесь в комментариях. Особенно интересны альтернативные подходы: может, кто-то решил эту задачу через другие инструменты?

Bundle доступен на GitHub и в Packagist.

---

P.S. Если статья сэкономила вам время на изобретении велосипеда — поставьте звезду репозиторию. А если найдёте баги — создавайте issues, поправим.