Как бы я создал приложение, которое может диагностировать себя во время выполнения?

Question

У меня есть приложение, которое использует различные внешние ресурсы (веб-сервисы, файловая система, база данных), и поэтому может быть довольно сложно настроить. Планируется добавить в приложение инструмент самодиагностики, чтобы он мог сообщать о проблемах с конфигурацией и позволять пользователю ее исправлять. Существуют ли какие-либо шаблоны проектирования, библиотеки, примеры и т. Д., Которые следует учитывать при разработке такой функции?

Приложение написано на C # и ASP.NET.

Answer 1

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

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

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

Answer 2

Если они могут видеть вас, вы можете видеть их

Добавьте слой к вашим (внешним) приложениям, который отправляет асинхронные "пинги" в той или иной форме. Может быть инструментом промежуточного программного обеспечения для обмена сообщениями.

Если у вас нет контроля над внешними системами, возможно, добавьте приложение sep-A-RAT-e "фасад", которое выполняет диагностику (например, вызывает http-соединение с таймаутом), а затем отправляет эхо-запросы на имя внешнего приложения.

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

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

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

Answer 3

Если вы просто имеете в виду статическую конфигурацию,

добавить доступный клиенту модульный тест, который выполняет все системные интерфейсы. У вас уже есть один, верно?

Назовите это «проверить конфигурацию». или что-то.

Надеюсь, это поможет.

Answer 4

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