记录最佳实践 [英] Logging best practices

问题描述

我想了解人们如何处理实际应用程序中的跟踪和日志记录.以下是一些可能有助于解释您的答案的问题.

I'd like to get stories on how people are handling tracing and logging in real applications. Here are some questions that might help to explain your answer.

框架

你使用什么框架?

• log4net
• System.Diagnostics.Trace
• System.Diagnostics.TraceSource
• 记录应用程序块
• 其他?

如果使用跟踪，是否使用 Trace.Correlation.StartLogicalOperation?

If you use tracing, do you make use of Trace.Correlation.StartLogicalOperation?

您是手动编写此代码，还是使用某种形式的面向方面的编程来编写此代码?愿意分享代码片段吗?

Do you write this code manually, or do you use some form of aspect oriented programming to do it? Care to share a code snippet?

您是否对跟踪源提供任何形式的粒度?例如，WPF TraceSources 允许您在不同级别配置它们:

Do you provide any form of granularity over trace sources? E.g., WPF TraceSources allow you to configure them at various levels:

• System.Windows - 所有 WPF 的设置
• System.Windows.Animation - 专为动画覆盖.

听众

您使用什么日志输出?

• 文本文件
• XML 文件
• 事件日志
• 其他?

如果使用文件，您是使用滚动日志还是仅使用单个文件?您如何使日志可供人们使用?

If using files, do you use rolling logs or just a single file? How do you make the logs available for people to consume?

查看

您使用什么工具查看日志?

What tools to you use for viewing the logs?

• 记事本
• 尾巴
• 事件查看器
• 系统中心运营经理/微软运营经理
• WCF 服务跟踪查看器
• 其他?

如果您正在构建 ASP.NET 解决方案，您是否也使用 ASP.NET 运行状况监控?您是否在运行状况监视器事件中包含跟踪输出?Trace.axd 呢?

If you are building an ASP.NET solution, do you also use ASP.NET Health Monitoring? Do you include trace output in the health monitor events? What about Trace.axd?

自定义性能计数器呢?

推荐答案

---

