SigNoz: наблюдаемость в одном сервисе

MAATRIX

Если у вас на сервере уже стоит Prometheus для метрик, Loki для логов и Jaeger для трассировки — вы наверняка замечали, что связать их вместе руками неудобно. Метрика показала аномалию, а чтобы понять, что произошло, приходится открывать три разные вкладки и вручную сопоставлять время. SigNoz решает именно эту проблему: это открытый инструмент наблюдаемости, который держит метрики, логи и трейсы в одном сервисе с единым интерфейсом.

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

Классический подход к observability — взять лучший инструмент под каждую задачу отдельно. Prometheus или VictoriaMetrics для метрик, Grafana Loki для логов, Jaeger или Zipkin для распределённой трассировки, Grafana поверх всего этого как единая точка визуализации. У такого набора есть реальные плюсы: каждый инструмент специализирован, у сообщества накоплена экспертиза, легко заменить один компонент, не трогая остальные.

Но за гибкость приходится платить операционной сложностью. Вот с чем сталкивается инженер на практике:

• Несколько систем на поддержке. У каждого инструмента свой релизный цикл, свои breaking changes при обновлении, свой набор алертов, которые могут упасть независимо друг от друга.
• Разные интерфейсы и модели данных. PromQL для метрик, LogQL для логов, отдельный UI для трассировки — переключение контекста между ними съедает время именно тогда, когда счёт идёт на минуты (инцидент в проде).
• Ручная корреляция. Самый болезненный момент: увидели скачок latency на графике метрик — и теперь нужно вручную вычислить временное окно, пойти в Loki, отфильтровать логи по этому окну и сервису, потом ещё пойти в Jaeger и поискать медленные трейсы за тот же период. Автоматической связки между тремя системами, если их разворачивали независимо, обычно нет.

Для инфраструктуры из одного-нескольких серверов, которую держит один инженер или небольшая команда, это ощутимая нагрузка. Поддерживать четыре разных сервиса (плюс сама Grafana) ради наблюдаемости за десятком контейнеров — часто overkill.

Что такое SigNoz и как он устроен

SigNoz — open source платформа наблюдаемости, которая с самого начала проектировалась как единый инструмент для метрик, логов и трассировки, а не как надстройка над тремя чужими системами. Ключевая архитектурная особенность — все три типа данных хранятся в одном движке (ClickHouse) и доступны через один UI.

Из чего состоит типичное развёртывание SigNoz:

• ClickHouse — колоночная база данных, куда пишутся метрики, логи и трейсы;
• Query Service — бэкенд, который обслуживает запросы из UI к ClickHouse;
• Frontend — веб-интерфейс: дашборды, поиск по логам, просмотр трейсов, алерты;
• OTel Collector — компонент на основе OpenTelemetry Collector, принимает данные от инструментированных приложений и агентов и пишет их в ClickHouse;
• Alertmanager — правила алертинга и маршрутизация уведомлений.

Такая архитектура даёт то, чего сложно добиться, склеивая отдельные инструменты постфактум: единую временную шкалу и единый набор меток (labels/attributes) для всех трёх типов данных, потому что они изначально пишутся в одну и ту же базу с общей моделью.

Установка SigNoz на VPS

Самый простой путь для одного сервера — Docker Compose из официального репозитория. Понадобится VPS с Docker и docker-compose-plugin, и запас оперативной памяти — ClickHouse довольно требователен к RAM, конкретные минимальные цифры под вашу нагрузку стоит смотреть в актуальной документации проекта, они менялись от релиза к релизу.

git clone -b main https://github.com/SigNoz/signoz.git
cd signoz/deploy
./install.sh

Скрипт установки сам поднимет docker-compose со всеми компонентами (ClickHouse, Query Service, Frontend, OTel Collector, Alertmanager) и покажет адрес и порт веб-интерфейса по завершении — уточните их в выводе скрипта или в docker-compose.yaml, так как порт по умолчанию может отличаться между версиями проекта.

Если предпочитаете разворачивать вручную, посмотрите на docker-compose.yaml в каталоге deploy/docker/ репозитория — там перечислены все сервисы и переменные окружения. Для продакшена стоит сразу вынести ClickHouse на отдельный диск (лучше NVMe — она пишет много данных при активной трассировке) и настроить retention, чтобы не заполнить диск за пару недель:

# пример переменной retention для трейсов в конфиге clickhouse
# точные имена параметров смотрите в вашей версии деплоя
TRACE_TTL_DURATION_HOURS: 72
LOG_TTL_DURATION_HOURS: 168
METRICS_TTL_DURATION_HOURS: 2160

