6

我正在寻找一些关于日志记录的建议。我编写了一个名为的包装器Logger ，它在内部使用Microsoft Enterprise Library 5.0。目前它使我们能够以这种方式登录：

Logger.Error(LogCategory.Server, "Some message with some state {0}", state);

我面临的问题是 EventViewer 中的每个日志似乎都是不相关的，即使它们中的一些以某种方式相关，例如它们都来自处理来自特定客户端的请求。

让我详细说明这个问题。假设我正在开发一个需要同时处理来自多个客户端的请求的服务，每个客户端都将不同的参数集传递给服务方法。很少有参数可以用来识别请求，例如哪个客户端正在使用哪些唯一可识别的参数发出什么样的请求等。假设这些参数是（调用上下文信息）：

  • 服务器配置文件 ID
  • WebProfileId
  • 请求编号
  • 会话信息

现在服务开始处理请求，一件接一件地做（就像一个工作流）。在此过程中，我正在记录本地1消息，例如"file not found"或"entry not found in DB"，但我不想在每个日志中手动记录上述信息（上下文信息），而是我想要每次我记录本地消息时，记录器都会自动记录它们：

Logger.Error(LogCategory.Server, "requested file not found");

我希望上面的调用记录上下文信息以及“未找到请求的文件”消息，以便我可以将消息与其上下文相关联。

问题是，我应该如何设计这样一个自动记录上下文的记录器包装器？我希望它足够灵活，以便我可以在服务处理请求的过程中添加更具体的上下文信息，因为所有重要信息在请求开始时可能都不可用！

我还想让它可配置，这样我就可以在不记录上下文信息的情况下记录本地消息，因为当一切正常时不需要它们。:-)

1.本地信息是指更具体、更本地化的信息。相比之下，我会说，上下文信息是全局消息，因为它们对于处理请求的整个流程都有意义。

4

2 回答 2

4

这是一种使用相当容易设置的企业库的方法。您可以使用活动跟踪来存储全局上下文，使用扩展属性来存储本地上下文。

作为示例，我将使用没有任何包装类的服务定位器来演示该方法。

var traceManager = EnterpriseLibraryContainer.Current.GetInstance<TraceManager>();

using (var tracer1 = traceManager.StartTrace("MyRequestId=" + GetRequestId().ToString()))
using (var tracer2 = traceManager.StartTrace("ClientID=" + clientId))
{
    DoSomething();
}

static void DoSomething()
{
    var logWriter = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();
    logWriter.Write("doing something", "General");

    DoSomethingElse("ABC.txt");
}

static void DoSomethingElse(string fileName)
{
    var logWriter = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();

    // Oops need to log
    LogEntry logEntry = new LogEntry()
    {
        Categories = new string[] { "General" },
        Message = "requested file not found",
        ExtendedProperties = new Dictionary<string, object>() { { "filename", fileName } }
    };

    logWriter.Write(logEntry);
}

配置如下所示：

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="true" />
    </configSections>
    <loggingConfiguration name="" tracingEnabled="true" defaultCategory="General"
        logWarningsWhenNoCategoriesMatch="false">
        <listeners>
            <add name="Flat File Trace Listener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                fileName="trace.log" formatter="Text Formatter" traceOutputOptions="LogicalOperationStack" />
        </listeners>
        <formatters>
            <add type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=5.0.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
                template="Timestamp: {timestamp}&#xA;Message: {message}&#xA;ActivityID: {activity}&#xA;Context: {category}&#xA;Priority: {priority}&#xA;EventId: {eventid}&#xA;Severity: {severity}&#xA;Title:{title}&#xA;Machine: {localMachine}&#xA;App Domain: {localAppDomain}&#xA;ProcessId: {localProcessId}&#xA;Process Name: {localProcessName}&#xA;Thread Name: {threadName}&#xA;Win32 ThreadId:{win32ThreadId}&#xA;Local Context: {dictionary({key} - {value}{newline})}"
                name="Text Formatter" />
        </formatters>
        <categorySources>
            <add switchValue="All" name="General">
                <listeners>
                    <add name="Flat File Trace Listener" />
                </listeners>
            </add>
        </categorySources>
        <specialSources>
            <allEvents switchValue="All" name="All Events" />
            <notProcessed switchValue="All" name="Unprocessed Category" />
            <errors switchValue="All" name="Logging Errors &amp; Warnings" />
        </specialSources>
    </loggingConfiguration>
