Какая метрика предупреждает о сбое
Интернет-банк лёг в обед, второй раз за неделю. На разборе дежурный открывает графики: за три часа до аварии загрузка процессора базы данных уже ползла вверх. Графики были, тревоги не было. Знакомо?
Мониторинг собирает сотни метрик, но никто не знает, какая из них действительно предупреждает о сбое, а какая просто шумит. Нужен не ещё один дашборд, а ответ по вашей же истории: какая метрика и за сколько часов до сбоя начинает вести себя не так, как обычно.
Задача метода
Сравнить журнал инцидентов с метриками мониторинга за тот же период и ответить на три вопроса:
- Какая метрика меняется перед сбоями? Процессор, память, трафик, диск - или узел вовсе перестаёт присылать данные.
- За сколько до сбоя? За 15 минут, за несколько часов или за сутки.
- Это предупреждение или совпадение? Как часто то же самое бывает в обычные дни, когда сбоя нет.
Что прислать: журнал инцидентов и выгрузку метрик (Zabbix, Grafana, Prometheus) за один и тот же период - от 14 дней и от 8 сбоев. Оба файла - одной загрузкой.
Как это считается
- 1. Два файла на одной оси времени
Система сводит время заявок и метрик, учитывает часовой пояс и находит узел мониторинга по имени объекта в заявке.
- 2. «Обычное» для каждого часа
У процессора в 10 утра одна норма, в 3 ночи - другая. Система помнит обычный уровень каждой метрики для каждого часа суток, будни и выходные отдельно. Ночное резервное копирование не считается странностью.
- 3. Окна перед сбоем
Смотрим, что было за 15 минут - 1 час, за 1-6 часов и за 6-24 часа до заявки: была ли метрика заметно выше или ниже обычного.
- 4. Сравнение с обычными днями
Те же часы в другие дни, когда сбоя не было. Если в обычный день процессор так высоко бывает в 1 случае из 100, а перед сбоями - в половине случаев, это не совпадение.
- 5. Защита от случайных находок
Метрик сотни, и какая-нибудь «угадает» сбои просто случайно. Система делает поправку на число метрик и требует, чтобы совпадения были в разные дни.
Важно: метрика, которая растёт до сбоя, - ещё не его причина. Отчёт называет возможные причины и какие данные их различат.
Что метод видит в реальных данных и от чего защищён
- Тревога сама открыла заявкуМониторинг увидел «процессор выше 90%» и через минуту создал заявку. Это одно и то же событие, а не предупреждение: система смотрит не ближе 15 минут до заявки, а заявки вида «High CPU on db-01» распознаёт как эхо тревоги.
- Заявку завели позже, чем начался сбойСервис упал в 12:00, заявку открыли в 12:40 - и метрика «росла за 40 минут до сбоя». Подъём меньше чем за час до заявки отчёт называет «ранний признак или начало сбоя», а не предвестником.
- Узел замолчал в момент сбояЭто признак самого сбоя. Отчёт скажет «узел замолкал в момент сбоя в 12 случаях из 15», но предупреждением это не назовёт.
- Метрика растёт после сбояПосле перезапуска служба разбирает очередь, и нагрузка держится пару часов. Если следующий сбой случился в эти часы, такой подъём предвестником не считается.
- День массовой аварииОдин плохой день с двадцатью заявками не создаёт находку: совпадения нужны в разные дни.
- Часовые данные за годZabbix хранит поминутную историю месяц, дальше - средние за час. На часовых данных опережение меньше часа не видно, и отчёт это говорит.
- Мало данныхМеньше 14 дней общего периода или меньше 8 сбоев - метод выводов не делает и пишет почему.
Надёжность проверки: метод проверен на искусственных месяцах и годах мониторинга - 12 серверов по три метрики, дневной ритм нагрузки, ночные копирования, шум. Настоящий предвестник за 3-6 часов найден в 40 месяцах из 40, при всего 8 сбоях - в 35 из 40. В обычных месяцах ложных находок не было ни разу, при 105 метриках - в 2 месяцах из 40.
Что делать с найденной метрикой
| Сценарий | Возможные причины | Как проверить | Что делать |
|---|---|---|---|
| Метрика растёт за часы до сбоя (процессор базы за 3-5 часов) | Ресурс кончается под нагрузкой; тяжёлое задание по расписанию; рост числа запросов | Открыть график метрики за сутки до трёх последних сбоев и расписание заданий на эти часы | Предупреждение дежурному на этот уровень; разобрать задание или нагрузку в рамках Problem-тикета |
| Метрика падает перед сбоем (свободная память за 2-6 часов) | Утечка памяти, зависший процесс, закончилось место | Как меняется метрика между перезапусками службы | Временно - плановый перезапуск до опасного уровня; по сути - исправить утечку |
| Подъём меньше чем за час | Скорее всего, это уже начало сбоя, который заметили не сразу | Есть ли в заявке время начала или обнаружения сбоя | Начать записывать время обнаружения; поставить тревогу на эту метрику, чтобы узнавать раньше пользователей |
| Метрика общего ресурса перед сбоями разных систем (канал ядра сети) | Системы зависят от одного узла | Схема зависимостей: через что работают эти системы | Мониторинг и резерв общего узла вместо ремонта каждой системы |
| Эхо тревоги (заявку открыл мониторинг по этой же метрике) | Порог уже настроен | - | Если тревога срабатывает слишком поздно - снизить порог или добавить длительность |
Пример. База данных интернет-банка
Вводные: банк, 12 серверов интернет-банка, по три метрики на сервер (процессор, свободная память, входящий трафик) за месяц с шагом 5 минут и журнал инцидентов - около 130 сбоев за тот же месяц.
Ситуация: сервер базы данных падает примерно раз в полтора дня. Каждый раз заявка «Сервис недоступен», инженеры перезапускают службу, и всё работает до следующего раза.
Что показал отчёт:
- Процессор сервера базы данных был выше обычного для этого часа примерно за 4,5 часа до сбоя - в 11 случаях из 22. В те же часы других дней - меньше чем в 1% случаев.
- Остальные 35 метрик перед сбоями вели себя как обычно.
В чём польза такого результата:
- Предупреждение заранее. Дежурный получает сигнал за несколько часов до вероятного сбоя, а не звонок от клиентов.
- Где искать причину. Не «всё подряд», а что нагружает базу в эти часы: отчёт по расписанию, тяжёлые запросы, рост числа пользователей.
- Довод для решения. «Перед половиной сбоев процессор базы был выше нормы за 4 часа» - понятный аргумент за оптимизацию или более мощный сервер.
- Проверка результата. Через месяц выгрузить данные снова и посмотреть, исчез ли подъём перед сбоями.
Красная линия - в какой доле сбоев процессор был выше обычного за столько часов до заявки; серая - то же в те же часы других дней. Где красная линия отрывается от серой, метрика предупреждает о сбое.
Как применять эти данные в работе
- ДежурстваСбой, о котором известно за несколько часов, - это плановая работа, а не ночной аврал. Смена успевает переключить нагрузку или перезапустить службу в спокойный момент.
- Мониторинг без шумаСтановится видно, какие метрики действительно предупреждают, а какие только будят дежурного. Тревоги на первые стоит усилить, на вторые - ослабить.
- Бюджет и SLAДовод «перед половиной сбоев база упиралась в процессор» понятен руководству без технических деталей. Предупреждённый сбой можно предотвратить, а значит, меньше простоя идёт в счёт обещанной клиентам доступности.