Мониторинг, алертинг и бэкапы

01Метрики, логи и трейсы: три взгляда на одну систему

Метрики — это числа во времени: запросы в секунду, доля ошибок, время ответа, CPU, свободное место на диске, длина очереди. Их дёшево хранить, они идеальны для дашбордов и алертов, но говорят, что что-то не так, а не что именно. Логи — события с отметкой времени и подробностями: вот этот запрос, этот пользователь, это исключение и стектрейс. Они отвечают, что случилось, но искать по ним в больших объёмах дорого, поэтому пишите их в JSON с единообразными полями. Трейсы прослеживают один запрос через сервисы: вызов API, запросы к базе, обращение к платёжному провайдеру — каждый со своей длительностью, так что видно, куда ушло время. OpenTelemetry — вендор-нейтральный стандарт для всех трёх. Начните с метрик и логов; трейсинг добавляйте, когда у вас несколько сервисов общаются друг с другом.

• Метрики: всё ли в порядке? (агрегированные числа)
• Логи: что именно произошло? (отдельные события)
• Трейсы: на что этот запрос потратил время? (один запрос, много переходов)

02Prometheus, Grafana и Loki

Prometheus — база временных рядов, которая каждые несколько секунд забирает (scrape) метрики по HTTP с целевых сервисов. Exporter'ы отдают метрики того, что вы не писали сами: node_exporter — CPU, память и диск, postgres_exporter — базу данных, а ваше приложение может отдавать собственный эндпоинт /metrics. Запросы пишутся на PromQL, там же задаются правила алертов; затем Alertmanager группирует, дедуплицирует и направляет эти алерты в почту, Slack или на пейджер. Grafana рисует дашборды поверх Prometheus и многих других источников. Loki дёшево хранит логи, индексируя только метки вроде app, environment и level, а не весь текст, а Grafana Alloy — это сборщик, который отправляет в него логи и метрики. Вместе они дают self-hosted стек, который спокойно работает рядом с приложением на Docker Compose.

1groups:
2  - name: host
3    rules:
4      - alert: DiskAlmostFull
5        expr: node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} < 0.15
6        for: 15m
7        labels: { severity: warning }
8        annotations:
9          summary: "Less than 15% disk left on {{ $labels.instance }}"
10      - alert: HighErrorRate
11        expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
12        for: 10m
13        labels: { severity: critical }

03Проверки доступности, трекинг ошибок и алерты без спама

Uptime-проверка стучится на ваш сайт снаружи каждую минуту, как это сделал бы пользователь: отдаёт ли главная 200, действителен ли TLS-сертификат ещё хотя бы две недели, подтверждает ли health-эндпоинт, что база отвечает. Инструменты вроде Uptime Kuma можно хостить самому; облачные сервисы проверяют из нескольких регионов. Трекинг ошибок (Sentry для веба и бэкенда, Firebase Crashlytics для мобильных) группирует исключения и падения, показывает стектрейс, релиз и затронутых пользователей. Что касается алертов: будите человека только из-за симптомов, которые чувствуют пользователи (сайт лежит, много ошибок, не работает оформление заказа), а причины вроде высокой загрузки CPU отправляйте на дашборд или в низкоприоритетный канал. Требуйте, чтобы условие держалось несколько минут, прежде чем срабатывать, группируйте связанные алерты, и пусть каждый алерт ведёт на runbook с объяснением, что проверить в первую очередь.

• Алертите по симптомам, расследуйте причины.
• По каждому вызову должно быть понятно, что делать; если действовать никому не нужно, это не повод будить.
• Раз в месяц пересматривайте шумные алерты и удаляйте или донастраивайте их.

04Бэкапы: правило 3-2-1, снапшоты и настоящие бэкапы

Правило 3-2-1: держите три копии данных на двух разных типах носителей, причём одну — вне площадки. Современное расширение добавляет одну неизменяемую или офлайн-копию, чтобы её не могли удалить ни ransomware, ни украденный админский ключ, и ноль ошибок после проверенного восстановления. Снапшот провайдера копирует весь диск на определённый момент. Из него быстро восстановить сервер целиком, но обычно он живёт в том же аккаунте провайдера, а снапшот работающей базы может оказаться неконсистентным. Настоящий бэкап — это консистентная копия на уровне приложения, например вывод pg_dump или mysqldump плюс загруженные файлы, хранящаяся в другом месте и зашифрованная. Используйте оба: снапшоты — для быстрого восстановления сервера целиком, логические бэкапы — для точного и переносимого восстановления данных.

1#!/usr/bin/env bash
2set -euo pipefail
3STAMP=$(date +%F_%H%M)
4pg_dump -Fc -U app appdb > /backups/appdb_$STAMP.dump
5 
6# encrypted, deduplicated, off-site copy (S3-compatible storage)
7export RESTIC_REPOSITORY=s3:https://s3.example.com/your-backup-bucket
8restic backup /backups /var/www/app/shared/storage
9restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
10restic check

05Проверка восстановления, RPO и RTO

Стратегию бэкапов определяют два числа, и их нужно согласовать с бизнесом, а не угадывать силами инженеров. RPO (recovery point objective) — сколько данных вы можете позволить себе потерять, в единицах времени: с ночными дампами RPO — до 24 часов, с непрерывным архивированием WAL или отправкой binlog'ов — минуты. RTO (recovery time objective) — сколько вы можете простаивать, пока идёт восстановление. А затем докажите, что укладываетесь в них. По расписанию восстанавливайте последний бэкап во временную базу или на временный сервер, выполняйте несколько проверочных запросов, убеждайтесь, что загруженные файлы открываются, и засекайте время всего процесса. Запишите шаги в runbook, чтобы любой в команде смог сделать это в стрессовой ситуации.

