# Мониторинг и алертинг

Строим наблюдаемость: метрики, логи, дашборды и alert rules, по которым понятно, что сломалось и насколько это срочно.

## Метрики

Сбор с серверов, служб, баз и приложений; хранение с разумной глубиной; дашборды под три разных вопроса:

- **Дежурному** — что горит прямо сейчас.
- **Инженеру** — где именно узкое место.
- **Руководителю** — как система живёт в целом за месяц.

## Логи

Централизованный сбор с разбором по полям, чтобы поиск шёл по запросу, а не по десяти серверам через ssh. Хранение по срокам, отдельные правила для приложений и для системных журналов.

## Алерты

Alert rule должен означать «нужно вмешаться», а не «посмотрите, тут циферка подросла». Поэтому:

- пороги ставятся по реальному поведению системы, а не по круглым числам;
- у каждого алерта есть описание: что произошло, чем грозит, с чего начать разбор;
- шум вычищается — алерт, на который все привыкли не реагировать, вреден.

## Дежурства

Настраиваем маршрутизацию: кто получает уведомление, куда оно приходит, что происходит, если никто не ответил. По желанию берём дежурство на себя в рамках согласованного графика.

## Что получает заказчик

Ответ на вопрос «работает ли у нас всё» без похода по серверам, и разбор аварии по данным, а не по воспоминаниям.

Как это выглядело на практике — в кейсе [«Инфраструктура разработчика 1С на постоянном обслуживании»](/cases/1c-support).