Что такое мониторинг?

Такой кажущийся очевидным вопрос, любой специалист тут же готов на него ответить. Но, что характерно, отвечают все по-разному. Для кого-то это некая "система", продукт конкретного вендора: prometheus, zabbix или что-то из этого ряда. Для кого-то это система графиков и оповещений, отражающая состояние дел в вашей инфраструктуре. Для кого-то некий "черный ящик" с которым "возятся девопсы"

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

а) упредить аварию
б) получить нормальные уведомления об аварии, если она произошла
и) иметь актуальные данные о состоянии нашей системы

Система мониторинга также имеет такие характеристики как чувствительность, уровень шума и процент покрытия.

Разберемся подробнее
Анализируя данные, поставляемые мониторингом, мы можем понять, что что-то пошло не так, еще до того, как наблюдаемый узел начнет выходить из строя и среагировать до того, как произойдет отказ в обслуживании. Например, если некий сервер всегда потреблял 10% CPU, а сейчас вдруг начал потреблять 80%, то что-то, скорее всего, идет не так и когда уровень потребления дойдет до ста, то что-то упадет. Мы можем повесить алерт на критичный уровень и среагировать раньше.

Но что если это запустился некий контролируемый процесс (например после очередного релиза или начался пик трафика, в общем ситуация является нормальной и контролируемой)? Тогда мы все равно получим алерт, потратим время дежурного инженера на выяснение обстоятельств и, что самое неприятное, мы будем вынуждены либо отключить алерт, либо оставить его гореть. Обе эти ситуации довольно неприятные, так как искажают общую картину. В первом случае мы не получим уведомления, когда алерт сигнализирует о действительной проблеме, во втором случае мы получим "слепоту на алерты", когда просто перестанем обращать на него внимание. Нужно вводить метрику, растянутую по времени. То есть не "CPU > 80% тогда алерт", а "CPU > 80% в течении какого-то времени, тогда алерт". Но в этом случае мы должны знать об предстоящих пиках трафика или нагрузках на процессор. А вдруг паттерн аварии совпадет с нашими ожиданиями и алерта не будет? Надо вводить дополнительные условия: если CPU > 80% и растет, а расти началó с 50% и растет быстрее, чем мы ожидаем, например на 2% в минуту. Программирование на конфигах получим в итоге, ну а что делать?

Ну так в итоге, как поступать-то? В первую очередь надо понимать, что мониторинг нельзя настроить и забыть, за ним надо постоянно следить. И тогда и он будет постоянно следить за вашей системой. Во-вторых перед тем, как настраивать алерты, надо ответить себе на вопросы: что мы мониторим, зачем мы это мониторим и какое поведение является ненормальным для той сущности, которую мы мониторим. Чем больше ненормальных состояний вы опишите, тем легче будет настроить алерты.

Продолжение следует
(Впереди будет серия постов про #мониторинг)