Тонкость клиентского мониторинга в том, что клиент может сам заметить, что в системе что-то пошло не так. И сделать это раньше тебя. И даже раньше определить место поломки. А нафига тогда ему нужен ты?
Поэтому появилась мысль сделать так: при малейших признаках нестандартной работы системы или ее компонента(аномальное значение нагрузки, например или резкий скачок потребления оперативной памяти) должен сразу подниматься триггер средней важности с бодрящим пинком админам.
То есть у системы еще вагон памяти, скакнувшая нагрузка и до 50% не дотянулась, а все уже насторожились и начали разбираться. Потому что, пусть это и не критическое поведение системы, но уж точно ненормальное. И лучше узнать, что происходит прямо сейчас, пока есть пространство для маневра и опеределенное время на предотвращение критической ситуации.
Если же все бездействуют, не успевают вмешаться или авария развивается слишком быстро, то проверяемый параметр достигает критического значения и зажигается высокий или чрезвычайный триггер с отправкой уведомления клиенту. Это наша красная карточка – в этот момент мы уже проиграли схватку с внештатной ситуацией, потому что она начинает оказывать влияние на клиентский бизнес. То есть надо срочно все бросать и решать проблему. Из этого, кстати, вытекает и критерий для высокого уровня триггера – если значение наблюдаемого параметра оказывает влияние на работу клиентских систем, значит, оно должно быть высокого уровня или выше.