更新:对于 System.Diagnostics 的扩展，提供一些您可能需要的缺失侦听器，请参阅 CodePlex 上的 Essential.Diagnostics (http://essentialdiagnostics.codeplex.com/)

---

Update: For extensions to System.Diagnostics, providing some of the missing listeners you might want, see Essential.Diagnostics on CodePlex (http://essentialdiagnostics.codeplex.com/)

框架

A:System.Diagnostics.TraceSource，内置于 .NET 2.0.

它为应用程序提供了强大、灵活、高性能的日志记录，但是许多开发人员并不了解它的功能，也没有充分利用它们.

It provides powerful, flexible, high performance logging for applications, however many developers are not aware of its capabilities and do not make full use of them.

在某些领域，附加功能很有用，或者有时功能存在但没有很好的文档记录，但这并不意味着整个日志记录框架(设计为可扩展的)应该被丢弃并完全替换，例如一些流行的替代方案(NLog、log4net、Common.Logging，甚至 EntLib Logging).

There are some areas where additional functionality is useful, or sometimes the functionality exists but is not well documented, however this does not mean that the entire logging framework (which is designed to be extensible) should be thrown away and completely replaced like some popular alternatives (NLog, log4net, Common.Logging, and even EntLib Logging).

与其改变向应用程序添加日志语句的方式并重新发明轮子，不如在您需要的几个地方扩展 System.Diagnostics 框架.

Rather than change the way you add logging statements to your application and re-inventing the wheel, just extended the System.Diagnostics framework in the few places you need it.

在我看来，其他框架，甚至 EntLib，都只是遭受了 Not Invented Here Syndrome 的困扰，我认为他们浪费了时间重新发明在 System.Diagnostics 中已经运行良好的基础知识(例如您如何编写日志陈述)，而不是填补存在的少数空白.简而言之，不要使用它们——它们不是必需的.

It seems to me the other frameworks, even EntLib, simply suffer from Not Invented Here Syndrome, and I think they have wasted time re-inventing the basics that already work perfectly well in System.Diagnostics (such as how you write log statements), rather than filling in the few gaps that exist. In short, don't use them -- they aren't needed.

您可能不知道的功能:

• 使用采用格式字符串和参数的 TraceEvent 重载可以帮助提高性能，因为参数作为单独的引用保留，直到 Filter.ShouldTrace() 成功之后.这意味着在系统确认消息将实际记录之前，不会对参数值调用昂贵的 ToString().
• Trace.CorrelationManager 允许您关联关于相同逻辑操作的日志语句(见下文).
• VisualBasic.Logging.FileLogTraceListener 适用于写入日志文件并支持文件轮换.尽管在 VisualBasic 命名空间中，只需包含 DLL，就可以在 C#(或其他语言)项目中轻松使用它.
• 当使用 EventLogTraceListener 时，如果您使用多个参数和空或空格式字符串调用 TraceEvent，那么如果您使用本地化消息资源，则参数将直接传递给 EventLog.WriteEntry().
• Service Trace Viewer 工具(来自 WCF)可用于查看活动相关日志文件的图表(即使您没有使用 WCF).这确实可以帮助调试涉及多个线程/活动的复杂问题.
• 通过清除所有侦听器(或删除默认值)来避免开销；否则 Default 会将所有内容传递给跟踪系统(并产生所有这些 ToString() 开销).

您可能希望扩展的领域(如果需要):

• 数据库跟踪监听器
• 彩色控制台跟踪监听器
• MSMQ/电子邮件/WMI 跟踪侦听器(如果需要)
• 实现 FileSystemWatcher 以调用 Trace.Refresh 以进行动态配置更改

其他建议:

使用结构化事件 ID，并保留参考列表(例如，将它们记录在枚举中).

Use structed event id's, and keep a reference list (e.g. document them in an enum).

为系统中的每个(重要)事件设置唯一的事件 ID 对于关联和查找特定问题非常有用.很容易追溯到记录/使用事件 ID 的特定代码，并且可以轻松地为常见错误提供指导，例如错误 5178 表示您的数据库连接字符串错误等.

Having unique event id's for each (significant) event in your system is very useful for correlating and finding specific issues. It is easy to track back to the specific code that logs/uses the event ids, and can make it easy to provide guidance for common errors, e.g. error 5178 means your database connection string is wrong, etc.

事件 id 应该遵循某种结构(类似于电子邮件和 HTTP 中使用的回复代码理论)，这允许您在不知道特定代码的情况下按类别处理它们.

Event id's should follow some kind of structure (similar to the Theory of Reply Codes used in email and HTTP), which allows you to treat them by category without knowing specific codes.

例如第一个数字可以详细说明一般类别:1xxx 可用于开始"操作，2xxx 用于正常行为，3xxx 用于活动跟踪，4xxx 用于警告，5xxx 用于错误，8xxx 用于停止"操作，9xxx 用于致命错误等.

e.g. The first digit can detail the general class: 1xxx can be used for 'Start' operations, 2xxx for normal behaviour, 3xxx for activity tracing, 4xxx for warnings, 5xxx for errors, 8xxx for 'Stop' operations, 9xxx for fatal errors, etc.

第二个数字可以详细说明区域，例如21xx 数据库信息(41xx 数据库警告，51xx 数据库错误)，22xx 计算模式(42xx 计算警告等)，23xx 其他模块等

The second digit can detail the area, e.g. 21xx for database information (41xx for database warnings, 51xx for database errors), 22xx for calculation mode (42xx for calculation warnings, etc), 23xx for another module, etc.

分配的结构化事件 ID 还允许您在过滤器中使用它们.

Assigned, structured event id's also allow you use them in filters.

答:Trace.CorrelationManager 对于在任何类型的多线程环境中关联日志语句非常有用(现在几乎是任何环境).

您至少需要为每个逻辑操作设置一次 ActivityId 以进行关联.

You need at least to set the ActivityId once for each logical operation in order to correlate.

Start/Stop 和 LogicalOperationStack 然后可用于简单的基于堆栈的上下文.对于更复杂的上下文(例如异步操作)，使用 TraceTransfer 到新的 ActivityId(在更改它之前)，允许关联.

Start/Stop and the LogicalOperationStack can then be used for simple stack-based context. For more complex contexts (e.g. asynchronous operations), using TraceTransfer to the new ActivityId (before changing it), allows correlation.

Service Trace Viewer 工具可用于查看活动图(即使您没有使用 WCF).

The Service Trace Viewer tool can be useful for viewing activity graphs (even if you aren't using WCF).

A:您可能想要创建一个范围类，例如LogicalOperationScope，即 (a) 在创建时设置上下文，(b) 在释放时重置上下文.

这允许您编写如下代码来自动包装操作:

This allows you to write code such as the following to automatically wrap operations:

  using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
  {
    // .. do work here
  }

在创建时，如果需要，范围可以首先设置 ActivityId，调用 StartLogicalOperation，然后记录 TraceEventType.Start 消息.在 Dispose 时，它​​可以记录停止消息，然后调用 StopLogicalOperation.

On creation the scope could first set ActivityId if needed, call StartLogicalOperation and then log a TraceEventType.Start message. On Dispose it could log a Stop message, and then call StopLogicalOperation.

答:是的，随着系统变大，多个跟踪源很有用/很重要.

虽然您可能希望始终如一地记录所有警告 &以上，或所有信息 &以上消息，对于任何合理大小的系统，活动跟踪(开始、停止等)和详细日志记录的数量都变得太多了.

Whilst you probably want to consistently log all Warning & above, or all Information & above messages, for any reasonably sized system the volume of Activity Tracing (Start, Stop, etc) and Verbose logging simply becomes too much.

与其只有一个开关来开启或关闭所有功能，能够一次为系统的一个部分打开此信息是很有用的.

Rather than having only one switch that turns it all either on or off, it is useful to be able to turn on this information for one section of your system at a time.

通过这种方式，您可以从通常的日志记录(所有警告、错误等)中找到重大问题，然后放大"您想要的部分并将它们设置为活动跟踪甚至调试级别.

This way, you can locate significant problems from the usually logging (all warnings, errors, etc), and then "zoom in" on the sections you want and set them to Activity Tracing or even Debug levels.

您需要的跟踪源数量取决于您的应用程序，例如您可能希望每个程序集或应用程序的每个主要部分都有一个跟踪源.

The number of trace sources you need depends on your application, e.g. you may want one trace source per assembly or per major section of your application.

如果您需要更精细的控制，请添加单独的布尔开关以打开/关闭特定的高音量跟踪，例如原始消息转储.(或者可以使用单独的跟踪源，类似于 WCF/WPF).

If you need even more fine tuned control, add individual boolean switches to turn on/off specific high volume tracing, e.g. raw message dumps. (Or a separate trace source could be used, similar to WCF/WPF).

您可能还想为活动跟踪与一般(其他)日志记录考虑单独的跟踪源，因为这样可以更轻松地按照您想要的方式配置过滤器.

You might also want to consider separate trace sources for Activity Tracing vs general (other) logging, as it can make it a bit easier to configure filters exactly how you want them.

请注意，即使使用不同的来源，消息仍然可以通过 ActivityId 进行关联，因此请根据需要使用尽可能多的消息.

Note that messages can still be correlated via ActivityId even if different sources are used, so use as many as you need.

问:您使用什么日志输出?

这取决于您正在编写的应用程序类型以及正在记录的内容.通常不同的东西放在不同的地方(即多个输出).

This can depend on what type of application you are writing, and what things are being logged. Usually different things go in different places (i.e. multiple outputs).

我通常将输出分为三组:

I generally classify outputs into three groups:

(1) 事件 - Windows 事件日志(和跟踪文件)

例如如果编写服务器/服务，则 Windows 上的最佳实践是使用 Windows 事件日志(您没有要向其报告的 UI).

e.g. If writing a server/service, then best practice on Windows is to use the Windows Event Log (you don't have a UI to report to).

在这种情况下，所有致命、错误、警告和(服务级别)信息事件都应转到 Windows 事件日志.应为这些类型的高级事件保留信息级别，即您想要在事件日志中记录的事件，例如服务已启动"、服务已停止"、已连接到 Xyz"，甚至可能是计划启动"、用户登录"等

In this case all Fatal, Error, Warning and (service-level) Information events should go to the Windows Event Log. The Information level should be reserved for these type of high level events, the ones that you want to go in the event log, e.g. "Service Started", "Service Stopped", "Connected to Xyz", and maybe even "Schedule Initiated", "User Logged On", etc.

在某些情况下，您可能希望将事件日志写入应用程序的内置部分，而不是通过跟踪系统(即直接写入事件日志条目).这意味着它不会被意外关闭.(请注意，您仍然希望在跟踪系统中记录相同的事件，以便进行关联).

In some cases you may want to make writing to the event log a built-in part of your application and not via the trace system (i.e. write Event Log entries directly). This means it can't accidentally be turned off. (Note you still also want to note the same event in your trace system so you can correlate).

相比之下，Windows GUI 应用程序通常会将这些报告给用户(尽管他们也可能会记录到 Windows 事件日志中).

In contrast, a Windows GUI application would generally report these to the user (although they may also log to the Windows Event Log).

事件也可能有相关的性能计数器(例如错误数/秒)，协调任何直接写入事件日志、性能计数器、写入跟踪系统和报告给用户是很重要的它们同时发生.

Events may also have related performance counters (e.g. number of errors/sec), and it can be important to co-ordinate any direct writing to the Event Log, performance counters, writing to the trace system and reporting to the user so they occur at the same time.

即如果用户在特定时间看到错误消息，您应该能够在 Windows 事件日志中找到相同的错误消息，然后在跟踪日志中找到具有相同时间戳的相同事件(以及其他跟踪详细信息).

i.e. If a user sees an error message at a particular time, you should be able to find the same error message in the Windows Event Log, and then the same event with the same timestamp in the trace log (along with other trace details).

(2) 活动 - 应用程序日志文件或数据库表(和跟踪文件)

这是系统执行的常规活动，例如提供的网页、提交的股票市场交易、接受的订单、执行的计算等.

This is the regular activity that a system does, e.g. web page served, stock market trade lodged, order taken, calculation performed, etc.

活动跟踪(开始、停止等)在这里很有用(以正确的粒度).

Activity Tracing (start, stop, etc) is useful here (at the right granuality).

此外，使用特定的应用程序日志(有时称为审核日志)也很常见.通常这是一个数据库表或一个应用程序日志文件，包含结构化数据(即一组字段).

Also, it is very common to use a specific Application Log (sometimes called an Audit Log). Usually this is a database table or an application log file and contains structured data (i.e. a set of fields).

根据您的应用程序，这里的内容可能会有些模糊.一个很好的例子可能是一个 Web 服务器，它将每个请求写入一个 Web 日志；类似的示例可能是消息传递系统或计算系统，其中每个操作都与特定于应用程序的详细信息一起记录.

Things can get a bit blurred here depending on your application. A good example might be a web server which writes each request to a web log; similar examples might be a messaging system or calculation system where each operation is logged along with application-specific details.

一个不太好的例子是股票市场交易或销售订单系统.在这些系统中，您可能已经在记录活动，因为它们具有重要的业务价值，但是将它们与其他操作相关联的原则仍然很重要.

A not so good example is stock market trades or a sales ordering system. In these systems you are probably already logging the activity as they have important business value, however the principal of correlating them to other actions is still important.

除了自定义应用程序日志外，活动通常还具有相关的性能计数器，例如每秒事务数.

As well as custom application logs, activities also often have related peformance counters, e.g. number of transactions per second.

通常，您应该协调跨不同系统的活动记录，即在增加性能计数器并记录到跟踪系统的同时写入应用程序日志.如果您同时执行所有操作(或在代码中直接执行)，那么调试问题会更容易(比它们都发生在代码中的不同时间/位置)更容易.

In generally you should co-ordinate logging of activities across different systems, i.e. write to your application log at the same time as you increase your performance counter and log to your trace system. If you do all at the same time (or straight after each other in the code), then debugging problems is easier (than if they all occur at diffent times/locations in the code).

(3) 调试跟踪 - 文本文件，或者 XML 或数据库.

这是详细级别及更低级别的信息(例如，用于打开/关闭原始数据转储的自定义布尔开关).这提供了系统在子活动级别执行的操作的内容或细节.

This is information at Verbose level and lower (e.g. custom boolean switches to turn on/off raw data dumps). This provides the guts or details of what a system is doing at a sub-activity level.

这是您希望能够为应用程序的各个部分(因此有多个源)打开/关闭的级别.您不希望这些东西弄乱 Windows 事件日志.有时会使用数据库，但更有可能是在一段时间后清除的滚动日志文件.

This is the level you want to be able to turn on/off for individual sections of your application (hence the multiple sources). You don't want this stuff cluttering up the Windows Event Log. Sometimes a database is used, but more likely are rolling log files that are purged after a certain time.

此信息与应用程序日志文件之间的一个很大区别在于它是非结构化的.虽然应用程序日志可能包含 To、From、Amount 等字段，但 Verbose 调试跟踪可能是程序员输入的任何内容，例如检查值 X={value}，Y=false"，或诸如完成，再试一次"之类的随机评论/标记.

A big difference between this information and an Application Log file is that it is unstructured. Whilst an Application Log may have fields for To, From, Amount, etc., Verbose debug traces may be whatever a programmer puts in, e.g. "checking values X={value}, Y=false", or random comments/markers like "Done it, trying again".

一个重要的做法是确保您放入应用程序日志文件或 Windows 事件日志中的内容也以相同的详细信息(例如时间戳)记录到跟踪系统中.这样您就可以在调查时关联不同的日志.

One important practice is to make sure things you put in application log files or the Windows Event Log also get logged to the trace system with the same details (e.g. timestamp). This allows you to then correlate the different logs when investigating.

如果您计划使用特定的日志查看器，因为您有复杂的相关性，例如服务跟踪查看器，那么您需要使用适当的格式，即 XML.否则，一个简单的文本文件通常就足够了——在较低级别，信息主要是非结构化的，因此您可能会发现数组转储、堆栈转储等.如果您可以关联回更高级别的更结构化的日志，事情应该没事.

If you are planning to use a particular log viewer because you have complex correlation, e.g. the Service Trace Viewer, then you need to use an appropriate format i.e. XML. Otherwise, a simple text file is usually good enough -- at the lower levels the information is largely unstructured, so you might find dumps of arrays, stack dumps, etc. Provided you can correlated back to more structured logs at higher levels, things should be okay.

问:如果使用文件，您使用滚动日志还是仅使用单个文件?您如何使日志可供人们使用?

A:对于文件，通常您希望从可管理性的角度滚动日志文件(使用 System.Diagnostics 只需使用 VisualBasic.Logging.FileLogTraceListener).

A: For files, generally you want rolling log files from a manageability point of view (with System.Diagnostics simply use VisualBasic.Logging.FileLogTraceListener).

可用性再次取决于系统.如果您只是在谈论文件，那么对于服务器/服务，可以在必要时访问滚动文件.(Windows 事件日志或数据库应用程序日志将有自己的访问机制).

Availability again depends on the system. If you are only talking about files then for a server/service, rolling files can just be accessed when necessary. (Windows Event Log or Database Application Logs would have their own access mechanisms).

如果您无法轻松访问文件系统，那么调试跟踪到数据库可能会更容易.[IE.实现一个数据库 TraceListener].

If you don't have easy access to the file system, then debug tracing to a database may be easier. [i.e. implement a database TraceListener].

我在 Windows GUI 应用程序中看到的一个有趣的解决方案是，它在运行时将非常详细的跟踪信息记录到飞行记录器"中，然后当您关闭它时，如果它没有问题，它就会简单地删除该文件.

One interesting solution I saw for a Windows GUI application was that it logged very detailed tracing information to a "flight recorder" whilst running and then when you shut it down if it had no problems then it simply deleted the file.

但是，如果它崩溃或遇到问题，则该文件不会被删除.如果它捕获错误，或者下次运行时它会注意到该文件，然后它可以采取行动，例如压缩它(例如 7zip)并通过电子邮件发送或以其他方式提供.

If, however it crashed or encountered a problem then the file was not deleted. Either if it catches the error, or the next time it runs it will notice the file, and then it can take action, e.g. compress it (e.g. 7zip) and email it or otherwise make available.

如今，许多系统都将故障自动报告给中央服务器(在与用户核对后，例如出于隐私原因).

Many systems these days incorporate automated reporting of failures to a central server (after checking with users, e.g. for privacy reasons).

问:您使用哪些工具查看日志?

A:如果您出于不同原因有多个日志，那么您将使用多个查看器.

A: If you have multiple logs for different reasons then you will use multiple viewers.

Notepad/vi/Notepad++ 或任何其他文本编辑器是纯文本日志的基础.

Notepad/vi/Notepad++ or any other text editor is the basic for plain text logs.

如果您有复杂的操作，例如传输的活动，那么您显然会使用像 Service Trace Viewer 这样的专用工具.(但如果你不需要它，那么文本编辑器更容易).

If you have complex operations, e.g. activities with transfers, then you would, obviously, use a specialized tool like the Service Trace Viewer. (But if you don't need it, then a text editor is easier).

因为我通常将高级信息记录到 Windows 事件日志中，所以它提供了一种以结构化方式快速获取概览的方法(寻找漂亮的错误/警告图标).如果日志中没有足够的文本文件，您只需要开始搜索文本文件，尽管至少日志为您提供了一个起点.(此时，确保您的日志具有协调的整体变得很有用).

As I generally log high level information to the Windows Event Log, then it provides a quick way to get an overview, in a structured manner (look for the pretty error/warning icons). You only need to start hunting through text files if there is not enough in the log, although at least the log gives you a starting point. (At this point, making sure your logs have co-ordinated entires becomes useful).

通常，Windows 事件日志也会将这些重要事件提供给 MOM 或 OpenView 等监控工具.

Generally the Windows Event Log also makes these significant events available to monitoring tools like MOM or OpenView.

其他 --

如果您登录到数据库，则可以轻松过滤和排序信息(例如放大特定活动 ID.(对于文本文件，您可以使用 Grep/PowerShell 或类似工具过滤您想要的特定 GUID)

If you log to a Database it can be easy to filter and sort informatio (e.g. zoom in on a particular activity id. (With text files you can use Grep/PowerShell or similar to filter on the partiular GUID you want)

MS Excel(或其他电子表格程序).如果您可以使用正确的分隔符导入结构化或半结构化信息，以便不同的值出现在不同的列中，这对于分析结构化或半结构化信息非常有用.

MS Excel (or another spreadsheet program). This can be useful for analysing structured or semi-structured information if you can import it with the right delimiters so that different values go in different columns.

在调试/测试中运行服务时，为了简单起见，我通常将其托管在控制台应用程序中，我发现彩色控制台记录器很有用(例如，红色表示错误，黄色表示警告等).您需要实现自定义跟踪侦听器.

When running a service in debug/test I usually host it in a console application for simplicity I find a colored console logger useful (e.g. red for errors, yellow for warnings, etc). You need to implement a custom trace listener.

请注意，该框架不包含彩色控制台记录器或数据库记录器，因此，现在，如果需要，您需要编写这些(这并不难).

Note that the framework does not include a colored console logger or a database logger so, right now, you would need to write these if you need them (it's not too hard).

让我很恼火的是，几个框架(log4net、EntLib 等)浪费时间重新发明轮子并重新实现基本的日志记录、过滤和记录到文本文件、Windows 事件日志和 XML 文件，每个以他们自己不同的方式(每个日志语句都不同)；然后每个人都实现了自己的版本，例如，一个数据库记录器，当其中大部分已经存在并且所需要的只是 System.Diagnostics 的几个跟踪侦听器.说说重复劳动的巨大浪费.

It really annoys me that several frameworks (log4net, EntLib, etc) have wasted time re-inventing the wheel and re-implemented basic logging, filtering, and logging to text files, the Windows Event Log, and XML files, each in their own different way (log statements are different in each); each has then implemented their own version of, for example, a database logger, when most of that already existed and all that was needed was a couple more trace listeners for System.Diagnostics. Talk about a big waste of duplicate effort.

问:如果您正在构建 ASP.NET 解决方案，您是否也使用 ASP.NET Health Monitoring?您是否在运行状况监视器事件中包含跟踪输出?Trace.axd 怎么样?

这些东西可以根据需要打开/关闭.我发现 Trace.axd 对于调试服务器如何响应某些事情非常有用，但它通常不适用于频繁使用的环境或长期跟踪.

These things can be turned on/off as needed. I find Trace.axd quite useful for debugging how a server responds to certain things, but it's not generally useful in a heavily used environment or for long term tracing.

问:自定义性能计数器怎么样?

对于专业应用程序，尤其是服务器/服务，我希望看到它完全配备性能监视器计数器并记录到 Windows 事件日志.这些是 Windows 中的标准工具，应该使用.

For a professional application, especially a server/service, I expect to see it fully instrumented with both Performance Monitor counters and logging to the Windows Event Log. These are the standard tools in Windows and should be used.

您需要确保包含您使用的性能计数器和事件日志的安装程序；这些应该在安装时创建(以管理员身份安装时).当您的应用程序正常运行时，它应该不需要具有管理权限(因此将无法创建丢失的日志).

You need to make sure you include installers for the performance counters and event logs that you use; these should be created at installation time (when installing as administrator). When your application is running normally it should not need have administration privileges (and so won't be able to create missing logs).

这是练习以非管理员身份进行开发的一个很好的理由(在需要安装服务等时有一个单独的管理员帐户).如果写入事件日志，.NET 将在您第一次写入时自动创建一个丢失的日志；如果您以非管理员身份进行开发，您将尽早发现这一点，并避免在客户安装您的系统后出现令人讨厌的意外，然后因为他们不是以管理员身份运行而无法使用它.

This is a good reason to practice developing as a non-administrator (have a separate admin account for when you need to install services, etc). If writing to the Event Log, .NET will automatically create a missing log the first time you write to it; if you develop as a non-admin you will catch this early and avoid a nasty surprise when a customer installs your system and then can't use it because they aren't running as administrator.

这篇关于记录最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！