Что на самом деле должен измерять health score сервера

Любой продукт мониторинга рано или поздно выпускает health score, и большинство из них бесполезны по одной причине: они усредняют то, что усреднять нельзя. Хост с диском на 99% и CPU на 5% не «здоров на 52%». Он вот-вот ляжет.

Score - инструмент сортировки, а не сигнализация

Ошибка - считать score триггером. Если по score вызывают дежурного, он обязан быть точным, а одно число не может быть точным про сотню разных видов отказа. Поэтому мы дали ему более узкую задачу: решать, на какой хост смотреть первым. Оповещения по-прежнему срабатывают по конкретным условиям с конкретными порогами. Score только ранжирует.

Такая переформулировка делает задачу решаемой. Функции ранжирования не нужно быть правой насчёт тяжести; ей нужно быть монотонной - хуже должно всегда сортироваться выше.

Худшее, а не среднее

Главное правило: нагрузка на ресурсы входит в score по худшему измерению, а не по среднему. Хост, у которого три оси в порядке, а четвёртая критична, - это хост в беде, и score обязан это сказать. Именно усреднение позволяет забитому диску спрятаться за простаивающим процессором.

Поверх этой базы мы вычитаем за вещи, которые категорически плохи, а не непрерывны:

• упавшие юниты systemd или остановленные службы Windows;
• требуемая перезагрузка, которой не произошло;
• предотказные признаки SMART или деградировавший RAID-массив;
• неуспешные проверки доступности и TLS-сертификаты на исходе срока;
• активный подбор пароля по SSH или RDP.

Стабильность важнее разрешения

Score, дёргающийся на каждом такте, - это шум на настенном экране, и люди перестают на него смотреть. Наш намеренно грубый и с гистерезисом: он двигается ступенями, и чтобы его сдвинуть, нужно устойчивое изменение. Если вы смотрите на число, а не на график, оно должно что-то значить, когда меняется.

Как устроена сторона оповещений - в статье правила оповещений, которые не кричат «волки».