</configuration>

这将导致如下输出：

----------------------------------------
Timestamp: 1/16/2013 3:50:11 PM
Message: doing something
ActivityID: 5b765d8c-935a-445c-b9fb-bde4db73124f
Context: General, ClientID=123456, MyRequestId=8f2828be-44bf-436c-9e24-9641963db09a
Priority: -1
EventId: 1
Severity: Information
Title:
Machine: MACHINE
App Domain: LoggingTracerNDC.exe
ProcessId: 5320
Process Name: LoggingTracerNDC.exe
Thread Name: 
Win32 ThreadId:8472
Local Context: 
----------------------------------------
----------------------------------------
Timestamp: 1/16/2013 3:50:11 PM
Message: requested file not found
ActivityID: 5b765d8c-935a-445c-b9fb-bde4db73124f
Context: General, ClientID=123456, MyRequestId=8f2828be-44bf-436c-9e24-9641963db09a
Priority: -1
EventId: 0
Severity: Information
Title:
Machine: MACHINE
App Domain: LoggingTracerNDC.exe
ProcessId: 5320
Process Name: LoggingTracerNDC.exe
Thread Name: 
Win32 ThreadId:8472
Local Context: filename - ABC.txt

----------------------------------------

注意事项：

  • 由于我们正在使用跟踪，因此我们免费获得了可用于关联活动的 .NET 活动 ID。当然，我们也可以使用我们自己的上下文信息（自定义请求 ID、客户端 ID 等）。
  • 企业库使用跟踪“操作名称”作为类别，因此我们需要设置 logWarningsWhenNoCategoriesMatch="false" 否则我们会收到一连串的警告消息。
  • 这种方法的缺点可能是性能（但我没有测量它）。

如果你想禁用全局上下文（在这个实现中，跟踪）那么你需要做的就是编辑配置文件并设置tracingEnabled="false"。

这似乎是使用内置企业库功能实现目标的一种相当直接的方式。

其他要考虑的方法是可能使用某种非常优雅的拦截（自定义 LogCallHandler）（但这可能取决于现有设计）。

如果您要使用自定义实现来收集和管理上下文，那么您可以考虑使用Trace.CorrelationManager来处理每个线程上下文。您还可以查看创建一个IExtraInformationProvider以填充扩展属性字典（有关示例，请参见 Enterprise Library 3.1 Logging Formatter Template - Include URL Request）。

于 2013-01-16T16:02:42.267 回答
1

免责声明：我不知道微软技术栈的细节。

在这种情况下，我会做的事情是：

实现一个 Singleton（在服务器实例级别，如果您的应用程序部署到集群，它不需要是全局单例），它基本上是一种 Hashmap，其中“Key”是您请求的唯一有意义的标识符加工。在 Java 中，我会使用线程 ID（假设您通过从线程池调度线程来服务请求）。如果这在您的情况下不可能/没有意义，则必须使用请求 ID（但在这种情况下，您必须使其渗透到日志管理器，而我的想法是使用本质上可用的东西线程本身）。

Hashmap 的“值”将是一组数据——在你的情况下是 ServerProfileId、WebProfileId、RequestId（除非它已经是键）、SessionInfo——以便日志管理器可以有条件地检索这些并获取对一个有意义的部分特定的日志事件。

所以：在请求管理开始时创建一个全局可用的请求状态引用，并确保日志管理器可以在需要时检索请求状态。

当然，您必须确保正确管理哈希图（通过在处理请求后删除状态）。

于 2013-01-16T15:03:10.483 回答