Observability bootstrap

Observability Bootstrap

Отвечает на вопрос соло-разработчика: «как я узнаю, что прод сломался, раньше пользователей?» Стек: Linux VPS, systemd + nginx + postgres + redis, без Docker. Конфиги авторятся на Windows, применяются на сервере.

Когда применять

• Новый сервис уезжает в прод, наблюдаемости нет вообще.
• «Узнаю о падениях от пользователей» — нужно закрыть слепые зоны.
• Аудит: что из наблюдаемости уже есть и чего не хватает.

Контекст — установить ПЕРВЫМ делом

1. Стек и тип сервиса — Django / FastAPI (веб) или aiogram-бот (воркер без HTTP). Для бота healthcheck-эндпоинта нет — liveness через systemd watchdog или heartbeat-файл.
2. Что уже есть — Grep по проекту: sentry_sdk, LOGGING, /health, WatchdogSec в unit-файлах, внешние мониторы. Не дублируй существующее.
3. Бюджет — дефолт: бесплатные тиры (Sentry free, UptimeRobot free, journald без внешнего лог-стора). Платное — только по явному запросу.

Четыре слоя (внедряй по приоритету)

#	Слой	Инструмент	Закрывает
1	Ошибки	Sentry SDK	исключения с трейсбеком и контекстом, release-теги
2	Живость	healthcheck + внешний uptime + systemd	«сервис умер/завис», ошибки конфигурации
3	Логи	структурный JSON в journald + ротация	диагностика инцидентов постфактум
4	Ресурсы	cron-скрипт алертов	диск заполнен, память, истекающий TLS-сертификат

Слои 1–2 обязательны для любого прод-сервиса; 3–4 — сразу после.

Процесс

Режим аудита: пройди слои 1–4 по проекту и unit-файлам, выдай gap-таблицу (слой → есть/нет → риск → рекомендация) с уровнями риска: CRITICAL — ошибок не видно вообще (нет ни Sentry, ни доступных логов); HIGH — нет liveness (падение заметят пользователи); MEDIUM — нет ротации/алертов ресурсов; LOW — улучшения.

Режим генерации — по слоям:

1. Sentry. sentry_sdk.init(dsn=env, environment=..., release=...) — в settings.py (Django), lifespan (FastAPI), entrypoint бота (aiogram). DSN — только из EnvironmentFile, не в коде. traces_sample_rate — 0 или низкий (не жечь квоту). Проверка: sentry_sdk.capture_message("deploy test") одноразово.
2. Healthcheck. Эндпоинт /healthz: проверяет БД (SELECT 1) и redis (PING), отвечает 200/503 без секретов в теле; в nginx — location /healthz без логирования access. Для бота — WatchdogSec=60 в unit + sd_notify WATCHDOG=1 из фонового таска (или heartbeat-файл + cron-проверка возраста).
3. Внешний uptime. UptimeRobot/аналог на https://домен/healthz, интервал 1–5 мин, алерт в Telegram/email. Внешний — потому что мониторинг на том же VPS умирает вместе с ним.
4. Логи. Логи в stdout → journald (unit уже пишет туда); формат JSON (python-json-logger или ручной Formatter): timestamp, level, logger, message, request_id. journalctl -u app -o json становится грепабельным. Ротация journald: SystemMaxUse=500M в journald.conf. Файловые логи (если есть) — logrotate.
5. Ресурсные алерты. Cron-скрипт (диск > 85%, память, openssl x509 -enddate на сертификат < 14 дней) → уведомление в Telegram через Bot API (curl). Это дешёвая замена Prometheus для одного VPS.

Каждый конфиг выдавай с пометкой, куда он кладётся на сервере и как проверить, что работает (одна команда → ожидаемый вывод).

Быстрый чеклист

• Sentry ловит тестовое исключение; DSN в EnvironmentFile.
• /healthz отвечает 200 и проверяет БД+redis (или watchdog для бота).
• Внешний uptime-монитор шлёт алерт (проверено остановкой сервиса).
• Логи структурные, в journald, с ротацией.
• Алерты: диск, память, TLS-срок.
• Ни один секрет не попал в логи и healthcheck-ответ.

Связь с библиотекой навыков

• vps-deploy-auditor — базовый деплой (unit-файлы, nginx), поверх которого ставится наблюдаемость; его аудит проверяет Restart=, этот навык — «а узнаешь ли ты о падении».
• vps-incident-triage — runbook, когда алерт уже сработал.
• 500-error-eliminator — конкретная Django-ошибка, которую Sentry поймал.
• harness-engineering — вшей проверку слоёв 1–2 в Definition of Done деплоя.