Logs, metrics, alerts: что смотреть после запуска

1. Логи приложения

Лог должен отвечать на вопрос: что сломалось, у какого пользователя, на каком endpoint и с каким request id.

level=error request_id=abc123 user_id=42 endpoint=/api/order
message="payment provider timeout"

2. Uptime checks

Минимум — внешний сервис или cron, который проверяет главную страницу и health endpoint.

1. Проверять каждые 1-5 минут.
2. Alert в Telegram при падении.
3. Отдельно проверять SSL срок действия.

3. Метрики сервера

• CPU стабильно не выше 80%.
• RAM не уходит в swap.
• Disk не заполняется логами.
• Количество 5xx ошибок не растёт.
• Очереди задач не накапливаются бесконечно.

4. Backups

Backup без restore test — это надежда, не защита. Проверяй восстановление на отдельной базе или staging сервере.

pg_dump app_db > backup.sql
createdb restore_test
psql restore_test < backup.sql

5. Alerts в Telegram

Alert должен приходить туда, где его увидят быстро. Для маленькой команды достаточно Telegram-уведомления при падении health endpoint, росте 5xx, заполнении диска и ошибках фоновых задач.

alert: site_down
target: https://example.com/health
notify: Telegram chat
repeat: every 5 minutes until resolved

6. Что проверять каждый день

1. Есть ли новые 500 ошибки.
2. Не растёт ли очередь задач.
3. Не закончится ли диск из-за логов.
4. Прошёл ли ночной backup.
5. Нет ли резкого падения заявок после deploy.

7. Шаблон postmortem

После серьёзной ошибки запиши короткий разбор. Это важнее, чем просто “починили”.

Когда началось:
Что сломалось:
Кого задело:
Причина:
Что исправили:
Как предотвратить повтор:

Incident checklist

1. Проверить health endpoint.
2. Проверить последние deploy изменения.
3. Посмотреть error logs.
4. Проверить диск, RAM, DB connection.
5. Откатить deploy, если причина в релизе.
6. Записать короткий postmortem.