Question

我需要在启动期间记录跟踪事件，因此我使用所有必需的提供程序配置AutoLogger。但是当我的服务/进程启动时，我想切换到实时模式，以便文件不会爆炸。我正在使用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");
}

这里我想让我可以将会话转移到实时模式。但相反，我收到的文件包含15s期间而不是10s期间的事件。如果我改用new TraceEventSession("TEMPSESSIONNAME", @"c:\temp\TEMPSESSIONNAME.etl", TraceEventSessionOptions.Create)，也会发生同样的情况。

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

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

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

我还在库的文档中找到了以下内容：

在实时模式中，事件被缓冲，事件触发和会话接收之间至少有一秒左右的延迟（通常为3秒）（允许事件以多个有效的块形式传递）事件）

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

我可以关闭会话并创建一个新的不同但我认为我会错过一些事件。或者我可以打开一个新会话，然后关闭基于文件的会话，但之后我可能会收到重复的事件。

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

Answer 1

我设法联系了TraceEvent的作者，这就是我得到的答案：

除了自动关闭和重启＆＃39;功能，它实际上是关于操作系统的问题（TraceEvent只是调用底层的OS API）。仅供参考，关于孤儿的交易是，您的流程退出是很容易的，但是让会话继续进行。这可能是你想要的，但通常不是，所以要使常见的情况“只是工作”。如果你Create（这是默认值），它将关闭一个会话（如果它已经存在）（因为你要求一个新会话）。

实验当然是“真理”的试金石。但我坦率地期待不寻常的组合只是工作通常是不正确的。

我的建议是保持简单。您需要打开一个新会话并关闭原始会话。是的，你最终会得到重复，但是你可以将它们过滤掉（毕竟它们是IDENTICAL时间戳）。

另一种可能性是以预期的方式使用SetFileName（从一个文件到另一个文件）。这肯定解决了文件大小增长的问题，并且通常是处理其他方案的好方法（毕竟，即使在生成新文件时，您也可以启动处理并开始删除文件）。

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

1 个答案: