Отслеживание ошибок в реальных / производственных веб-приложениях - PullRequest
3 голосов
/ 25 октября 2008

В настоящее время я работаю в компании, которая имеет множество пользовательских приложений, которые создаются внутри компании. В настоящее время не существует стандартов для многих вещей. Я хотел бы реализовать способ записи / отслеживания ошибок, которые происходят в этих программах (большинство из них asp.net).

В настоящее время я думаю об обработке этого в Global.asax в методе ошибки приложения. Сначала попытайтесь сохранить информацию в базе данных «Журнал ошибок / отслеживание», а в случае сбоя попробуйте отправить электронное письмо.

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

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

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

Ответы [ 10 ]

3 голосов
/ 26 октября 2008

Я думаю ELMAH может быть то, что вы ищете.

2 голосов
/ 26 октября 2008

Если вы используете библиотеку журналов (например, Log4Net), вы можете настроить различные приложения журналирования для регистрации в электронной почте, в БД, в файл, в журнал событий и т. Д., Имея в своем коде один вызов журнала. Этот пост охватывает все, что вам нужно для начала.

Существует также Мониторинг состояния ASP.NET .

РЕДАКТИРОВАТЬ: еще один автор упоминал ELMAH, который отлично подходит для записи ошибок ASP.NET и может быть динамически «внедрен» в работающие приложения.

1 голос
/ 26 октября 2008

Будьте очень осторожны при регистрации потенциально конфиденциальной информации, которая поступила через https. Пользователь будет ожидать, что он будет полностью зашифрован (что может быть юридическим требованием). Убедитесь, что вы не отправляете его по электронной почте.

Обычно я бы сказал, регистрировать все запросы, включая get, post, cookies, состояние формы (в ASPNET), пользовательский агент, другие заголовки, дату / время, серверный компьютер и т. Д.

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

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

1 голос
/ 25 октября 2008

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

Я никогда ничего не храню в БД, потому что, если в БД есть ошибка, у меня никогда не будет этой ошибки в БД, по логике, вставка завершится неудачей!

Поэтому я отправляю письмо на специальный адрес электронной почты, например, bugs@mydomain.com

Тема : [Имя приложения] [Отметка времени: ddmmyyyy hhmmss] Сообщение : приложение, сообщение об ошибке, информация о трассировке стека, а также переменные сеанса, например имя пользователя, и переменные сервера, например, Referrer.

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

единственная проблема , которая у вас есть в этой системе, заключается в том, что вы ничего не получите, если у электронной почты есть проблема (за исключением некоторых случаев при отправке электронной почты), и для этого я начал добавлять к ежемесячному XML-файл [errorLog_ mmm_yyyy.xml] также создал простую страницу с перетаскиванием и сеткой, в которой загружался XML для месяца и года, в которые я хотел проверить ошибки.

try 
{
   // production code
}
catch(Exception ex)
{
   Utilities.Mail.SendError(ex);
}

или лучший способ: добавьте его в Application_Error в global.asax:

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<script language="C#" runat="server">
void Application_Error(object sender, EventArgs e)
{
   //get reference to the source of the exception chain
   Exception ex = Server.GetLastError().GetBaseException();

   //log the details of the exception and page state to the
   //Windows Event Log
   EventLog.WriteEntry("myWebApplication name",
     "MESSAGE: " + ex.Message + 
     "\nSOURCE: " + ex.Source +
     "\nFORM: " + Request.Form.ToString() + 
     "\nQUERYSTRING: " + Request.QueryString.ToString() +
     "\nTARGETSITE: " + ex.TargetSite +
     "\nSTACKTRACE: " + ex.StackTrace, 
     EventLogEntryType.Error);

   Utilities.Mail.SendError(ex);
}
</script>

с кодом выше вы добавляете ошибку в журнал событий, я добавляю ошибку в файл XML в функции SendError (Exception).

1 голос
/ 25 октября 2008

Джефф Этвуд написал отличный обработчик исключений, который вы должны посмотреть на CodeProject

Я бы попытался собрать как можно больше информации. Информация о стеке Информация о сеансе Расположение ошибки

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

0 голосов
/ 09 сентября 2009

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

0 голосов
/ 09 сентября 2009

Мы были разочарованы приложениями для отчетов об ошибках веб-сайтов, которые были там, поэтому мы написали свое собственное в Clearwind Consulting. Это бесплатно, и мы используем его для наших проектов. Он предоставляет полную информацию об ошибках, такую ​​как полные коды ошибок, тип браузера, трассировку, фрагмент кода, вызвавшего ошибку, частоту появления ошибок в течение 30 дней и более. В Clearwind мы занимаемся разработкой веб-приложений. Нам был нужен инструмент, который давал бы нам реальные данные, которые мы могли бы эффективно использовать о наших веб-сайтах.

Вы можете выбрать способ получения уведомления о том, когда ваш веб-сайт выдает ошибку. RSS, электронная почта или любой другой метод, который вам больше всего подходит, могут использоваться для получения уведомлений об ошибках. И да, вы можете отправлять ошибки на свой iPhone, пока вы пьете. Он полностью написан на Django, поэтому вы можете использовать JSON, RoR, XML, CSV и т. Д., Если хотите пометить или отформатировать данные. Или просто зайдите на сайт.

Если хотите, посмотрите на www.areciboapp.com.

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

0 голосов
/ 26 октября 2008

протоколирование это хорошо, но мониторинг приложений лучше.

предостережение: я являюсь автором CALM

0 голосов
/ 25 октября 2008

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

Отправка уведомлений об ошибках - хорошая идея, если вам нужен быстрый ответ. Но нет списка ошибок для их сканирования.

Я делаю это путем создания специального пользовательского класса исключений со свойствами, включая информацию о пользователе (идентификатор, имя, если доступно), все переменные сеанса, все переменные формы (чтобы вы могли видеть, как форма заполнялась и что пользователь вошел), и некоторые признаки за пределами стека отслеживают, где произошла ошибка (какая страница, какой класс, какой метод). Также укажите имя вызываемой хранимой процедуры и параметры отправки или сам SQL. Также все свойства исключения (трассировка стека и т. Д.). И поля DisplayMessage и InternalMessage. DisplayMessage отображается для пользователя. InternalMessage записывается в журнал и отображается в пользовательской странице ошибок в режиме отладки.

Я делаю вход в Page_Error на базовой странице и как отказоустойчивый в Application_Error.

Иногда я добавляю пару ключ-значение в web.config, чтобы содержать мой адрес электронной почты (или список рассылки). Если в этом ключе есть vaue, отправляется уведомление по электронной почте. Если нет значения, электронная почта не отправляется. Затем, во время тестирования или раннего производства, я могу сразу же получить личное уведомление о проблеме. По истечении начального периода я удаляю адрес электронной почты в web.config.

0 голосов
/ 25 октября 2008

Звучит так, как будто вы хорошо продумали решение.

Я работаю в магазине веб-разработок, поэтому помимо регистрации ошибок я также проверяю, что любые критические системные ошибки, такие как сбой запроса к БД и т. П., Также отправляются по электронной почте, чтобы мы могли сразу же их исправить и исправить.

Альтернативой для рассмотрения может быть отправка по электронной почте отчета каждый день, в котором содержится информация о каждой ошибке, выдаваемой в каждом приложении, и любая соответствующая информация, которую вы хотели бы получить по электронной почте.

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

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

...