Держим руку на пульсе

Задача

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

PHP: 4.3.0
libGD: OK
MySQL: OK
Disk: OK
Recent order: OK

Все показатели, которые здесь в состоянии OK - такими (по нашему дизайну) и должны быть в обычной работе. А если диагностическая страничка показывает ошибку - это причина для того, чтобы искать проблему.

okerr имеет несколько разных методов проверки, работающих через http(s) протоколы. С одним из них (HTTP SHA1 hash dynamic) мы познакомились выше. В принципе, он подходит и тут - он способен сообщить нам об изменении на странце. Но это не очень удобно, мы только видим, что хеш изменился с одного "непонятного" значения, на другое. Было бы удобнее, если бы okerr умел каким-то образом сам определять, какое состояние страницы "правильное", а какое говорит об ошибке.

Решение

Есть два варианта решения проблемы. Первый - использовать статичный метод. Создадим индикатор "test:second", укажем метод проверки "HTTP SHA1 hash static", и так же, как в предыдущей задаче, указываем в поле URL адрес диагностической страницы. Перепроверим, и пустое поле hash установится в sha1 хеш страницы. Теперь, это значение считается эталонным, статус индикатора - 'OK', а любое изменение страницы изменит статус на ERR.

Если перепроверить без изменения страницы - состояние индикатора не изменится (поскольку диагностическая страница имеет точно то же содержание). А если мы изменим содержание диагностической страницы, например, укажем "MySQL: ERROR", то следующая проверка, обнаружит изменение, и (поскольку мы используем статичный метод) - эталонное значение hash НЕ изменится (статичные методы не изменяют значения аргументов), а вместо этого статус индикатора изменится на ERR (ошибка), и будет отправлено оповещение на почту.

Индикатор вернется в состояние OK в одном из двух случаев - либо наблюдаемая страница изменит содержание на эталонное, хеш которой записан в аргументах, либо если вручную стереть значение поля hash, и тогда при следующей проверке okerr установит новое значение, которое будет эталоном для следующих проверок.

Второй вариант решения - через метод проверки "HTTP grep". Изменим тип проверки на HTTP grep, снова укажем URL, а в поле mustnothave укажем подстроку, которая в нормальной ситуации не должна встретиться на странице, например, по-умолчанию это будет строчка 'Error'. Теперь, если на странице появится это слово - индикатор изменит состояние на ERR, и будет выслано оповещение. Так же, метод позволяет проверять обязательное наличие подстроки (аргумент musthave). Например, указав там "Disk: OK" индикатор будет принимать состояние ошибки, если этой подстроки не будет (например, будет "Disk: Error" или "Disk: к сожалению, у нас опять что-то сломалось" или вообще совсем не будет строчки про Disk)

Все три описаных метода (HTTP grep и HTTP SHA1 hash static/dynamic) выставляют ошибку, если HTTP запрос завершился неудачно (невозможно получить ответ от сервера или HTTP код ответа любой кроме 200, например 404 - нет такой страницы)

Маленькая хитрость: Использование подобных диагностических страниц, которые проверяются одним индикатором но сами выполняют много других проверок - снижает нагрузку на okerr и позволяет не превышать ограниченное количество индикаторов в проекте.