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

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

Метрики

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

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

Логи

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

Алерты

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

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

Дежурства

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

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

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

Как это выглядело на практике — в кейсе «Инфраструктура разработчика 1С на постоянном обслуживании».