После установки первым делом настройте базовую аутентификацию (в веб-интерфейсе создаётся первый администратор при первом заходе) и, если сервер смотрит в открытый интернет, закройте порт SigNoz снаружи через ufw или nginx с базовой авторизацией — сам SigNoz из коробки не рассчитан на то, чтобы торчать наружу без дополнительной защиты.

Отправка данных: совместимость с OpenTelemetry

Главная практическая причина, почему SigNoz легко встраивается в существующую инфраструктуру — он построен вокруг протокола OpenTelemetry (OTLP). Это значит, что если ваше приложение уже инструментировано через OpenTelemetry SDK — для сбора метрик, логов или трейсов — оно может отправлять данные напрямую в SigNoz, без специфичной привязки к какому-то одному вендору наблюдаемости.

Практически это выглядит так: приложение или агент экспортирует данные по OTLP (gRPC, порт 4317, или HTTP, порт 4318) на адрес OTel Collector, который идёт в комплекте с SigNoz:

# фрагмент конфига OpenTelemetry SDK / коллектора на стороне приложения
exporters:
  otlp:
    endpoint: "your-signoz-host:4317"
    tls:
      insecure: true  # для внутренней сети без TLS; для интернета настройте TLS

Для инфраструктуры, где уже используется автоинструментирование (например, готовые OTel-агенты для Node.js, Python, Java, Go), переход на SigNoz часто не требует переписывания кода приложения — достаточно поменять endpoint экспортёра. Это же работает и в обратную сторону: если вы позже захотите уйти от SigNoz на другой OTLP-совместимый бэкенд, приложение менять не придётся — что заметно снижает vendor lock-in по сравнению с проприетарными SaaS-решениями наблюдаемости.

Стоит оговориться: конкретные детали совместимости (какие именно OTel-семантические конвенции поддерживаются полностью, а какие — частично) стоит сверять с документацией той версии SigNoz, которую вы разворачиваете — экосистема OpenTelemetry активно развивается, и что было ограничением год назад, может быть уже закрыто.

Метрики, логи и трассировка в одном интерфейсе — как это выглядит на практике

Вот где единый инструмент оправдывает себя больше всего — в сценарии реального разбора проблемы. Возьмём типичный кейс: дашборд показывает рост p95 latency на одном из сервисов.

В классической связке из трёх отдельных инструментов вы бы:

1. Заметили аномалию в Grafana поверх Prometheus.
2. Скопировали временной диапазон и пошли в отдельный UI Loki фильтровать логи сервиса за это же окно.
3. Затем пошли в Jaeger, вручную выставили тот же диапазон и искали медленные трейсы того же сервиса.

В SigNoz эти три шага стянуты в один интерфейс:

• на графике метрики можно кликнуть на аномальную точку и перейти к трейсам того же сервиса за тот же период без повторного ввода фильтров;
• у каждого трейса есть привязанные логи того же запроса (если приложение прокидывает trace ID в логи — это стандартная практика при работе с OpenTelemetry);
• поиск по логам поддерживает фильтрацию по тем же атрибутам сервиса, что и метрики и трейсы (service name, environment, версия деплоя), потому что все три типа данных используют общую модель меток.

На практике это экономит не столько CPU-время сервера, сколько время инженера в момент инцидента — а это ресурс, которого обычно не хватает больше всего. Такая корреляция «из коробки» — прямое следствие того, что данные изначально пишутся в одну базу с общими метками, а не результат отдельной интеграции поверх независимых систем.

SigNoz vs отдельные инструменты: когда что выбирать

Единый инструмент — не универсальный ответ на все случаи. Вот практическое сравнение для self-hosted инфраструктуры:

Отдельно стоит сказать про масштаб: у крупной инфраструктуры с очень высоким объёмом трейсов или логов узкоспециализированные системы, заточенные именно под этот тип данных (например Loki именно под логи, с её моделью индексации только по меткам, а не по содержимому), иногда масштабируются предсказуемее, чем один общий движок под всё сразу. Но для read-инфраструктуры, которая типична для читателя self-hosted VPS-блога — один-несколько серверов, разумный объём трафика — единый инструмент вроде SigNoz обычно закрывает потребность с запасом, а операционная простота перевешивает теоретическую гибкость, которой вы, скорее всего, не воспользуетесь на таком масштабе.

Если вы уже развернули отдельно метрики через Prometheus и Grafana, логи через Grafana Loki или трассировку через Jaeger и это работает без нареканий — необязательно всё сносить и переезжать на SigNoz только ради унификации. Но если вы только начинаете строить observability с нуля на новом сервере, стоит сначала прикинуть, действительно ли вам нужна гибкость трёх раздельных систем, или единый инструмент закроет задачу с меньшими трудозатратами.

Частые вопросы