实时/生产 Web 应用程序中的错误跟踪
我目前在一家公司工作,该公司有很多内部制作的自定义应用程序。 目前很多事情都没有标准。 我想实现一种方法来记录/跟踪该程序中发生的错误(大多数是asp.net)。
我目前正在考虑在 Global.asax 的应用程序错误方法中处理这个问题。 首先尝试将信息保存到错误日志/跟踪数据库,如果失败,请尝试发送电子邮件。
从错误消息和其他应用程序变量(页面、用户名等)中获取什么类型的信息最有用。
我目前正在考虑使用两个表,一个用于获取一般错误和应用程序信息,另一个用于保存异常信息。 这将是一种一对多的关系,用于处理可能来自一个应用程序级别异常的内部异常。
我确信我遗漏了很多细节,并且想听听您处理此问题的策略。
I currently work at a company that has a lot of custom applications that are made internally. There are not currently standards for a lot of things. I would like to implement a way to record/track errors that happen in this programs (most are asp.net).
I am currently thinking of handling this in the Global.asax in the Application Error method. First trying to save the information to an Error Log/Tracking database, and if that fails, try sending an e-mail.
What type of information is the most useful to get from the error message and other application variables (page, username etc).
I am currently thinking of using two tables, one to get the general error and application information, and a second that holds the exception information. This will be a one to many relationship to hand the inner Exceptions that can come from one Application level exception.
I am sure that I am missing a lot of details and would like to hear your strategy for handling this issue.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(10)
如果您使用日志库(如 Log4Net),您可以设置各种日志附加程序来记录到电子邮件、数据库、文件、事件日志等,同时在代码中进行单个日志调用。 这篇帖子涵盖了您需要获得的所有内容开始了。
还有 ASP.NET 运行状况监控。
编辑:另一张海报提到了 ELMAH,它非常适合记录 ASP.NET 错误,并且可以动态“注入”到正在运行的应用程序中。
If you use a logging library (like Log4Net) you can set up various logging appenders to log to email, DB, file, event log, etc while having a single log call in your code. This post covers everything you need to get started.
There's also ASP.NET health monitoring.
EDIT: another poster mentioned ELMAH, which is great for recording ASP.NET errors, and can be dynamically 'injected' into running apps.
Jeff Atwood 写了一个很棒的异常处理程序,您应该在 CodeProject 上查看,
我会尝试收集尽可能多的信息。
堆栈信息
会议信息
错误位置
我还会设置一个 Web 服务,应用程序调用该服务将异常信息保存到您的系统中。
Jeff Atwood wrote a great Exception Handler that you should look at on CodeProject
I would attempt to collect as much information as possible.
Stack Information
Session Information
Location of Error
I would also setup a webservice that the applications call to save off the exception information into your system.
这就是我所做的,但由于电子邮件问题,我仍然遇到了错误。
我从不在数据库上保留任何内容,因为如果数据库有错误,我将永远不会在数据库上出现该错误,从逻辑上讲,插入将会失败!
因此,我会向一个特殊的电子邮件地址发送电子邮件,例如 [email protected]
主题:[应用程序名称] [时间戳:ddmmyyyy hhmmss]
消息:应用程序、错误消息、堆栈跟踪信息以及会话变量(例如用户名)和服务器变量(例如引用者)。
ASP.NET 开发人员最好的朋友是堆栈跟踪信息,在这里您将知道出了什么问题、调用了什么以及调用的位置。
唯一的问题,你在这个系统中,是如果电子邮件有问题,你将不会得到任何东西(发送电子邮件时有一些例外),为此我开始添加到每月的 XML 文件[errorLog_ mmm_yyyy.xml] 也制作了一个简单的“拖放”页面,其中包含一个 gridview,该页面加载了我想要检查错误的月份和年份的 XML。
或者最好的方法:将其添加到 global.asax 中的 Application_Error 中:
使用上面的代码将错误添加到事件日志中,我将错误附加到 SendError(Exception) 函数中的 XML 文件中。
This is what I do, and I still got a bug because of an email problem.
I never keep anything on the DB, cause if the DB has an error I will never have that error on the DB cause, logically, the insert will fail!
So I email to a special email address like [email protected]
Subject: [Application name] [Time Stamp: ddmmyyyy hhmmss]
Message: Application, Error Message, Stack Trace Information plus session variables like username and server variables like Referrer.
the best friend of an ASP.NET developer is the stack trace information, it is here that you will know what went wrong, what was the call and where it was calling.
the only problem that you have in this system, is that you will not get anything if the email has a problem (some exception when sending the email), and for that I started add to a monthly XML file [errorLog_ mmm_yyyy.xml] as well and made a simple "drag-and-drop" page with a gridview that loaded the XML for the month and year that I wanted to check the errors.
or the best way: Add it to the Application_Error in global.asax:
with the code above you add the error to the event log, I append the error to the XML file in the SendError(Exception) function.
记录通过 https 到达的潜在机密信息时要非常小心。 用户希望它被端到端加密(这可能是法律要求)。 确保您不通过普通电子邮件发送。
通常我会说记录所有请求,包括 get、post、cookie、表单状态(在 ASPNET 中)、用户代理、其他标头、日期/时间、服务器计算机等,
但在某些情况下,这会导致记录一些信息您不应该永久记录(例如传递给支付提供商的信用卡号码)。 通过电子邮件发送的情况更糟。
值得检查一下 HTTPS 是否已打开,如果是,请减少记录的信息量以避免此问题。 我只是发送了一个字符串来说明该字段是空还是非空。
Be very careful when logging potentially confidential information which has arrived over https. The user will expect it to be encrypted end-to-end (which may be a legal requirement). Ensure you don't send it via plain email.
Normally I'd say log all of the request including get, post, cookies, form state (in ASPNET), user agent, other headers, date/time, server machine etc
BUT under some cases that would result in some information being logged which you're not supposed to permanently record (such as credit card numbers being passed through to a payment provider). Sending it by email is even worse.
It's worth doing a check if HTTPS is on, and if so, reduce the amount of information you log to avoid this problem. I just sent through a string to say whether the field was empty or non-empty.
实际上听起来您已经很好地考虑了解决方案。
我在网络开发商店工作,因此除了记录错误之外,我还确保通过电子邮件发送任何系统关键错误(例如数据库查询失败等),以便我们可以立即解决它们并修复它们。
可以考虑的另一种选择是每天通过电子邮件发送一份报告,其中提供每个应用程序中抛出的每个错误的信息以及您希望在电子邮件中包含的任何相关信息。
我们将所有错误记录到该应用程序的单个表中(当然,当您处理数据库全部包含在内部的应用程序时,这更容易做到),包括错误的时间戳和异常消息的全文也已通过电子邮件发送。
异常消息包含函数跟踪,以便您知道原始调用函数是什么以及堆栈中所有函数的文件号和行号。 这使得回溯任何给定的错误变得非常简单。
It actually sounds like you've thought out the solution pretty well.
I work in web development shop, so in addition to logging errors, I also make sure that any system critical errors such as failing db query's and the like are also emailed so that we can jump on them and fix them right away.
An alternative to consider would be to email a report each day that provides information on each error thrown in each application and any relevant information that you would want in the email.
We log all of our errors into a single table for that application (of course that's easier to do when your working on applications where the databases are all contained in-house) including the timestamp of the error and the full text of the exception message that has also been emailed.
The exception message contains a function trace so you know what the original calling function was as well as file and line numbers for all functions in the stack. This makes back-tracking any given bug super simple.
当记录到数据库失败时,您可以写入服务器的事件日志或 Log.txt 文件。 您在这里的选择部分取决于您是否有权访问包含这些内容的网络服务器。
如果您需要快速响应,发送错误通知电子邮件是个好主意。 但没有错误列表可供扫描。
为此,我创建一个特殊的自定义异常类,其属性包括用户信息(ID、名称,如果可用)、所有会话变量、所有表单变量(这样您就可以看到表单的填充方式以及用户输入的内容) ,以及超出堆栈跟踪的一些指示,表明错误发生的位置(哪个页面、哪个类、哪个方法)。 还包括调用的存储过程的名称和发送的参数,或 SQL 本身。 还有所有异常属性(堆栈跟踪等)。 还有 DisplayMessage 和 InternalMessage 字段。 DisplayMessage 显示给用户。 InternalMessage 记录在日志中,并在调试模式下显示在自定义错误页面上。
我在基页上的 Page_Error 中进行日志记录,并在 Application_Error 中作为故障安全。
有时我会在 web.config 中添加一个键值对来包含我的电子邮件地址(或通讯组列表)。 如果该键中有值,则会发送通知电子邮件。 如果没有值,则不会发送电子邮件。 然后,在测试或早期生产过程中,我可以立即收到有关问题的个人通知。 初始阶段过去后,我删除了 web.config 中的电子邮件地址。
When logging to the database fails, you could write to the server's Event Log, or to a Log.txt file. You choice here partly depends upon whether you have access to the web servers containing those.
Sending error notification emails is a good idea if you need a speedy response. But there's no list of the errors to scan through them.
I do this by creating a special custom exception class with properties including user information (ID, name if available), all of the session variables, all of the form variables (so you can see how the form was populated and what the user entered), and some indication beyond the stack trace of where the error occurred (which page, which class, which method). Also include the name of the stored procedure called and the parameters send, or the SQL itself. Also all of the Exception properties (stack trace, etc). And DisplayMessage and InternalMessage fields. The DisplayMessage is displayed to the user. The InternalMessage is recorded in the log, and displayed on the custom error page when in debug mode.
I do the logging in Page_Error on the base page, and as a fail-safe in Application_Error.
Sometimes I add a key-value pair in web.config to contain my email address (or a distribution list). If there is a vaue in that key, a notification email gets sent. If there's no value, no eomail is sent. Then, during testing or early production, I can get immediate personal notification of the problem. After the initial period passes, I remove the email address in web.config.
日志记录很好,但应用程序监控更好。
警告:我是 CALM 的作者
logging is good, but application monitoring is better.
caveat: i am the author of CALM
我们对现有的网站错误报告应用程序感到沮丧,因此我们在 Clearwind Consulting 编写了自己的应用程序。 它是免费的,我们在内部项目中使用它。 它提供了完整的错误信息,例如完整的错误代码、浏览器类型、回溯、导致错误的代码片段、30 天内绘制的错误频率等。 在 Clearwind,我们从事网络应用程序开发。 我们需要一个工具来为我们提供可以有效使用我们网站的真实数据。
您可以选择如何在您的网站出现错误时收到通知。 RSS、电子邮件或任何最适合您的方法都可以用于获取错误通知。 是的,您可以在喝酒时将错误发送到您的 iPhone。 它完全用 Django 编写,因此如果您想要标记或格式化数据,您可以使用 JSON、RoR、XML、CSV 等。 或者直接访问网站。
如果您愿意,请访问 www.areciboapp.com。
它是免费的,可以轻松地添加到任何网站(或从中删除),并提供真实的信息,使您能够修复错误,而不仅仅是 404。这里没有强行推销。 只是邀请您来看一下,看看它是否对您和您的网站有帮助。 我们认为有可能。
We were frustrated with the website error reporting applications that were out there so we wrote our own at Clearwind Consulting. It's free and we use it internally for our projects. It gives complete error information such as full error codes, browser type, traceback, a snippet of the code that caused the error, error frequency graphed over 30 days and more. At Clearwind, we do web application development. We needed a tool that would give us real data we could efficiently use about our websites.
You can choose how to get notification of when your website gives an error. RSS, email, or whatever method works best for you can all be used to get error notifications. And yes, you can send the errors to your iPhone while you're having a drink. It is fully written in Django so you can use JSON, RoR, XML, CSV, etc. if you desire to tag or format your data. Or just come to the website.
If you like, look at www.areciboapp.com.
It's free, easily added to (or removed from) any website and gives real information to enable you to fix the errors, rather than just a 404. No hard sell here. Just an invite to come take a look and see if it might help you and your website. We think it might.
记录到服务器上的自定义事件日志以及任何其他日志记录是一个非常好的主意。 通知。 如果错误是由基础设施问题引起的,则同样的问题也可能导致错误处理程序无法发送电子邮件或保存到数据库。
It's a pretty good idea to log to a custom event log on the server as well as any other logging & notification. If the error was caused by an infrastructure issue, the same problem might also keep the error handler from sending emails or saving to a database.
我认为 ELMAH 可能就是您要找的。
I think ELMAH may be what you're looking for.