Мониторинг ошибок веб-приложений и API в GlitchTip: развертывание легковесной замены Sentry на VDS в Docker Compose

Каждый веб-разработчик и владелец интернет-магазина сталкивался с неприятной ситуацией: пользователи нажимают кнопку оформления заказа, сталкиваются с белым экраном из-за непредвиденного JavaScript-сбоя, а бэкенд возвращает пятисотую ошибку. Узнавать о таких инцидентах из жалоб в службу поддержки — худший сценарий, приводящий к потере клиентов и выручки. Классическим стандартом мониторинга ошибок в индустрии является Sentry, однако его облачные тарифы начинаются от $26 в месяц с жесткими ограничениями по числу событий и трудностями оплаты картами РФ, а официальный self-hosted стек превратился в тяжеловесную систему, требующую от 16 ГБ оперативной памяти, Apache Kafka, ClickHouse и более десятка вспомогательных микросервисов.

Для проектов малого и среднего бизнеса, соло-разработчиков и веб-студий существует открытая альтернатива — GlitchTip. Это легковесная платформа мониторинга ошибок с открытым исходным кодом, на 100% совместимая со стандартными SDK Sentry. Она принимает аварийные дампы, трейсы стека, предупреждения фронтенда и бэкенда, группирует однотипные сбои и отправляет алерты команде. При этом GlitchTip официально требует от 256–512 МБ оперативной памяти и разворачивается за считанные минуты.

1. Архитектура GlitchTip v6: почему он требует минимум ресурсов

В актуальной мажорной ветке GlitchTip 6.2 архитектура платформы претерпела фундаментальную переработку. Разработчики полностью отказались от тяжеловесного Celery, заменив его на собственную асинхронную очередь фоновых задач django-vtasks, а слой кэширования перевели на django-vcache. Из Docker-образа удалены устаревшие серверы Gunicorn и Uvicorn — новым стандартом по умолчанию стал сверхбыстрый Rust-асинхронный ASGI-сервер Granian.

В режиме SERVER_ROLE=all_in_one воркер фоновых задач и планировщик встроены непосредственно в процесс веб-сервера Granian. Это позволяет поднимать полноценный мониторинг всего в трех компактных контейнерах:

2. Подготовка VDS и генерация криптографических ключей

Для развертывания потребуется сервер с чистой операционной системой Ubuntu 24.04 LTS или Debian 12, установленным Docker Engine с плагином Compose и направленной A-записью домена (например, errors.example.com). Если вы настраиваете чистый VDS, рекомендуем предварительно ознакомиться с руководством по базовому харденингу серверов.

Создадим изолированный рабочий каталог для сервиса и ограничим к нему доступ, чтобы конфигурационные файлы и переменные окружения не были доступны посторонним пользователям системы:

# Создаем рабочую директорию проекта
sudo mkdir -p /opt/glitchtip && cd /opt/glitchtip

# Устанавливаем строгие права доступа (чтение и запись только владельцу)
sudo chmod 700 /opt/glitchtip

GlitchTip требует защищенный секретный ключ (SECRET_KEY) для шифрования сессий и токенов авторизации, а также надежный пароль к базе данных PostgreSQL. Сгенерируем криптостойкие случайные строки длиной 32 байта с помощью утилиты openssl. Также вы можете воспользоваться онлайн-утилитой генератора надежных паролей SysKit для безопасного получения случайных секретов без спецсимволов:

# Генерация 64-символьного SECRET_KEY
openssl rand -hex 32

# Генерация надежного пароля для PostgreSQL
openssl rand -hex 24

3. Боевой манифест Docker Compose: GlitchTip 6.2, PostgreSQL и Redis

Сформируем конфигурационный файл переменных окружения /opt/glitchtip/.env с помощью команды sudo tee. В нем зафиксируем сгенерированные секреты, параметры подключения к базе данных, почтовую конфигурацию и политику хранения ивентов (по умолчанию 90 дней, чтобы старые трейсы автоматически удалялись):

