windows - 实时记录

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

5年前关闭。




Improve this question




我有一个应用程序，它有一个循环，它是“调度程序”的一部分，它始终运行并且是应用程序的核心。非常像游戏循环，只是我的应用程序是 WPF 应用程序，而不是游戏。自然地，应用程序会在许多点进行日志记录，但调度程序会进行一些敏感的监控，有时仅从日志中无法判断可能出错的地方(错误并不意味着异常)或当前状态。

由于调度程序的内部循环以较短的间隔运行，因此您无法在其中执行基于文件 I/O 的日志记录(或使用事件查看器)。首先，您需要实时查看它，其次日志文件的大小会非常快地增长。所以我在想办法将这些数据实时显示给用户，我考虑了一些事情:

在 UI 中实时显示数据

使用 AllocConsole/WriteConsole 在控制台中显示此信息

使用不同的控制台应用程序来显示此信息，使用管道或其他 IPC 技术在调度程序和控制台应用程序之间进行通信

使用 Windows 的性能监视器并以某种方式向它提供此信息

东运

在 UI 中显示会有问题。首先，它没有与我为我的应用程序设计的 UI 集成，而且我不想仅仅为了这个而使 UI 复杂化。这种诊断只会很少发生。其次，会有一些重要的数据保护，因为调度程序有它自己的线程。

一个单独的控制台窗口可能会起作用，但我仍然担心它是否阈值不高。分配我自己的控制台，因为这是一个 Windows 应用程序，可能比不同的控制台应用程序 (3) 更好，因为我不需要担心 IPC 通信和非阻塞通信。但是，用户可以关闭我分配的控制台，在这种情况下会出现问题。使用单独的过程，您不必担心。

假设有一个用于性能监视器的 API，它不会与我的应用程序集成得很好，也不会对用户显而易见。使用 ETW 也不能解决任何问题，只是一个随机的想法，我仍然需要以某种方式显示这些信息。

其他人怎么想，我会错过其他方式吗？

Answer 1

恭敬地 - Adrian K 和 Dima 的答案都不正确。正确答案是使用 Event Tracing For Windows (ETW)。这是我们用于所有 Windows 登录的。它非常坚固，性能非常好。例如，W7 在许多操作系统事件上记录 ETW 事件 - 一直 - 包括处理器上下文切换。曾经使用过 W7 中的性能监视器吗？它正在消耗内核中的 ETW 事件。

我建议您使用 ETW 完成所有日志记录。为什么？几个原因:

它无处不在

您可以在正在运行的进程中启用禁用日志记录。无需重新启动进程。 (是的，其他记录器会这样做，但有些不会)。

它旨在包含在运输代码中。

记录事件保证是非阻塞的:它不会导致“等待”。

我们提供了许多用于 ETW 跟踪处理的工具。最值得注意的是 XPERF 工具(link、link、link)

使用 ETW 事件检测性能路径的一大好处是，可以使用 XPERF 工具将事件与内核事件整合在一起。

编写一个“监视”应用程序来监视组件中的 ETW 事件也很容易。我有一个用于我们的组件之一，它只是将事件显示到控制台。

我强烈建议不要尝试编写自己的高性能日志系统。要做好这点很有挑战性，但就性能和可靠性而言。 Windows ETW 系统非常强大且性能非常好。