Отслеживание веб-службы, размещенной по адресу http

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

Я могу придумать три варианта:

1. Попросите родственника позвонить вам, когда ему понадобится помощь. Например, если они падают и не могут встать.
2. Попросите родственника звонить вам каждый день в определенное время, скажем, в 19:00. Если вы не получите от них известий к 19:30, вы бы обострили ситуацию, попытавшись позвонить им или попросив кого-нибудь поблизости остановиться и проверить их.
3. Звоните им регулярно, скажем, раз в день, и проверяйте, все ли в порядке.

Варианты 2 и 3 являются вариантами опроса. Единственная разница в том, кто инициирует запрос; но любой вариант подойдет. Вариант 1 - уведомление, управляемое событиями. Это наиболее эффективный вид уведомления, потому что родственник получит немедленную помощь. Но если они сильно упали и потеряли сознание, они не смогут поднять тревогу, и могут пройти дни, прежде чем кто-нибудь заметит.

Исходя из этого, я считаю лучший выбор - использовать уведомление, управляемое событиями, где это возможно, но использовать какую-либо форму опроса в качестве надежного отката. Какой бы метод опроса ни использовался, он должен быть очевиден, когда сам механизм опроса дает сбой. Было бы плохо, если бы система, которую вы используете для опроса веб-службы, перестала бы работать, а вы этого не осознали.

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

Мы решили написать собственное решение для мониторинга, которое опрашивает все критически важные службы каждые несколько секунд. Если в течение ожидаемого периода ожидания ответа не поступает или он приходит, но не соответствует ожиданиям, система предупреждает одного из наших сотрудников. Система отправит электронные письма ключевому персоналу, а также сообщает о текущем состоянии всех систем через свой "информационный радиатор"/"большая видимая диаграмма"тип отображения.

Вот один из информационных излучателей, которые есть в нашем офисе, который всегда обеспечивает индикатор доступности и производительности наших критически важных услуг:

Дисплей расположен на видном месте в нашем офисе, чтобы мы знали, не отслеживает ли он.

В прошлом месяце мы выпустили систему под названием ServiceMon, как открытый исходный код под лицензией GPL.

ServiceMon настраивается с помощью очень простого скрипта. Вот пример того, как вы будете отслеживать веб-страницу:

http-get "http://www.google.com" must-contain "<title>Google</title>"

Вы также можете использовать этот подход для мониторинга служб на основе REST без сохранения состояния. Есть пример Вот

Если вам нужно отслеживать веб-службу на основе SOAP, вам необходимо создать простой плагин. Эта статья Я написал для CodeProject, что ближе к концу есть раздел, объясняющий, в чем дело.

В идеале ваша система будет спроектирована с нуля с учетом мониторинга и, мы надеемся, будет предоставлять информацию о состоянии и диагностику с помощью методов, контролируемых безопасностью (которые, возможно, потребуется ограничить для внутреннего использования).

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

Для получения дополнительной информации о ServiceMon посетите домашняя страница проекта