# Создаем файл окружения от имени суперпользователя
sudo tee /opt/glitchtip/.env > /dev/null << 'EOF'
# Основные параметры GlitchTip
GLITCHTIP_DOMAIN=https://errors.example.com
SECRET_KEY=9a1b2c3d4e5f67890123456789abcdef0123456789abcdef0123456789abcdef
DATABASE_URL=postgres://glitchtip:pg_strong_password_here@postgres:5432/glitchtip
VALKEY_URL=redis://redis:6379

# Роль сервера: all_in_one объединяет веб-сервер, воркер django-vtasks и планировщик
SERVER_ROLE=all_in_one

# Политика регистрации и хранения логов
ENABLE_ORGANIZATION_CREATION=true
GLITCHTIP_RETENTION_DAYS=90
LOG_LEVEL=INFO

# Почтовые оповещения (по умолчанию консольный вывод для тестов;
# для продакшена укажите smtp://user:password@smtp.example.com:587)
EMAIL_URL=consolemail://
DEFAULT_FROM_EMAIL=glitchtip@example.com

# Параметры параллелизма ASGI-сервера Granian
GRANIAN_WORKERS=1
EOF

# Ограничиваем права доступа к файлу с секретами
sudo chmod 600 /opt/glitchtip/.env

Теперь создадим файл /opt/glitchtip/docker-compose.yml. Мы используем легковесные образы PostgreSQL 17 и Redis 7 на базе Alpine Linux, а также официальный релиз GlitchTip 6.2.6. Обратите внимание на директивы SERVER_ROLE: all_in_one (альтернатива в документации — GLITCHTIP_EMBED_WORKER=true) и привязку порта приложения строго к локальному интерфейсу 127.0.0.1:8000:8000 для защиты от несанкционированного доступа мимо системного брандмауэра UFW:

services:
  postgres:
    image: postgres:17-alpine
    restart: unless-stopped
    mem_limit: 512m
    cpus: 1.0
    environment:
      POSTGRES_USER: glitchtip
      POSTGRES_PASSWORD: pg_strong_password_here
      POSTGRES_DB: glitchtip
    command:
      - postgres
      - -c
      - max_connections=200
      - -c
      - max_locks_per_transaction=512
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U glitchtip -d glitchtip"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    mem_limit: 256m
    cpus: 0.5
    # Режим AOF гарантирует сохранение задач в очереди при перезагрузке,
    # а директива --save "" отключает избыточные RDB-дампы на диск
    command: redis-server --appendonly yes --save ""
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

  glitchtip:
    image: glitchtip/glitchtip:6.2.6
    restart: unless-stopped
    mem_limit: 768m
    cpus: 1.5
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    environment:
      SERVER_ROLE: all_in_one
    env_file:
      - .env
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - uploads_data:/code/uploads

volumes:
  postgres_data:
  redis_data:
  uploads_data:

Запустим контейнеры в фоновом режиме:

# Запуск сервисов через Docker Compose
sudo docker compose up -d

# Просмотр логов автоматической инициализации
sudo docker compose logs -f glitchtip

При первом старте GlitchTip автоматически выполняет миграции схемы базы данных (./manage.py migrate) с помощью транзакционных advisory-блокировок PostgreSQL, предотвращая состояния гонки. Если вы разворачиваете сервис в кластере Kubernetes через Helm, авто-миграции можно отключить переменной SKIP_INIT=true и запускать их отдельным Pre-Deploy шагом.

Проверить доступность локального HTTP-эндпоинта можно через терминал или с помощью нашего онлайн-инструмента проверки портов SysKit:

# Проверка доступности локального HTTP-эндпоинта
curl -I http://127.0.0.1:8000/

4. Настройка веб-сервера и SSL-сертификатов: Nginx и Caddy

Для безопасного приема дампов ошибок из браузеров клиентов и бэкенд-серверов требуется шифрованное HTTPS-соединение. Кроме того, входящие пакеты с трассировками стека и отчетами об авариях могут содержать объемные данные (включая source maps и дампы памяти), поэтому официальная документация GlitchTip рекомендует установить директиву client_max_body_size 40m;.

Рассмотрим настройку на базе популярного веб-сервера Nginx. Создадим конфигурационный файл виртуального хоста. Чтобы исключить проблему «курицы и яйца» (когда Nginx не может запуститься из-за отсутствия SSL-сертификата), сначала настраиваем базовый HTTP-прокси на 80 порту:

