Enterprise Library 5:异常未记录到 Windows Azure 上的事件日志中
我有一个部署为 Windows Azure Web 角色的 WCF 服务。
我正在使用 Enterprise Library 进行异常处理,并且在我的本地 Development Fabric 中,异常似乎可以使用事件日志处理程序(记录到应用程序事件日志)正确处理和记录。
当它在 Azure 上运行时,虽然似乎应用了异常策略(因为我正在观察某些预期异常的正确处理),但事件日志中没有记录任何内容。
这是异常处理策略:
<add name="Entity">
<exceptionTypes>
<add name="All Exceptions"
type="System.Exception, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
postHandlingAction="NotifyRethrow">
<exceptionHandlers>
<add name="Logging Exception Handler"
type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
logCategory="General"
eventId="100"
severity="Error"
title="Enterprise Library Exception Handling"
formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling"
priority="0" />
</exceptionHandlers>
</add>
</exceptionTypes>
</add>
这是日志记录配置:
<loggingConfiguration name="" tracingEnabled="true" defaultCategory="General">
<listeners>
<add name="Event Log Listener"
type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" source="Enterprise Library Logging" formatter="Text Formatter"
log="Application"
machineName="."
traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack" />
</listeners>
<formatters>
<add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
template="Timestamp: {timestamp}{newline}
Message: {message}{newline}
Category: {category}{newline}
Priority: {priority}{newline}
EventId: {eventid}{newline}
Severity: {severity}{newline}
Title:{title}{newline}
Machine: {localMachine}{newline}
App Domain: {localAppDomain}{newline}
ProcessId: {localProcessId}{newline}
Process Name: {localProcessName}{newline}
Thread Name: {threadName}{newline}
Win32 ThreadId:{win32ThreadId}{newline}
Extended Properties: {dictionary({key} - {value}{newline})}"
name="Text Formatter" />
</formatters>
<categorySources>
<add switchValue="All" name="General">
<listeners>
<add name="Event Log Listener" />
</listeners>
</add>
</categorySources>
<specialSources>
<allEvents switchValue="All" name="All Events" />
<notProcessed switchValue="All" name="Unprocessed Category" />
<errors switchValue="All" name="Logging Errors & Warnings">
<listeners>
<add name="Event Log Listener" />
</listeners>
</errors>
</specialSources>
</loggingConfiguration>
知道出了什么问题吗?
I have a WCF service that's deployed as a Windows Azure Web Role.
I'm using Enterprise Library for exception handling and in my local Development Fabric, exceptions seem to be handled and logged correctly using the Event Log Handler (logging to the Application event log).
When it's running on Azure, while the Exception Policy seems to be being applied (as I'm observing correct handling of certain expected exceptions), nothing's being logged to the Event Log.
Here's the exception handling policy:
<add name="Entity">
<exceptionTypes>
<add name="All Exceptions"
type="System.Exception, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
postHandlingAction="NotifyRethrow">
<exceptionHandlers>
<add name="Logging Exception Handler"
type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging.LoggingExceptionHandler, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
logCategory="General"
eventId="100"
severity="Error"
title="Enterprise Library Exception Handling"
formatterType="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.TextExceptionFormatter, Microsoft.Practices.EnterpriseLibrary.ExceptionHandling"
priority="0" />
</exceptionHandlers>
</add>
</exceptionTypes>
</add>
And here's the Logging configuration:
<loggingConfiguration name="" tracingEnabled="true" defaultCategory="General">
<listeners>
<add name="Event Log Listener"
type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" source="Enterprise Library Logging" formatter="Text Formatter"
log="Application"
machineName="."
traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, ProcessId, ThreadId, Callstack" />
</listeners>
<formatters>
<add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
template="Timestamp: {timestamp}{newline}
Message: {message}{newline}
Category: {category}{newline}
Priority: {priority}{newline}
EventId: {eventid}{newline}
Severity: {severity}{newline}
Title:{title}{newline}
Machine: {localMachine}{newline}
App Domain: {localAppDomain}{newline}
ProcessId: {localProcessId}{newline}
Process Name: {localProcessName}{newline}
Thread Name: {threadName}{newline}
Win32 ThreadId:{win32ThreadId}{newline}
Extended Properties: {dictionary({key} - {value}{newline})}"
name="Text Formatter" />
</formatters>
<categorySources>
<add switchValue="All" name="General">
<listeners>
<add name="Event Log Listener" />
</listeners>
</add>
</categorySources>
<specialSources>
<allEvents switchValue="All" name="All Events" />
<notProcessed switchValue="All" name="Unprocessed Category" />
<errors switchValue="All" name="Logging Errors & Warnings">
<listeners>
<add name="Event Log Listener" />
</listeners>
</errors>
</specialSources>
</loggingConfiguration>
Any idea what's going wrong?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
进行日志记录的最佳方法是使用诊断跟踪侦听器。 Windows Azure 中事件日志的名称不同。要使用此企业库,您需要从事件日志侦听器更改为 Windows Azure 诊断跟踪侦听器。我们在《将应用程序移至云端一书中提供了有关此内容的更多信息”。代码位于 VS 2008 中,但您可以在 VS 2010 中打开以查看示例。在代码中,了解我们如何使用 Windows Azure 诊断跟踪侦听器设置企业库日志记录。您需要确保将日志移过来才能查看信息。书中对此进行了详细介绍。
如果您想快速浏览一下,可以从我们的 codeplex 此处下载音乐应用程序网站展示了如何将 Enterprise Library 与 Windows Azure 结合使用。这是我们正在努力升级的旧版本。
有关跟踪的更多信息,请参见此处。
The best way to do logging is to use the diagnostic trace listener. The names for Event Logs in Windows Azure is different. To do with this Enterprise Library you will need to change from the Event Log listener to the Windows Azure Diagnostic Trace listener. We have more information about this in our book "Moving Applications to the Cloud". The code is in VS 2008 but you can open in VS 2010 to see the samples. In the code and see how we setup Enterprise Library Logging with the Windows Azure Diagnostic Trace Listener. You will need to make sure to move the logs over to see the information. The book goes into detail about this.
If you want to just get a quick look you can download the Music Application here from our codeplex site that shows how to use Enterprise Library with Windows Azure. This is older version that we are working to upgrade.
More on tracing here.
使用默认设置的事件日志跟踪侦听器的先决条件是确保安装了默认事件源(“企业库日志记录”)。为了安装此事件源(或任何其他自定义源)并使用此侦听器,可以使用执行 Windows PowerShell 脚本的启动任务。这些脚本安装自定义源。带有相应 PowerShell 脚本的 QuickStart 使用此方法。
A prerequisite for using the Event Log Trace Listener with the default settings is to ensure that the default event source ("Enterprise Library Logging") is installed. In order to install this event source (or any other custom source) and use this listener, a startup task that executes Windows PowerShell scripts can be used. These scripts install the custom source. A QuickStart with the corresponding PowerShell script uses this approach.