Развёртывание SigNoz на VPS: комплексный мониторинг приложений (logs, metrics, traces)

Что мы настраиваем и зачем

В современном мире разработки и эксплуатации программного обеспечения критически важно иметь полное представление о том, что происходит с вашими приложениями и инфраструктурой. Именно для этого существуют системы мониторинга и сбора телеметрии. Мы будем разворачивать SigNoz — комплексное решение с открытым исходным кодом, которое объединяет в себе функционал для сбора и анализа логов (logs), метрик (metrics) и трассировок (traces).

Логи предоставляют детализированную информацию о событиях внутри приложения, помогая отлаживать ошибки и понимать последовательность действий. Метрики — это числовые данные, которые показывают производительность и состояние системы (например, загрузка CPU, использование памяти, количество запросов в секунду). Трассировки (или distributed tracing) позволяют отслеживать путь запроса через множество микросервисов, выявляя узкие места и задержки в сложной архитектуре.

В итоге, развернув SigNoz, вы получите единую панель управления, где сможете:

• Собирать и централизованно хранить логи всех ваших приложений.
• Визуализировать метрики производительности и создавать кастомные дашборды.
• Отслеживать запросы на всем их пути через распределенные системы, выявляя задержки.
• Настраивать алерты на основе пороговых значений метрик или паттернов в логах.
• Быстро диагностировать проблемы и сокращать время простоя.

Альтернативы и почему self-hosted на VPS

Существует множество решений для мониторинга. Среди популярных коммерческих облачных сервисов можно выделить Datadog, New Relic, Dynatrace. Они предлагают богатый функционал, но их стоимость может быть очень высокой, особенно для стартапов или проектов с ограниченным бюджетом. Кроме того, вы полностью зависите от их инфраструктуры и политики ценообразования.

Среди решений с открытым исходным кодом широко известны ELK Stack (Elasticsearch, Logstash, Kibana) для логов, а также Prometheus и Grafana для метрик. Эти системы мощные, но требуют более сложной настройки и интеграции, так как изначально они не являются единым "коробочным" решением для всех трех столпов observability. SigNoz же стремится предоставить интегрированный опыт "из коробки" для логов, метрик и трассировок, используя популярные стандарты, такие как OpenTelemetry.

Развертывание SigNoz на собственном VPS или выделенном сервере дает вам полный контроль над данными, безопасностью и расходами. Вы платите только за ресурсы сервера, избегая дорогих тарифов за объем данных. Это идеальный выбор для разработчиков, стартапов и компаний, которым нужна мощная, но экономичная система мониторинга без привязки к конкретному облачному провайдеру.

Какой VPS-конфиг нужен под эту задачу

Выбор подходящего VPS или выделенного сервера для SigNoz зависит от объема данных, которые вы планируете собирать, и количества приложений/сервисов, которые будут отправлять телеметрию. SigNoz, как и любая система observability, может быть достаточно требовательной к ресурсам, особенно к дисковой подсистеме и оперативной памяти.

Минимальные требования

Для небольших проектов, где вы мониторите 1-5 приложений со средним объемом логов и метрик (до нескольких десятков GB данных в месяц), минимальные требования будут следующими:

• CPU: 2 ядра (современные Intel Xeon или AMD EPYC).
• RAM: 4-8 GB. SigNoz использует ClickHouse для хранения данных, который любит оперативную память.
• Диск: 100-200 GB NVMe SSD. Скорость диска критически важна для записи и запросов к данным телеметрии. Обычные SATA SSD могут быть слишком медленными для интенсивной нагрузки.
• Сеть: 100 Mbps - 1 Gbps. Для сбора данных и доступа к UI.

Рекомендуемый VPS-план для большинства задач

Для большинства средних проектов, включающих до 10-20 приложений, сбора данных с нескольких серверов и хранением истории за 1-3 месяца, рекомендуются следующие характеристики:

• CPU: 4 ядра.
• RAM: 16-32 GB. Это позволит ClickHouse эффективно кэшировать данные и обрабатывать сложные запросы.
• Диск: 400-800 GB NVMe SSD. Больший объем для длительного хранения и высокая скорость для производительности.
• Сеть: 1 Gbps.