# /etc/nginx/sites-available/glitchtip.conf
server {
    listen 80;
    server_name errors.example.com;

    # Рекомендованный GlitchTip лимит на загрузку дампов и source maps (40 МБ)
    client_max_body_size 40m;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;

        # Таймауты для надежного приема событий
        proxy_connect_timeout 30s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }
}

Активируем сайт через символическую ссылку, проверяем синтаксис директив и выпускаем бесплатный SSL-сертификат Let's Encrypt через Certbot с автоматическим редиректом всех запросов на HTTPS:

# Активация конфигурации в Nginx
sudo ln -sf /etc/nginx/sites-available/glitchtip.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

# Выпуск SSL-сертификата с автоматическим HTTPS-редиректом
sudo certbot --nginx -d errors.example.com --redirect --non-interactive --agree-tos -m admin@example.com

Если вы предпочитаете современный веб-сервер Caddy со встроенным выпуском Let's Encrypt, конфигурация в /etc/caddy/Caddyfile выглядит еще компактнее:

errors.example.com {
    reverse_proxy 127.0.0.1:8000
    request_body {
        max_size 40MB
    }
}

После перезагрузки веб-сервера проверьте статус TLS-шифрования и цепочку сертификатов через онлайн-инструмент проверки SSL-сертификатов SysKit, чтобы убедиться в отсутствии проблем с доверием у браузеров.

5. Системные требования и выбор оптимального тарифа VDS

В официальной документации GlitchTip указано минимальное требование к памяти — от 256 МБ RAM в режиме all-in-one. В условиях реальной промышленной эксплуатации связка из PostgreSQL 17, Redis 7 и GlitchTip на Granian комфортно чувствует себя на тарифах с 1–2 ГБ RAM, оставляя достаточный запас оперативной памяти под системный дисковый кэш и пиковые всплески трафика.

Для надежного развертывания выбирайте VDS с аппаратной KVM-виртуализацией, скоростными NVMe-дисками и размещением в проверенных российских дата-центрах (Timeweb Cloud, Selectel, Beget). Это гарантирует минимальные задержки при отправке аварийных дампов из РФ, отсутствие санкционных рисков и оплату рублями без валютных карт:

6. Подключение клиентских SDK: JavaScript, Python и PHP

