从基于文件的跟踪会话转移到实时会话
Moving from file-based tracing session to real time session
我需要在启动期间记录跟踪事件,因此我使用所有必需的提供程序配置了一个 AutoLogger。但是当我的 service/process 启动时,我想切换到实时模式,这样文件就不会爆炸。
我正在使用 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);
}
但这里我必须根据文档重新启用所有提供程序 "if the session already existed it is closed and reopened (thus orphans are cleaned up on next use)"。我不明白关于孤儿的最后一部分。显然,某些事件可能会在关闭、打开和订阅事件之间发生。这是否意味着我将失去这些事件,或者我会得到后者?
我还在库的文档中找到了以下内容:
In real time mode, events are buffered and there is at least a second or so delay (typically 3 sec) between the firing of the event and the reception by the session (to allow events to be delivered in efficient clumps of many events)
这是否使上面的代码正常(好吧,除非发生不可能的事情并且由于某种原因我的线程在创建实时会话和开始处理事件之间延迟了一秒以上)?
我可以关闭会话并创建一个新的不同的会话,但我想我会错过一些事件。或者我可以打开一个新会话,然后关闭基于文件的会话,但我可能会得到重复的事件。
我在网上找不到任何从基于文件的跟踪转移到实时跟踪的示例。
我设法联系到了 TraceEvent 的作者,这是我得到的答案:
关于'auto-closing and restarting'特征的异常,确实是关于OS的问题(TraceEvent只是调用底层的OSAPI)。仅供参考,关于孤儿的交易是您的进程很容易退出但让会话继续进行。这可能是你想要的,但通常不是,所以如果你做Create
(这是默认设置),那么常见的情况是'just work',如果它已经存在,它将关闭会话(因为你要了一个新的)。
实验当然是 'truth' 的试金石,但坦率地说,我希望不寻常的组合能够正常工作通常是不正确的。
我的建议是保持简单。您需要打开一个新会话并关闭原始会话。是的,你最终会得到重复的,但你可以过滤掉它们(毕竟它们是相同的时间戳)。
另一种可能性是以预期的方式使用 SetFileName
(从一个文件到另一个文件)。这当然可以解决您的文件大小增长问题,并且通常是处理其他情况的好方法(毕竟您可以开始处理并开始删除文件,即使正在生成新文件)。
我需要在启动期间记录跟踪事件,因此我使用所有必需的提供程序配置了一个 AutoLogger。但是当我的 service/process 启动时,我想切换到实时模式,这样文件就不会爆炸。 我正在使用 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);
}
但这里我必须根据文档重新启用所有提供程序 "if the session already existed it is closed and reopened (thus orphans are cleaned up on next use)"。我不明白关于孤儿的最后一部分。显然,某些事件可能会在关闭、打开和订阅事件之间发生。这是否意味着我将失去这些事件,或者我会得到后者?
我还在库的文档中找到了以下内容:
In real time mode, events are buffered and there is at least a second or so delay (typically 3 sec) between the firing of the event and the reception by the session (to allow events to be delivered in efficient clumps of many events)
这是否使上面的代码正常(好吧,除非发生不可能的事情并且由于某种原因我的线程在创建实时会话和开始处理事件之间延迟了一秒以上)?
我可以关闭会话并创建一个新的不同的会话,但我想我会错过一些事件。或者我可以打开一个新会话,然后关闭基于文件的会话,但我可能会得到重复的事件。
我在网上找不到任何从基于文件的跟踪转移到实时跟踪的示例。
我设法联系到了 TraceEvent 的作者,这是我得到的答案:
关于'auto-closing and restarting'特征的异常,确实是关于OS的问题(TraceEvent只是调用底层的OSAPI)。仅供参考,关于孤儿的交易是您的进程很容易退出但让会话继续进行。这可能是你想要的,但通常不是,所以如果你做Create
(这是默认设置),那么常见的情况是'just work',如果它已经存在,它将关闭会话(因为你要了一个新的)。
实验当然是 'truth' 的试金石,但坦率地说,我希望不寻常的组合能够正常工作通常是不正确的。
我的建议是保持简单。您需要打开一个新会话并关闭原始会话。是的,你最终会得到重复的,但你可以过滤掉它们(毕竟它们是相同的时间戳)。
另一种可能性是以预期的方式使用 SetFileName
(从一个文件到另一个文件)。这当然可以解决您的文件大小增长问题,并且通常是处理其他情况的好方法(毕竟您可以开始处理并开始删除文件,即使正在生成新文件)。