1# monthly restore drill into a throwaway database
2createdb restore_test
3pg_restore --no-owner -d restore_test /backups/appdb_latest.dump
4psql -d restore_test -c "SELECT count(*), max(created_at) FROM orders;"
5dropdb restore_test

06SLI, SLO, error budget и алерты по burn rate

Индикатор уровня сервиса (SLI) — это измеряемая доля хороших событий среди всех событий, например доля запросов, на которые успешно ответили быстрее чем за 500 мс. Цель уровня сервиса (SLO) — целевое значение для него на окне времени, скажем 99,9% за 30 дней. Оставшиеся 0,1% — это error budget: примерно 43 минуты полного простоя в месяц или более долгий период частичных ошибок. Вместо алерта на фиксированный процент ошибок алертите по тому, как быстро сгорает бюджет. Burn rate 1 расходует ровно весь бюджет за 30 дней; burn rate 14,4, продержавшийся час, съедает 2% месячного бюджета и заслуживает пейджа. Паттерн multiwindow из SRE workbook от Google проверяет длинное окно, чтобы убедиться, что проблема реальна, и короткое — чтобы убедиться, что она всё ещё происходит. Так алерты быстро срабатывают и быстро гаснут.

1# page: 2% of a 30-day 99.9% budget burned in 1 hour
2- alert: ErrorBudgetFastBurn
3  expr: |
4    (sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) > 14.4 * 0.001)
5    and
6    (sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 14.4 * 0.001)
7  labels: { severity: page }
8  annotations: { runbook: "https://wiki.example.com/runbooks/error-budget" }

07Внутренности Prometheus: серии, кардинальность и гистограммы

Prometheus хранит отдельный временной ряд для каждой уникальной комбинации имени метрики и значений лейблов. http_requests_total с лейблами method, route и status может дать несколько сотен серий — это нормально. Добавьте лейбл user_id или полный URL, и вы получите по серии на каждого пользователя или каждый URL: память взрывается, запросы ползут. Это и есть проблема кардинальности, самый частый способ сломать Prometheus. Держите лейблы в небольших ограниченных наборах, а детали с высокой кардинальностью отправляйте в логи или трейсы. Для латентности используйте гистограммы: приложение раскладывает запросы по бакетам, а histogram_quantile оценивает p95 или p99 в момент запроса по всем инстансам. Средние значения прячут медленный хвост, который пользователи как раз и чувствуют. Тяжёлые запросы из дашбордов и алертов стоит превратить в recording rules, которые считаются один раз за интервал. По умолчанию Prometheus хранит 15 дней; долгосрочное хранение обычно уходит в Thanos, Mimir или облачный бэкенд через remote_write.

1# p95 latency per route over 5 minutes
2histogram_quantile(0.95,
3  sum by (le, route) (rate(http_request_duration_seconds_bucket[5m])))
4 
5# recording rule: compute once, reuse in dashboards and alerts
6- record: route:http_request_duration_seconds:p95_5m
7  expr: histogram_quantile(0.95, sum by (le, route) (rate(http_request_duration_seconds_bucket[5m])))
8 
9# find the metrics with the most series
10topk(10, count by (__name__) ({__name__=~".+"}))

08Point-in-time recovery для PostgreSQL

Ночной дамп даёт RPO до суток. Point-in-time recovery (PITR) сокращает его до минут. PostgreSQL записывает каждое изменение в журнал предзаписи (WAL) до того, как применить его. Если у вас есть периодический base backup — физическая копия каталога данных — плюс каждый сегмент WAL с того момента, можно восстановить base backup и проиграть WAL до любого момента, например за минуту до того, как кто-то выполнил DELETE без WHERE. Включается это через archive_mode и команду архивации, которая отправляет каждый завершённый сегмент за пределы сервера. На практике берите специализированный инструмент вроде pgBackRest или WAL-G: они сами занимаются сжатием, шифрованием, ретеншеном, параллельным восстановлением и проверкой и складывают всё в объектное хранилище. Восстановление: разложите base backup, задайте recovery_target_time и создайте файл recovery.signal. Управляемые базы дают то же самое одной кнопкой, но репетировать всё равно нужно.

1# postgresql.conf (with pgBackRest)
2wal_level = replica
3archive_mode = on
4archive_command = 'pgbackrest --stanza=app archive-push %p'
5archive_timeout = 60          # ship at least once a minute
6 
7# restore to just before the mistake
8pgbackrest --stanza=app --type=time \
9  --target="2026-11-05 14:31:00+00" --target-action=promote restore

09Защита самих бэкапов

Современный ransomware и злонамеренные инсайдеры первым делом бьют по бэкапам, так что исходите из того, что атакующий с учётными данными сервера попытается их удалить. Три защиты работают вместе. Раздельные учётные данные: сервер должен уметь добавлять новые бэкапы, но не удалять старые. У rest-server от restic есть режим append-only, а объектное хранилище позволяет выдать право на запись без права на удаление. Неизменяемость: S3 Object Lock (его предлагают и некоторые S3-совместимые провайдеры) хранит объекты в режиме write-once на время ретеншена; в режиме compliance никто, даже root аккаунта, не может его сократить. Независимый мониторинг: dead man's switch ждёт пинг после каждого успешного бэкапа и алертит, если пинга нет, — так ловятся тихо сломавшиеся cron-задачи. Ключ или пароль шифрования храните отдельно от сервера, например в менеджере паролей: зашифрованный бэкап без ключа — просто шум.

1# bucket must have versioning; lock new objects for 30 days
2aws s3api put-object-lock-configuration --bucket example-backups \
3  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'
4 
5# end of backup script: report success to a dead man's switch
6restic backup /backups && curl -fsS -m 10 --retry 3 https://hc-ping.example.com/your-check-id