После завершения установки откройте в браузере адрес вашего инстанса (https://errors.example.com) и пройдите регистрацию первого пользователя. Он автоматически станет владельцем главной организации. Создайте новый проект (Project), выберите технологический стек и скопируйте сформированный DSN (Data Source Name) вида https://<public_key>@errors.example.com/<project_id>.

Подключение в JavaScript / Frontend (React, Vue, SPA)

Установите официальный пакет Sentry для браузера через npm или yarn:

npm install @sentry/browser

Инициализируйте клиент в точке входа вашего приложения (например, main.js или index.tsx):

import * as Sentry from "@sentry/browser";

Sentry.init({
  dsn: "https://d1a2b3c4d5e6f7a8b9c0@errors.example.com/1",
  environment: "production",
  release: "shop-frontend@1.4.0",
  // Доля трейсов производительности (1.0 = 100%, 0.1 = 10% для умеренной нагрузки)
  tracesSampleRate: 0.2,
});

// Тестовая проверка отправки инцидента
// Sentry.captureException(new Error("Тестовый сбой оформления заказа"));

Подключение в Python / Backend (FastAPI, Django, Flask)

Установите официальный SDK для Python:

pip install sentry-sdk

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

import sentry_sdk

sentry_sdk.init(
    dsn="https://d1a2b3c4d5e6f7a8b9c0@errors.example.com/1",
    environment="production",
    traces_sample_rate=0.2,
    # Автоматический перехват необработанных исключений
    send_default_pii=False,
)

Подключение в PHP (Laravel, Symfony, чистый PHP)

Для классических PHP-приложений установите базовый SDK через Composer:

composer require sentry/sentry

Если вы работаете с фреймворком Laravel, используйте официальный пакет интеграции composer require sentry/sentry-laravel. В чистом PHP инициализация выполняется следующим образом:

<?php
require_once __DIR__ . '/vendor/autoload.php';

\Sentry\init([
    'dsn' => 'https://d1a2b3c4d5e6f7a8b9c0@errors.example.com/1',
    'environment' => 'production',
    'traces_sample_rate' => 0.2,
]);

// Исключения автоматически перехватываются и передаются в GlitchTip
// throw new Exception("Сбой подключения к шлюзу платежей");
?>

7. Настройка правил алертов и мгновенных уведомлений в Telegram

Главная ценность мониторинга — скорость реакции дежурного инженера. GlitchTip поддерживает отправку уведомлений через Email, Generic Webhook, Discord, Slack, Microsoft Teams, Zulip, Feishu и Ntfy. Если вы используете собственный сервер пуш-уведомлений, настроенный по нашему руководству развертывания Ntfy в Docker Compose, вы можете подключить его в интерфейсе в разделе Project Settings → Alerts.

Для отправки алертов напрямую в рабочий Telegram-чат дежурных специалистов настроим легковесный вебхук-ретранслятор на Python. Создадим скрипт-обработчик /opt/glitchtip/telegram_relay.py, который принимает JSON-пакет от GlitchTip и отправляет аккуратно отформатированное HTML-сообщение в Telegram:

# /opt/glitchtip/telegram_relay.py
import os
import json
import html
import urllib.parse
import urllib.request
from http.server import HTTPServer, BaseHTTPRequestHandler

TELEGRAM_BOT_TOKEN = os.getenv("TELEGRAM_BOT_TOKEN", "123456789:ABCdefGhIJKlmNoPQRstuVWXyz")
TELEGRAM_CHAT_ID = os.getenv("TELEGRAM_CHAT_ID", "-1001234567890")

class WebhookHandler(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers.get('Content-Length', 0))
        body = self.rfile.read(length)
        try:
            data = json.loads(body.decode('utf-8'))
        except Exception:
            data = {}

        # Извлекаем параметры ошибки из вебхука GlitchTip
        event = data.get('event', {})
        project = data.get('project_name', 'GlitchTip')
        title = event.get('title') or data.get('title') or 'Неизвестное исключение'
        issue_url = data.get('issue_url') or ''

        # Экранируем спецсимволы в тексте для parse_mode='HTML'
        title_safe = html.escape(str(title))
        project_safe = html.escape(str(project))

        # Формируем сообщение в валидном HTML-режиме Telegram (без Markdown-звездочек)
        if issue_url:
            link_html = f"\n🔗 <a href='{issue_url}'>Открыть трейс в GlitchTip</a>"
        else:
            link_html = ""

        message = (
            f"🚨 <b>Сбой в проекте {project_safe}</b>\n\n"
            f"<b>Ошибка:</b> <code>{title_safe}</code>"
            f"{link_html}"
        )

        tg_url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"
        payload = urllib.parse.urlencode({
            'chat_id': TELEGRAM_CHAT_ID,
            'text': message,
            'parse_mode': 'HTML',
            'disable_web_page_preview': 'true'
        }).encode('utf-8')

        req = urllib.request.Request(tg_url, data=payload)
        try:
            with urllib.request.urlopen(req, timeout=10) as resp:
                self.send_response(200)
                self.end_headers()
                self.wfile.write(b"OK")
        except Exception as e:
            self.send_response(500)
            self.end_headers()
            self.wfile.write(str(e).encode('utf-8'))

if __name__ == '__main__':
    server = HTTPServer(('127.0.0.1', 9005), WebhookHandler)
    server.serve_forever()

Для тестовой проверки отправки сообщения в Telegram из командной строки используйте вызов curl со строгими обратными слэшами и флагом --data-urlencode, гарантирующим корректную передачу спецсимволов и переносов строк:

# Тестовая проверка доставки в Telegram через CLI
MESSAGE="🚨 Тестовый алерт GlitchTip: сервис работает в штатном режиме"
curl -s -X POST "https://api.telegram.org/bot123456789:ABCdefGhIJKlmNoPQRstuVWXyz/sendMessage" \
  -d "chat_id=-1001234567890" \
  --data-urlencode "text=$MESSAGE" \
  -d "parse_mode=HTML"

8. Политика хранения данных, автоочистка и резервное копирование базы

При активном трафике сотни сайтов могут генерировать миллионы записей трассировок, что неизбежно приводит к росту объема базы данных. В GlitchTip встроен механизм автоматического секционирования таблиц (PostgreSQL table partitioning), работающий с версии 4.0 (в версии 6.0 логика партиционирования переведена на собственный PartitionManager). Переменная GLITCHTIP_RETENTION_DAYS=90 в файле .env автоматически удаляет устаревшие партиции событий старше 90 дней, не создавая блокировок и не замедляя работу базы данных.

Для защиты данных настроим ежедневное автоматическое резервное копирование базы данных PostgreSQL в сжатый архив с автоматической ротацией старых копий. Создадим скрипт /opt/glitchtip/backup.sh:

#!/usr/bin/env bash
set -eo pipefail

BACKUP_DIR="/var/backups/glitchtip"
PROJECT_DIR="/opt/glitchtip"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/glitchtip_db_$DATE.sql.gz"

mkdir -p "$BACKUP_DIR"
cd "$PROJECT_DIR"

# Выполняем согласованный дамп базы через pg_dump внутри контейнера
docker compose exec -T postgres pg_dump -U glitchtip glitchtip | gzip > "$BACKUP_FILE"

# Устанавливаем строгие права доступа к архиву
chmod 600 "$BACKUP_FILE"

# Удаляем резервные копии старше 14 дней для экономии места
find "$BACKUP_DIR" -type f -name "glitchtip_db_*.sql.gz" -mtime +14 -delete

echo "[$DATE] Резервная копия базы GlitchTip успешно создана: $BACKUP_FILE"

Сделаем скрипт исполняемым и добавим его в системный планировщик cron на запуск каждую ночь в 03:00:

# Делаем скрипт исполняемым
sudo chmod +x /opt/glitchtip/backup.sh

# Добавляем задачу в crontab суперпользователя
(sudo crontab -l 2>/dev/null; echo "0 3 * * * /opt/glitchtip/backup.sh >> /var/log/glitchtip_backup.log 2>&1") | sudo crontab -

9. Траблшутинг: типичные сбои и их быстрое устранение

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

10. Обновление GlitchTip до новых версий

Разработчики GlitchTip регулярно выпускают минорные обновления с улучшениями производительности и новыми коннекторами. Благодаря автоматическому применению миграций на старте контейнера, процесс обновления сводится к трем простым командам:

# Переходим в каталог проекта
cd /opt/glitchtip

# Загружаем свежие версии образов
sudo docker compose pull

# Перезапускаем сервис с автоматическим накатыванием миграций
sudo docker compose down && sudo docker compose up -d

Перед мажорными обновлениями рекомендуется обязательно выполнить внеочередной бэкап базы данных с помощью скрипта /opt/glitchtip/backup.sh.

11. Итоговый чек-лист проверки контура перед запуском в продакшен

Перед тем как переключать DSN в боевых веб-сервисах на новый сервер мониторинга, убедитесь в соблюдении всех требований безопасности и надежности:

• Роль сервера: В docker-compose.yml задана директива SERVER_ROLE: all_in_one, активирующая встроенный воркер и планировщик задач.
• Шифрование и SSL: Сертификат выпущен корректно, при обращении по HTTP срабатывает автоматический 301-редирект на HTTPS. Проверено через SSL Checker.
• Изоляция портов: Порт GlitchTip привязан строго к 127.0.0.1:8000. База данных PostgreSQL и Redis не имеют внешних пробросов в интернет. Проверено через Port Checker.
• Регистрация: Переменная ENABLE_ORGANIZATION_CREATION=false установлена в .env после создания администратора, чтобы закрыть несанкционированную регистрацию.
• Алерты в Telegram: Тестовое исключение успешно отображается в интерфейсе GlitchTip и доставляется ботом в рабочий чат с кликабельной ссылкой на инцидент.
• Резервное копирование: Скрипт бэкапа добавлен в cron и формирует валидный gzip-дамп базы данных.