代码之家 › 专栏 › 技术社区 › Dina

从基于文件的跟踪会话移动到实时会话

etw trace

Dina · 技术社区 · 8 年前

我需要在引导期间记录跟踪事件,因此我使用所有必需的提供程序配置自动记录器。但是当我的服务/进程启动时,我想切换到实时模式,这样文件就不会爆炸。我正在使用 TraceEvent 我不知道如何正确地、原子地做这个动作。

我尝试的第一件事是:

const int timeToWait = 5000;

using (var tes = new TraceEventSession("TEMPSESSIONNAME", @"c:\temp\TEMPSESSIONNAME.etl") { StopOnDispose = false })
{
    tes.EnableProvider(ProviderExtensions.ProviderName<MicrosoftWindowsKernelProcess>());
    Thread.Sleep(timeToWait);
}

using (var tes = new TraceEventSession("TEMPSESSIONNAME", TraceEventSessionOptions.Attach))
{
    Thread.Sleep(timeToWait);
    tes.SetFileName(null);
    Thread.Sleep(timeToWait);

    Console.WriteLine("Done");
}

在这里,我想让我可以将会话转换为实时模式。但相反,我得到的文件包含了15秒的事件,而不是10秒。如果我使用 new TraceEventSession("TEMPSESSIONNAME", @"c:\temp\TEMPSESSIONNAME.etl", TraceEventSessionOptions.Create) 相反

以下情况似乎会导致文件停止写入:

using (var tes = new TraceEventSession("TEMPSESSIONNAME"))
{
    tes.EnableProvider(ProviderExtensions.ProviderName<MicrosoftWindowsKernelProcess>());
    Thread.Sleep(timeToWait);
}

但在这里,我必须重新启用所有的提供者,并根据文档“如果会话已经存在,它将关闭并重新打开(因此孤儿将在下次使用时被清理)”。我不明白关于孤儿的最后一部分。显然,一些事件可能发生在关闭、打开和订阅事件之间。这是否意味着我会输掉这些比赛,还是我会晚一点得到比赛?

我还在图书馆的文档中发现了以下内容:

在实时模式下,事件被缓冲,并且在事件的触发和会话的接收之间至少有一秒左右的延迟(通常为3秒)(以允许事件以多个事件的有效集群传递)

这是否使上述代码正常(好吧,除非发生了不可能的情况,并且出于某种原因,我的线程在创建实时会话和开始处理事件之间延迟了一秒以上)?

我可以结束会议,创建一个新的不同的会议,但我想我会错过一些活动。或者,我可以打开一个新的会话,然后关闭基于文件的会话,但可能会出现重复的事件。

我在网上找不到任何从基于文件的跟踪转移到实时跟踪的示例。

1 回复 | 直到 8 年前

Dina 8 年前

我设法联系了TraceEvent的作者,这是我得到的答案:

除了“自动关闭和重新启动”功能之外,这实际上是关于操作系统的问题(TraceEvent只是调用底层操作系统API)。仅供参考,关于孤儿的协议是,您的流程很容易退出,但会继续进行。这可能是你想要的,但往往不是,所以如果你这样做的话,就让常见的情况“只起作用” Create (这是默认设置),如果会话已经存在,它将关闭该会话(因为您要求创建一个新会话)。

实验当然是“真理”的试金石,但我坦白地说,我认为不寻常的组合通常是不正确的。

我的建议是保持简单。您需要打开一个新会话并关闭原来的会话。是的,你会得到重复的结果,但你可以过滤掉它们(毕竟它们是相同的时间戳)。

另一种可能性是使用 SetFileName 以其预期的方式(从一个文件到另一个文件)。这当然解决了文件大小增长的问题,而且通常是处理其他情况的好方法(毕竟,即使生成新文件,也可以开始处理和删除文件)。