Такой VPS с указанными характеристиками обеспечит комфортную работу с SigNoz и запас для роста. Убедитесь, что выбранный провайдер предлагает NVMe SSD, так как это значительно влияет на производительность системы мониторинга.

Когда нужен dedicated, а не VPS

Выделенный сервер становится необходим, если вы планируете мониторить десятки или сотни сервисов, генерирующих огромные объемы данных (терабайты в месяц), или если вам требуется очень длительное хранение истории (более 3-6 месяцев). В этом случае вам понадобится:

• CPU: 8+ ядер.
• RAM: 64 GB и более.
• Диск: Несколько терабайт NVMe SSD в RAID-массиве для отказоустойчивости и производительности, или гибридные решения с быстрыми SSD для горячих данных и HDD для холодных.
• Сеть: 10 Gbps.

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

Локация: на что влияет

Выбор локации сервера для SigNoz важен по нескольким причинам:

• Задержка (Latency): Чем ближе сервер SigNoz к вашим приложениям, тем ниже задержка при отправке телеметрии. Это особенно важно для трассировок и метрик, где своевременность данных критична.
• Законодательство: Если вы работаете с чувствительными данными, убедитесь, что локация сервера соответствует требованиям местного законодательства о хранении данных.
• Стоимость: Цены на VPS могут варьироваться в зависимости от региона.

Обычно рекомендуется размещать SigNoz в том же географическом регионе, что и большинство ваших мониторируемых сервисов.

Подготовка сервера

Перед установкой SigNoz необходимо выполнить базовую подготовку вашего VPS. В качестве операционной системы мы будем использовать Ubuntu 24.04 LTS (актуальная версия на 2026 год), так как она предлагает отличную стабильность и широкую поддержку сообщества. Предполагается, что у вас есть доступ к серверу по SSH с правами root или пользователя с sudo.

1. Обновление системы

Всегда начинайте с обновления списка пакетов и их апгрейда до последних стабильных версий. Это обеспечит наличие актуальных патчей безопасности и совместимость.

sudo apt update -y          # Обновление списка пакетов
sudo apt upgrade -y         # Обновление установленных пакетов
sudo apt autoremove -y      # Удаление ненужных зависимостей

2. Создание нового пользователя и настройка sudo

Работа напрямую под root небезопасна. Создадим нового пользователя, добавим его в группу sudo и настроим SSH-доступ.

# Замените 'youruser' на желаемое имя пользователя
sudo adduser youruser
sudo usermod -aG sudo youruser # Добавление пользователя в группу sudo

Переключитесь на нового пользователя и настройте SSH-ключи для более безопасного входа:

su - youruser # Переключение на нового пользователя

# Создайте директорию .ssh, если ее нет, и установите права
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# Скопируйте ваш публичный SSH-ключ (id_rsa.pub)
# Замените 'ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ' на содержимое вашего ключа
echo "ВАШ_ПУБЛИЧНЫЙ_КЛЮЧ" > ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Отключите вход по паролю для root и разрешите только по ключу
# Отредактируйте файл /etc/ssh/sshd_config (выполнять от root или через sudo)
# Откройте новый SSH-сеанс с новым пользователем, чтобы убедиться, что вход работает, прежде чем закрывать текущий root-сеанс!

3. Настройка файрвола (UFW)

UFW (Uncomplicated Firewall) — это удобный интерфейс для iptables. Настроим его, чтобы разрешить только необходимые порты.

sudo apt install ufw -y              # Установка UFW
sudo ufw allow OpenSSH               # Разрешить SSH (порт 22)
sudo ufw allow http                  # Разрешить HTTP (порт 80)
sudo ufw allow https                 # Разрешить HTTPS (порт 443)
sudo ufw enable                      # Включить файрвол
sudo ufw status verbose              # Проверить статус

4. Установка Fail2ban

Fail2ban защищает сервер от атак методом перебора (brute-force) путем блокировки IP-адресов, с которых поступает слишком много неудачных попыток входа.

sudo apt install fail2ban -y         # Установка Fail2ban
sudo systemctl enable fail2ban       # Включение автозапуска сервиса
sudo systemctl start fail2ban        # Запуск сервиса

Fail2ban по умолчанию уже настроен для защиты SSH. Для более тонкой настройки можно создать файл /etc/fail2ban/jail.local.

