Consider what industry the software targets. Gathering any information about the user (even active directory name) or the network can get your app blackballed and potentially carries liability. i.e. What if your bug database is compromised and that information is used to break into a bank's or a government laboratories network. Will the bug report containing their IP's be noticed? Can you be sued? Maybe...
For instance, if you need to gather network specific data to diagnose network issues, consider having your app replace any system names or IP's with placeholders before data gets send back to you. (emailSrvr1, bankAcctNumSrv, becomes srvr1 and srvr2) It's a bigger pain in tracking down issues, but may be worth it. This still captures info that may get you in trouble, but may help.
I've been working with high end enterprise and Government for a few years which colors my perspective, but it's probably worth considering what you are collecting and how it is being stored.
Clrdump 主要是 Microsoft 的 DbgHelp.dll 的包装。您可以直minidump”，它将与应用程序的虚拟地址空间一样大，该空间可能非常大。 Clrdump 做得很好，它创建了一个小型转储，其中仅包含堆栈跟踪以及 SOS 能够读取它们的足够信息。
(This is somewhat Windows / .NET specific, but that is what you specified in the question, and I think this is quite useful info in that context.)
Unless your application is strictly single-threaded, you want a dump file (which will give you the stack for all threads, at a minimum), not just a stack trace for the thread throwing the exception.
Generating a dump that is not too big and that has enough information to give you useful managed stack traces is a bit tricky, but there is a very useful utility called clrdump that will handle some of the gorier details for you.
Clrdump is mostly a wrapper for Microsoft's DbgHelp.dll. You can use DbgHelp directly - see this question - but then you will get a "full minidump" which will be as big as the virtual address space of your application, which can be pretty large. Clrdump does a nice job of creating a small dump with just the stack traces plus enough info for SOS to be able to read them.
LA Transtar 还保留一个仅在发生故障时保存的关键日志。该日志包含程序运行时的输入和跟踪。日志在每个新事务开始时重置。
LA Transtar also keeps a key log that is saved only for failures. This log contains the input and a trace of the program as it is proceeding. The log is reset at the start of each new transaction.
您没有提到进程日志记录（例如 Linux 中的 syslog、Windows 中的事件查看器？）。由于我也有系统管理背景，所以我非常喜欢带有日志记录功能的程序。如果可以选择详细级别就更好了。
更多地了解环境对您有好处，如果您的用户必须与其他工具进行某种类型的集成工作，这对您的用户也有好处。
如果您的用户更懂技术，您可以要求他们将日志记录详细程度设置为最大并再次重现错误。
You do not mention about process logging (like syslog in Linux, Event Viewer for windows?). Since I also have a sys admin background I truly appreciate programs with a logging facility. Even better if the verbosity level can be selected.
It is good for you to know more about the environment, and it is good for your users if they have to do some type of integration work with other tools.
If your users are more technical, you can ask them to set the logging verbosity to the maximum and reproduce the error again.
Basically, there is no Golden rule that you have to follow and implement it in every application. Depending on your business application and scenario, different things are the most appropriate to be included for information collection when an error occurs.
The ones you mentioned are OK, but here's a bit more that is good to be logged :
input parameters for critical and complex operations
context of your program - some objects with heavy algorithms - the most risk-possessing classes
the state in which is your program
example : the flow of your program is like a state automata and you have 5 states and you have reached state 3.
if you have an application which is server-client , collect both logs - from provider and consumption side
memory dump is not generally a good suggestion - do it only when you need to understand problems in frameworks or JVM(for example) that you have no control of. OutOfMemoryError for example
I don't see in your list the most important information (when we talking about dotnet/java level of code).
The exception type,message and trace.
You can use simple code, to catch any exception, and "write to log"/"send directly to the email".
发布评论
评论（6）
现在来自偏执狂阵营:(
考虑软件的目标行业。收集有关用户的任何信息（甚至活动目录名称）或网络可能会使您的应用程序被列入黑名单，并可能承担责任。即，如果您的错误数据库受到损害怎么办？信息用于闯入银行或政府实验室网络。包含其 IP 的错误报告会被注意到吗？也许……
例如，如果您需要收集特定于网络的数据来诊断网络问题，请考虑让您的应用程序在数据发送回您之前用占位符替换任何系统名称或 IP（emailSrvr1、bankAcctNumSrv 变为 srvr1 和 srvr2），这在跟踪问题方面会比较困难，但可能还是值得的。给你带来麻烦，但可能会有所帮助。
我已经与高端企业和政府合作了几年，这影响了我的观点，但可能值得考虑你正在收集什么以及如何存储它。
And now from the paranoia camp :(
Consider what industry the software targets. Gathering any information about the user (even active directory name) or the network can get your app blackballed and potentially carries liability. i.e. What if your bug database is compromised and that information is used to break into a bank's or a government laboratories network. Will the bug report containing their IP's be noticed? Can you be sued? Maybe...
For instance, if you need to gather network specific data to diagnose network issues, consider having your app replace any system names or IP's with placeholders before data gets send back to you. (emailSrvr1, bankAcctNumSrv, becomes srvr1 and srvr2) It's a bigger pain in tracking down issues, but may be worth it. This still captures info that may get you in trouble, but may help.
I've been working with high end enterprise and Government for a few years which colors my perspective, but it's probably worth considering what you are collecting and how it is being stored.
（这在某种程度上是 Windows / .NET 特定的，但这就是您在问题中指定的内容，我认为这在该上下文中是非常有用的信息。）
除非您的应用程序是严格单线程的，否则您需要一个转储文件（它将至少为您提供所有线程的堆栈，而不仅仅是抛出异常的线程的堆栈跟踪。
生成一个不太大并且有足够信息来为您提供有用的托管堆栈跟踪的转储有点棘手，但是有一个非常有用的实用程序，称为 clrdump 将为您处理一些更详细的细节。
Clrdump 主要是 Microsoft 的 DbgHelp.dll 的包装。您可以直minidump”，它将与应用程序的虚拟地址空间一样大，该空间可能非常大。 Clrdump 做得很好，它创建了一个小型转储，其中仅包含堆栈跟踪以及 SOS 能够读取它们的足够信息。
(This is somewhat Windows / .NET specific, but that is what you specified in the question, and I think this is quite useful info in that context.)
Unless your application is strictly single-threaded, you want a dump file (which will give you the stack for all threads, at a minimum), not just a stack trace for the thread throwing the exception.
Generating a dump that is not too big and that has enough information to give you useful managed stack traces is a bit tricky, but there is a very useful utility called clrdump that will handle some of the gorier details for you.
Clrdump is mostly a wrapper for Microsoft's DbgHelp.dll. You can use DbgHelp directly - see this question - but then you will get a "full minidump" which will be as big as the virtual address space of your application, which can be pretty large. Clrdump does a nice job of creating a small dump with just the stack traces plus enough info for SOS to be able to read them.
LA Transtar 还保留一个仅在发生故障时保存的关键日志。该日志包含程序运行时的输入和跟踪。日志在每个新事务开始时重置。
LA Transtar also keeps a key log that is saved only for failures. This log contains the input and a trace of the program as it is proceeding. The log is reset at the start of each new transaction.
您没有提到进程日志记录（例如 Linux 中的 syslog、Windows 中的事件查看器？）。由于我也有系统管理背景，所以我非常喜欢带有日志记录功能的程序。如果可以选择详细级别就更好了。
更多地了解环境对您有好处，如果您的用户必须与其他工具进行某种类型的集成工作，这对您的用户也有好处。
如果您的用户更懂技术，您可以要求他们将日志记录详细程度设置为最大并再次重现错误。
You do not mention about process logging (like syslog in Linux, Event Viewer for windows?). Since I also have a sys admin background I truly appreciate programs with a logging facility. Even better if the verbosity level can be selected.
It is good for you to know more about the environment, and it is good for your users if they have to do some type of integration work with other tools.
If your users are more technical, you can ask them to set the logging verbosity to the maximum and reproduce the error again.
基本上，不存在您必须在每个应用程序中遵循和实施的黄金法则。根据您的业务应用程序和场景，发生错误时最适合包含不同的信息收集内容。
您提到的那些都可以，但这里还有一些值得记录的内容：
示例：您的程序流程就像一个状态自动机，您有 5 个状态，并且已达到状态 3。
如果您有一个服务器-客户端应用程序，请从提供者和消费端收集日志
内存转储通常不是一个好的建议 - 仅当您需要了解框架或 JVM 中的问题时才这样做（例如）你无法控制的。例如 OutOfMemoryError
Basically, there is no Golden rule that you have to follow and implement it in every application. Depending on your business application and scenario, different things are the most appropriate to be included for information collection when an error occurs.
The ones you mentioned are OK, but here's a bit more that is good to be logged :
example : the flow of your program is like a state automata and you have 5 states and you have reached state 3.
if you have an application which is server-client , collect both logs - from provider and consumption side
memory dump is not generally a good suggestion - do it only when you need to understand problems in frameworks or JVM(for example) that you have no control of. OutOfMemoryError for example
我在您的列表中没有看到最重要的信息（当我们谈论 dotnet/java 级别的代码时）。
异常类型、消息和跟踪。
您可以使用简单的代码来捕获任何异常，并“写入日志”/“直接发送到电子邮件”。
I don't see in your list the most important information (when we talking about dotnet/java level of code).
The exception type,message and trace.
You can use simple code, to catch any exception, and "write to log"/"send directly to the email".