Отслеживание ошибок в реальных/производственных веб-приложениях
https://stackoverflow.com/questions/236851
-
04-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
В настоящее время я работаю в компании, у которой есть много собственных приложений.В настоящее время для многих вещей нет стандартов.Я хотел бы реализовать способ записи/отслеживания ошибок, возникающих в этих программах (большинство из них — asp.net).
В настоящее время я думаю обработать это в Global.asax в методе ошибки приложения.Сначала попытайтесь сохранить информацию в базе данных журнала ошибок/отслеживания, а если это не удастся, попробуйте отправить электронное письмо.
Какой тип информации наиболее полезно получить из сообщения об ошибке и других переменных приложения (страница, имя пользователя и т. д.).
В настоящее время я подумываю об использовании двух таблиц: одну для получения общей информации об ошибках и приложениях, а вторую — для хранения информации об исключениях.Это будет отношение один ко многим для передачи внутренних исключений, которые могут возникнуть из одного исключения уровня приложения.
Я уверен, что мне не хватает многих деталей, и хотел бы услышать вашу стратегию решения этой проблемы.
Решение
Джефф Этвуд написал отличный обработчик исключений, который вы должны посмотреть на CodeProject
Я бы попытался собрать как можно больше информации. Информация о стеке Информация о сеансе Расположение ошибки
Я также настроил бы веб-службу, которую приложения вызывают, чтобы сохранить информацию об исключениях в вашей системе.
Другие советы
Я думаю, что ELMAH может быть тем, что вы ищете.
Если вы используете библиотеку журналов (например, Log4Net), вы можете настроить различные приложения ведения журналов для регистрации в электронной почте, в БД, в файл, в журнал событий и т. д., используя один вызов журнала в своем коде. В этой публикации рассказывается обо всем, что вам нужно, чтобы получить начало.
Существует также мониторинг состояния ASP.NET .
РЕДАКТИРОВАТЬ: на другом плакате упоминается ELMAH, который отлично подходит для записи ошибок ASP.NET и может динамически «впрыскиваться» в работающие приложения.
Это то, что я делаю, и у меня все еще есть ошибка из-за проблемы с электронной почтой.
Я никогда ничего не храню в БД, потому что, если в БД есть ошибка, у меня никогда не будет этой ошибки в БД, по логике, вставка завершится неудачей!
Поэтому я отправляю электронное письмо на специальный адрес электронной почты, такой как 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).
Будьте очень осторожны при регистрации потенциально конфиденциальной информации, которая поступила через https. Пользователь будет ожидать, что он будет полностью зашифрован (что может быть юридическим требованием). Убедитесь, что вы не отправляете его по электронной почте.
Обычно я бы сказал, регистрировать все запросы, включая get, post, cookies, состояние формы (в ASPNET), пользовательский агент, другие заголовки, дату / время, компьютер сервера и т. д.
НО в некоторых случаях это может привести к регистрации некоторой информации, которую вы не должны фиксировать (например, номера кредитных карт, передаваемых поставщику платежных услуг). Отправка по электронной почте еще хуже.
Стоит проверить, включен ли HTTPS, и, если это так, сократите объем регистрируемой информации, чтобы избежать этой проблемы. Я только что отправил через строку, чтобы сказать, было ли поле пустым или не пустым.
На самом деле это звучит так, как будто вы хорошо продумали решение.
Я работаю в магазине веб-разработок, поэтому, помимо регистрации ошибок, я также проверяю, что любые критические системные ошибки, такие как сбой запросов к БД и т. п., также отправляются по электронной почте, чтобы мы могли сразу же их исправить и исправить.
Альтернативой для рассмотрения может быть отправка отчета по электронной почте каждый день, в котором содержится информация о каждой ошибке, выдаваемой в каждом приложении, и любая соответствующая информация, которую вы хотели бы получить по электронной почте.
Мы регистрируем все наши ошибки в одной таблице для этого приложения (конечно, это проще сделать, когда вы работаете с приложениями, в которых все базы данных содержатся внутри компании), включая временную метку ошибки и полный текст сообщение об исключении, которое также было отправлено по электронной почте.
Сообщение об исключении содержит трассировку функции, поэтому вы знаете, какой была исходная вызывающая функция, а также номера файлов и строк для всех функций в стеке. Это делает обратное отслеживание любой данной ошибки очень простым.
При сбое входа в базу данных вы можете записать в журнал событий сервера или в файл Log.txt. Ваш выбор здесь частично зависит от того, есть ли у вас доступ к веб-серверам, содержащим их.
Отправка уведомлений об ошибках - хорошая идея, если вам нужен быстрый ответ. Но нет списка ошибок для их сканирования.
Я делаю это, создавая специальный пользовательский класс исключений со свойствами, включая информацию о пользователе (идентификатор, имя, если доступно), все переменные сеанса, все переменные формы (чтобы вы могли видеть, как форма заполнялась и какие пользователь вошел), и некоторые признаки за пределами стека отслеживают, где произошла ошибка (какая страница, какой класс, какой метод) Также укажите имя вызываемой хранимой процедуры и параметры отправки или сам SQL. Также все свойства исключения (трассировка стека и т. Д.). И поля DisplayMessage и InternalMessage. DisplayMessage отображается для пользователя. InternalMessage записывается в журнал и отображается на пользовательской странице ошибок в режиме отладки.
Я делаю вход в Page_Error на базовой странице и как отказоустойчивый в Application_Error.
Иногда я добавляю пару ключ-значение в web.config, чтобы содержать мой адрес электронной почты (или список рассылки). Если в этом ключе есть vaue, отправляется уведомление по электронной почте. Если нет значения, электронная почта не отправляется. Затем, во время тестирования или раннего производства, я могу сразу же получить личное уведомление о проблеме. По истечении начального периода я удаляю адрес электронной почты в web.config.
ведение журнала - это хорошо, но мониторинг приложений лучше.
Предупреждение: я являюсь автором CALM
Нас разочаровали существующие приложения для отчетов об ошибках на веб-сайтах, поэтому мы написали собственное в Clearwind Consulting.Это бесплатно, и мы используем его внутри своих проектов.Он предоставляет полную информацию об ошибках, такую как полные коды ошибок, тип браузера, обратная трассировка, фрагмент кода, вызвавшего ошибку, график частоты ошибок за 30 дней и многое другое.В Clearwind мы занимаемся разработкой веб-приложений.Нам нужен был инструмент, который давал бы нам реальные данные о наших веб-сайтах, которые мы могли бы эффективно использовать.
Вы можете выбрать, как получать уведомления об ошибках на вашем сайте.RSS, электронная почта или любой другой метод, который вам больше всего подходит, можно использовать для получения уведомлений об ошибках.И да, вы можете отправлять ошибки на свой iPhone, пока пьете.Он полностью написан на Django, поэтому вы можете использовать JSON, RoR, XML, CSV и т. д.если вы хотите пометить или отформатировать свои данные.Или просто зайдите на сайт.
Если хотите, загляните на www.areciboapp.com.
Он бесплатен, легко добавляется (или удаляется) на любой веб-сайт и предоставляет реальную информацию, позволяющую исправить ошибки, а не просто ошибку 404.Здесь нет навязчивых продаж.Просто приглашение прийти, посмотреть и посмотреть, может ли это помочь вам и вашему сайту.Мы думаем, что это возможно.
Очень хорошая идея - войти в пользовательский журнал событий на сервере, а также в любую другую систему регистрации и разработки. уведомление. Если ошибка была вызвана проблемой инфраструктуры, эта же проблема может также не позволить обработчику ошибок отправлять электронные письма или сохранять их в базе данных.