5. Установка базовых утилит

Установим несколько полезных утилит, которые могут пригодиться в процессе установки и отладки.

sudo apt install curl wget git htop -y # Установка curl, wget, git и htop

Теперь ваш сервер готов к установке SigNoz.

Установка ПО — пошагово

SigNoz разворачивается с помощью Docker и Docker Compose, что значительно упрощает процесс установки и управления всеми его компонентами. Мы будем использовать актуальные версии Docker Engine и Docker Compose, а также последнюю стабильную версию SigNoz (предполагаем, что это будет версия 0.30+ к 2026 году).

1. Установка Docker Engine

Сначала установим Docker Engine на ваш сервер. Рекомендуется использовать официальный репозиторий Docker для получения самых свежих версий.

# Удаление старых версий Docker (если есть)
for pkg in docker.io docker-doc docker-compose docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin; do sudo apt remove $pkg; done

# Установка зависимостей
sudo apt update
sudo apt install ca-certificates curl gnupg lsb-release -y

# Добавление официального GPG ключа Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Добавление репозитория Docker в APT sources
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Обновление списка пакетов и установка Docker Engine
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

# Добавление текущего пользователя в группу docker для выполнения команд Docker без sudo
sudo usermod -aG docker youruser # Замените 'youruser' на ваше имя пользователя
newgrp docker # Примените изменения к текущей сессии или перелогиньтесь

Проверьте установку Docker:

docker run hello-world # Запуск тестового контейнера

Вы должны увидеть приветственное сообщение от Docker.

2. Установка SigNoz с помощью Docker Compose

SigNoz предоставляет готовые файлы Docker Compose для удобного развертывания.

# Создание директории для SigNoz
mkdir -p ~/signoz
cd ~/signoz

# Клонирование репозитория SigNoz
git clone -b main https://github.com/SigNoz/signoz.git

# Переход в директорию развертывания
cd signoz/deploy/

# Запуск SigNoz с использованием Docker Compose
docker compose -f docker-compose.yaml up -d # Запуск всех сервисов SigNoz в фоновом режиме

Этот процесс может занять несколько минут, пока Docker загружает все необходимые образы и запускает контейнеры. После завершения вы можете проверить статус контейнеров:

docker compose -f docker-compose.yaml ps # Проверка статуса запущенных контейнеров SigNoz

Вы должны увидеть список запущенных сервисов, таких как ClickHouse, Query Service, Frontend, OpenTelemetry Collector и другие.

По умолчанию SigNoz будет доступен на порту 3301 вашего VPS. Теперь можно перейти к конфигурации доступа.

Конфигурация SigNoz и приложений

После успешной установки SigNoz необходимо настроить к нему доступ и начать отправлять данные из ваших приложений. Мы также обеспечим безопасное соединение с UI SigNoz через HTTPS.

1. Первоначальный доступ к UI SigNoz

По умолчанию UI SigNoz доступен по адресу http://ВАШ_IP_АДРЕС:3301. Откройте его в браузере. При первом входе вам будет предложено создать учетную запись администратора. Задайте имя пользователя и надежный пароль.

2. Настройка HTTPS с помощью Caddy

Использование HTTP для доступа к панели мониторинга крайне нежелательно. Мы настроим Caddy — простой в использовании веб-сервер с автоматической выдачей и обновлением TLS-сертификатов Let's Encrypt — для обеспечения HTTPS-доступа.

Предварительные шаги:

1. Убедитесь, что ваш домен (например, signoz.yourdomain.com) указывает на IP-адрес вашего VPS.
2. Убедитесь, что порты 80 (HTTP) и 443 (HTTPS) открыты в вашем UFW (мы уже открыли их в разделе "Подготовка сервера").

Установка Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy -y # Установка Caddy

Конфигурация Caddyfile:

Создайте или отредактируйте файл /etc/caddy/Caddyfile. Замените signoz.yourdomain.com на ваш реальный домен.

