StatsD

StatsD — простой протокол и демон-агрегатор метрик, разработанный компанией Etsy в 2011 году. Приложение отправляет необработанные числа по UDP одной строкой, демон агрегирует их за интервал (по умолчанию 10 секунд) и пересылает в Graphite, InfluxDB или другой backend. Ключевая идея — минимальные накладные расходы на стороне приложения: UDP не требует установки соединения, отправка метрики занимает микросекунды.

Как работает

Формат метрики: имя_метрики:значение|тип|@коэффициент_семплирования

Типы метрик:

• Counter (c) — счётчик событий: http.requests:1|c. Агрегируется суммированием.
• Gauge (g) — текущее значение: db.connections:42|g. Переписывается при каждой отправке.
• Timer (ms) — время операции: api.response_time:320|ms. Вычисляются min/max/mean/p95/p99.
• Set (s) — количество уникальных значений: users.unique:user_id|s.

Семплирование: http.errors:1|c|@0.1 означает «это событие происходит в 10% случаев, умножь на 10». Это снижает трафик при высоком RPS.

Демон StatsD слушает UDP/TCP (порт 8125) и каждые 10 секунд сбрасывает агрегированные данные в backend. Важно: UDP ненадёжен — при перегрузке пакеты теряются без уведомления. Это приемлемо для метрик (потеря 0,1% данных не критична), но неприемлемо для транзакционных операций.

StatsD стал де-факто стандартом протокола. Сегодня существуют десятки реализаций и клиентских библиотек: Telegraf принимает StatsD-метрики, Prometheus — через pushgateway, Datadog — через DogStatsD (расширенный формат с тегами).

История

StatsD создан инженерами Etsy (Кайлом Тобиасом и Иэном Прибо) и опубликован на GitHub в 2011 году. Написан на Node.js. Этси опубликовал пост «Measure Anything, Measure Everything», описывающий идеологию: низкий барьер для добавления метрик, агрегация вместо передачи сырых данных. К 2013 году появились реализации на Go, Python, Erlang. Telegraf (InfluxData, 2015) стал популярной заменой с встроенным StatsD-входом.

На что обращать внимание

StatsD-демон должен обрабатывать входящие пакеты быстрее, чем они поступают: при 100k RPS и потере 1% метрик разница с точными счётчиками Prometheus станет существенной. Для высоких нагрузок используйте batching: клиентская библиотека объединяет несколько метрик в один UDP-пакет (до 65 КБ). Размещение StatsD-демона на том же хосте, что и приложение, снижает UDP-потери — loopback надёжнее сетевого интерфейса.

История StatsD

StatsD создан Этан Шрайбером и Ником Мур в Etsy в 2010 году для сбора метрик приложений. Первый открытый релиз на GitHub — 2011 год. Написан на Node.js, принимает метрики по UDP. Протокол StatsD стал де-факто стандартом: поддерживается Telegraf, Datadog, InfluxDB, StatsD-compatible backends (statsite на C, gostatsd на Go). DogStatsD — расширение Datadog с тегами. Подходит для высокочастотного сбора метрик приложений без накладных расходов TCP.

Типы метрик StatsD

counter:1|c           # счётчик (запросы, события)
gauge:100|g           # текущее значение (RAM, очередь)
timer:320|ms          # измерение времени
set:unique_user|s     # уникальные значения
histogram:45|h        # распределение значений

StatsD vs Prometheus vs InfluxDB Line Protocol

Применение StatsD на хостинге

StatsD полезен для мониторинга бизнес-метрик приложения в реальном времени: количество регистраций, успешных платежей, ошибок API. На VPS StatsD работает как лёгкий сервис (~30 MB RAM). Telegraf принимает StatsD и пересылает в InfluxDB. Grafana визуализирует метрики. Стек StatsD + Telegraf + InfluxDB + Grafana занимает меньше ресурсов, чем ELK Stack.