# /etc/caddy/Caddyfile
signoz.yourdomain.com {
    # Автоматическая выдача и обновление TLS-сертификатов
    tls {
        # Используйте ваш email для уведомлений Let's Encrypt
        email [email protected]
    }

    # Проксирование всех запросов к SigNoz Frontend
    reverse_proxy localhost:3301 {
        # Добавление необходимых заголовков для корректной работы
        header_up Host {host}
        header_up X-Real-IP {remote_ip}
        header_up X-Forwarded-For {remote_ip}
        header_up X-Forwarded-Proto {scheme}
    }

    # Включение сжатия (опционально, но рекомендуется)
    encode gzip zstd

    # Логирование доступа (опционально)
    log {
        output file /var/log/caddy/access.log
        format json
    }
}

Создайте директорию для логов Caddy:

sudo mkdir -p /var/log/caddy
sudo chown caddy:caddy /var/log/caddy

Перезапуск Caddy:

sudo caddy validate -adapter caddyfile --config /etc/caddy/Caddyfile # Проверка конфигурации
sudo systemctl reload caddy # Перезагрузка Caddy для применения изменений
sudo systemctl enable caddy # Убедиться, что Caddy запускается при старте системы

Теперь вы можете получить доступ к SigNoz по адресу https://signoz.yourdomain.com.

3. Отправка данных в SigNoz с помощью OpenTelemetry

SigNoz активно использует OpenTelemetry (OTel) — открытый стандарт для сбора телеметрии. Для отправки логов, метрик и трассировок из ваших приложений вам нужно будет интегрировать OTel SDK в ваш код или использовать OTel Collector.

Пример для Node.js приложения (базовая трассировка):

Установите необходимые пакеты OpenTelemetry:

npm install @opentelemetry/sdk-node @opentelemetry/api @opentelemetry/auto-instrumentations-node @opentelemetry/exporter-otlp-proto-http @opentelemetry/sdk-trace-node

Создайте файл tracing.js:

// tracing.js
const opentelemetry = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-otlp-proto-http');

const traceExporter = new OTLPTraceExporter({
    url: 'http://localhost:4318/v1/traces', // Адрес SigNoz OpenTelemetry Collector
});

const sdk = new opentelemetry.NodeSDK({
  serviceName: 'my-node-app',
  traceExporter,
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start()
  .then(() => console.log('Tracing initialized'))
  .catch((error) => console.error('Error initializing tracing', error));

process.on('SIGTERM', () => {
  sdk.shutdown()
    .then(() => console.log('Tracing terminated'))
    .catch((error) => console.error('Error terminating tracing', error))
    .finally(() => process.exit(0));
});

Запустите ваше Node.js приложение с этим файлом:

node -r ./tracing.js your-app.js

Для других языков программирования и для отправки метрик/логов, процесс аналогичен: используйте соответствующие OTel SDK и экспортеры. OpenTelemetry Collector в SigNoz по умолчанию слушает порты 4317 (gRPC) и 4318 (HTTP) для трассировок, а также 4317/4318 для метрик и 4317 для логов. При отправке данных из приложения указывайте адрес localhost:4318 или localhost:4317, так как OTel Collector работает в том же Docker Compose стеке, что и само приложение SigNoz.

Для сбора логов с хоста или из других контейнеров можно настроить отдельный OpenTelemetry Collector или использовать Docker log driver, отправляющий логи в SigNoz.

4. Проверка работоспособности

После настройки приложений и отправки данных, зайдите в UI SigNoz (https://signoz.yourdomain.com). Перейдите в раздел "Traces", "Metrics" или "Logs". Вы должны увидеть поступающие данные. Если данных нет, проверьте:

• Логи контейнеров SigNoz: docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs
• Логи Caddy: sudo journalctl -u caddy.service
• Правильность настройки OTel SDK в вашем приложении.
• Доступность портов между приложением и SigNoz OTel Collector.

Бэкапы и обслуживание

Резервное копирование и регулярное обслуживание являются критически важными аспектами для любой производственной системы, особенно для системы мониторинга, которая хранит ценные данные. Потеря данных телеметрии может привести к невозможности анализа инцидентов и регрессий.

Что бэкапить

Для SigNoz необходимо бэкапить следующие компоненты:

1. Данные ClickHouse: Это основное хранилище всех логов, метрик и трассировок. Это самый большой и важный компонент.
2. Конфигурационные файлы SigNoz: Файлы docker-compose.yaml, .env, любые кастомные конфигурации OpenTelemetry Collector или другие параметры, которые вы могли изменить.
3. Конфигурация Caddy: Файл /etc/caddy/Caddyfile и директория с TLS-сертификатами (обычно /var/lib/caddy).

Простой скрипт автобэкапа

Мы создадим простой скрипт, который будет архивировать основные конфигурационные файлы и делать "горячий" бэкап данных ClickHouse. Для хранения данных ClickHouse можно использовать команды docker exec.

Создайте файл ~/signoz/backup_signoz.sh:

#!/bin/bash

# --- Конфигурация бэкапа ---
BACKUP_DIR="/var/backups/signoz_$(date +%Y%m%d%H%M%S)"
SIGNOZ_DEPLOY_PATH="/root/signoz/signoz/deploy" # Путь к вашему deploy/ SigNoz
CLICKHOUSE_CONTAINER="signoz-clickhouse" # Имя контейнера ClickHouse, можно узнать через docker ps
CLICKHOUSE_DATABASE="signoz" # Имя базы данных ClickHouse
RETENTION_DAYS=7 # Сколько дней хранить бэкапы

# --- Создание директории для бэкапа ---
echo "Создание директории бэкапа: $BACKUP_DIR"
sudo mkdir -p "$BACKUP_DIR"
if [ $? -ne 0 ]; then
    echo "Ошибка: Не удалось создать директорию бэкапа. Проверьте права."
    exit 1
fi

# --- Бэкап конфигурационных файлов ---
echo "Бэкап конфигурационных файлов..."
sudo cp -r "$SIGNOZ_DEPLOY_PATH" "$BACKUP_DIR/signoz_config"
sudo cp /etc/caddy/Caddyfile "$BACKUP_DIR/Caddyfile"
sudo cp -r /var/lib/caddy "$BACKUP_DIR/caddy_data" # Бэкап сертификатов Caddy

# --- Бэкап данных ClickHouse ---
echo "Бэкап данных ClickHouse..."
# ClickHouse поддерживает "горячий" бэкап с помощью команды ATTACH TABLE FROM DISK
# Этот метод копирует данные из активных партиций, что может быть ресурсоемким
# Более надежный способ - использование инструмента clickhouse-backup
# В рамках этого примера, мы сделаем дамп схемы и важных таблиц
# Для полного бэкапа ClickHouse лучше использовать специализированные инструменты:
# https://clickhouse.com/docs/en/operations/backup

# Пример: дамп схемы базы данных
sudo docker exec "$CLICKHOUSE_CONTAINER" clickhouse-client --query="SHOW CREATE DATABASE $CLICKHOUSE_DATABASE" > "$BACKUP_DIR/clickhouse_schema.sql"

# Пример: дамп данных небольших, но важных таблиц (например, метаданных)
# Для больших таблиц это неэффективно.
# sudo docker exec "$CLICKHOUSE_CONTAINER" clickhouse-client --query="SELECT  FROM signoz.traces ORDER BY timestamp LIMIT 1000 FORMAT CSV" > "$BACKUP_DIR/traces_sample.csv"

# Для полноценного бэкапа ClickHouse рекомендуется использовать clickhouse-backup:
# 1. Установить clickhouse-backup на хост: https://github.com/Altinity/clickhouse-backup
# 2. Настроить его для работы с контейнером ClickHouse.
# Пример команды с clickhouse-backup:
# sudo clickhouse-backup -c /etc/clickhouse-backup.yaml create --name signoz_full_backup

echo "Архивирование бэкапа..."
sudo tar -czvf "$BACKUP_DIR.tar.gz" -C "$(dirname "$BACKUP_DIR")" "$(basename "$BACKUP_DIR")"
if [ $? -ne 0 ]; then
    echo "Ошибка: Не удалось архивировать бэкап."
    exit 1
fi
sudo rm -rf "$BACKUP_DIR" # Удаление временной директории

echo "Бэкап успешно создан: $BACKUP_DIR.tar.gz"

# --- Удаление старых бэкапов ---
echo "Удаление старых бэкапов (старше $RETENTION_DAYS дней)..."
sudo find /var/backups/signoz_ -type f -mtime +"$RETENTION_DAYS" -delete
echo "Завершено."

Сделайте скрипт исполняемым:

chmod +x ~/signoz/backup_signoz.sh

Куда складывать бэкапы

Хранить бэкапы на том же сервере, что и оригинальные данные, крайне рискованно. Если сервер выйдет из строя, вы потеряете и данные, и бэкапы. Рекомендуется использовать:

• Внешнее S3-совместимое хранилище: Amazon S3, MinIO, Wasabi, Backblaze B2. Это экономичное и надежное решение. Вы можете использовать s3cmd или rclone для загрузки архивов.
• Отдельный VPS: Недорогой VPS с большим объемом диска, расположенный в другом дата-центре.
• Локальный NAS/сервер: Если у вас есть собственная инфраструктура.

Для автоматической загрузки на S3, вы можете добавить в скрипт бэкапа команду aws s3 cp "$BACKUP_DIR.tar.gz" s3://your-backup-bucket/ (после настройки AWS CLI).

Автоматизация бэкапов с Cron

Добавьте задачу в Cron, чтобы скрипт выполнялся регулярно (например, ежедневно в 3 часа ночи).

sudo crontab -e

Добавьте следующую строку в конец файла:

0 3   * /root/signoz/backup_signoz.sh >> /var/log/signoz_backup.log 2>&1

Это будет запускать скрипт каждый день в 03:00 и записывать вывод в лог-файл.

Обновления: rolling vs maintenance window

Обновление SigNoz:

SigNoz постоянно развивается. Для обновления до новой версии:

cd ~/signoz/signoz/deploy/
git pull # Получить последние изменения из репозитория
docker compose -f docker-compose.yaml pull # Скачать новые образы контейнеров
docker compose -f docker-compose.yaml up -d # Пересоздать контейнеры с новыми образами
docker image prune -f # Очистить старые неиспользуемые образы

Рекомендуется выполнять обновления в "окно обслуживания" (maintenance window), когда нагрузка на систему минимальна, так как обновление может вызвать кратковременную недоступность некоторых сервисов SigNoz. Всегда читайте release notes перед обновлением, чтобы быть в курсе возможных breaking changes.

Обновление ОС и Docker:

Регулярно обновляйте операционную систему и Docker Engine:

sudo apt update && sudo apt upgrade -y
sudo systemctl restart docker # Перезапуск Docker после обновления компонентов

Эти обновления также лучше проводить в окно обслуживания, так как перезапуск Docker может остановить все запущенные контейнеры на несколько секунд.

Troubleshooting + FAQ

В процессе развертывания и эксплуатации SigNoz могут возникнуть различные проблемы. Ниже приведены типичные вопросы и способы их решения.

1. SigNoz UI недоступен по IP-адресу или домену.

Что проверить:

• Статус Docker-контейнеров: Убедитесь, что все контейнеры SigNoz запущены.

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml ps

  Все сервисы должны быть в состоянии running. Если нет, проверьте логи проблемного контейнера:

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs signoz-frontend

• Файрвол (UFW): Убедитесь, что порты 80, 443 (для Caddy) и 3301 (для прямого доступа к SigNoz UI) открыты.

  sudo ufw status verbose

• Caddy: Если используете Caddy, проверьте его статус и логи.

  sudo systemctl status caddy

  sudo journalctl -u caddy.service

  Убедитесь, что ваш домен корректно разрешается в IP-адрес сервера.
• Конфликты портов: Проверьте, не занимают ли другие сервисы порты 80, 443 или 3301.

  sudo netstat -tulpn | grep -E "80|443|3301"

Как фиксить: Перезапустите проблемные сервисы Docker или Caddy. Откройте необходимые порты в UFW. Исправьте DNS-запись для домена.

2. В SigNoz не поступают логи, метрики или трассировки.

Что проверить:

• Настройки OpenTelemetry Collector: Убедитесь, что OTel Collector в SigNoz запущен и слушает нужные порты.

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs signoz-otel-collector

• Настройки приложения: Проверьте, что ваше приложение корректно настроено для отправки данных в OTel Collector SigNoz (обычно http://localhost:4318 или http://localhost:4317 из других контейнеров в том же Docker Compose сети).

  curl -v -X POST http://localhost:4318/v1/traces -d '{"resourceSpans":[]}'

  Это простой тест на доступность эндпоинта OTLP.
• Сетевая доступность: Если приложение находится на другом хосте, убедитесь, что его сеть может достучаться до портов OTel Collector на вашем VPS.
• Ошибки в логах приложения: Проверьте логи приложения, которое должно отправлять телеметрию, на наличие ошибок OTel экспорта.

Как фиксить: Исправьте конфигурацию приложения или OTel Collector. Проверьте сетевую связность между компонентами.

3. SigNoz работает медленно или потребляет много ресурсов.

Что проверить:

• Ресурсы сервера: Проверьте загрузку CPU, использование RAM и скорость диска на вашем VPS.

  htop

  df -h

  iostat -x 1 10

• ClickHouse: ClickHouse является основным потребителем ресурсов. Проверьте его логи на наличие ошибок или предупреждений.

  docker compose -f ~/signoz/signoz/deploy/docker-compose.yaml logs signoz-clickhouse

• Объем данных: Оцените объем поступающих данных. Возможно, ваш VPS просто не справляется с текущей нагрузкой.

Как фиксить: Увеличьте ресурсы VPS (CPU, RAM, NVMe SSD). Оптимизируйте приложения для уменьшения объема отправляемой телеметрии (например, сэмплирование трассировок). Настройте политику хранения данных в SigNoz для автоматического удаления старых данных.

4. Какой VPS-конфиг минимально подойдёт?

Для тестовых целей или очень небольших проектов (1-2 приложения, низкий объем данных) можно начать с 2 CPU, 4 ГБ ОЗУ и 100 ГБ NVMe SSD. Однако для любой серьезной эксплуатации, даже для небольших команд, рекомендуется минимум 4 CPU, 8-16 ГБ ОЗУ и 200 ГБ NVMe SSD для стабильной работы и возможности хранения данных за несколько недель.

5. Что выбрать — VPS или dedicated для этой задачи?

Выбор между VPS и выделенным сервером зависит от масштаба и требований к производительности. VPS подходит для большинства средних проектов (до 10-20 сервисов, несколько сотен GB данных в месяц) благодаря своей гибкости и стоимости. Выделенный сервер необходим для крупных инсталляций, где обрабатываются терабайты данных, требуется максимальная производительность ClickHouse, длительное хранение или строгие требования к изоляции ресурсов. Если вы сомневаетесь, начните с VPS и масштабируйтесь до выделенного сервера по мере роста потребностей.

6. Как обновить SigNoz до новой версии?

Для обновления SigNoz выполните следующие команды в директории ~/signoz/signoz/deploy/:

git pull                       # Получить последние изменения из репозитория SigNoz
docker compose -f docker-compose.yaml pull # Загрузить новые версии образов Docker
docker compose -f docker-compose.yaml up -d # Пересоздать контейнеры с новыми образами
docker image prune -f          # Очистить неиспользуемые старые образы Docker

Всегда проверяйте официальную документацию SigNoz на предмет специфических инструкций по обновлению для конкретной версии, так как иногда могут потребоваться дополнительные шаги.

Выводы и следующие шаги

Поздравляем! Вы успешно развернули SigNoz на своем VPS, настроили безопасный доступ через HTTPS и готовы начать собирать телеметрию из ваших приложений. Теперь у вас есть мощный инструмент для комплексного мониторинга, который предоставляет глубокое понимание производительности и поведения ваших систем, помогая оперативно реагировать на проблемы и принимать обоснованные решения.

Дальнейшие шаги для максимизации пользы от SigNoz включают:

• Интеграция всех приложений: Постепенно интегрируйте все ваши микросервисы и монолиты с OpenTelemetry SDK для отправки логов, метрик и трассировок в SigNoz.
• Настройка алертов: Создайте правила оповещения на основе ключевых метрик (например, высокая загрузка CPU, низкое свободное место на диске, увеличение ошибок в логах) или аномалий в трассировках, чтобы проактивно реагировать на потенциальные проблемы.
• Расширенные дашборды: Используйте возможности SigNoz для создания кастомизированных дашбордов, которые визуализируют наиболее важные для вас показатели и помогают отслеживать состояние системы с первого взгляда.
• Оптимизация хранения данных: Регулярно пересматривайте политику хранения данных в ClickHouse, чтобы балансировать между необходимостью в исторической информации и доступными дисковыми ресурсами.