3

我有一个应用程序，它有一个循环，是“调度程序”的一部分，它始终运行并且是应用程序的核心。很像一个游戏循环，只是我的应用程序是一个 WPF 应用程序，它不是一个游戏。自然地，应用程序会在很多点上进行日志记录，但调度程序会进行一些敏感的监控，有时仅从日志中就不可能知道可能出了什么问题（我说的错误不是指异常）或当前状态。

因为调度程序的内部循环运行间隔很短，所以您不能在其中执行基于文件 I/O 的日志记录（或使用事件查看器）。首先，您需要实时观看，其次日志文件的大小会增长得非常快。所以我正在考虑如何将这些数据实时显示给用户，我考虑了一些事情：

  • 在 UI 中实时显示数据
  • 使用 AllocConsole/WriteConsole 在控制台中显示此信息
  • 使用不同的控制台应用程序来显示此信息，使用管道或其他 IPC 技术在调度程序和控制台应用程序之间进行通信
  • 使用 Windows 的性能监视器并以某种方式将这些信息提供给它
  • ETW

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

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

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

别人怎么想，会不会有其他我错过的方式？

4

2 回答 2

9

尊敬的 - Adrian K 和 Dima 的答案都不正确。正确的答案是使用Windows 事件跟踪(ETW)。这是我们用于所有登录 Windows 的内容。它非常强大且性能非常好。例如，W7 在许多操作系统事件上记录一个 ETW 事件 - 一直 - 包括处理器上下文切换。曾经在 W7 中使用过性能监视器吗？它正在使用来自内核的 ETW 事件。

我建议您使用 ETW进行所有日志记录。为什么？几个原因：

  1. 它无处不在
  2. 您可以在正在运行的进程中启用禁用日志记录。无需重新启动进程。（是的，其他记录器会这样做，但有些不会）。
  3. 它设计用于包含在运输代码中。
  4. 记录事件保证是非阻塞的：它不会导致“等待”。
  5. 我们为 ETW 跟踪处理提供了很多工具。最值得注意的是 XPERF 工具（链接、链接、链接）

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

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

我强烈建议不要尝试编写自己的高性能日志记录系统。要想做得好，这是一项挑战，但在性能和可靠性方面。Windows ETW 系统超级强大且性能非常好。

于 2010-04-24T16:29:58.003 回答
0

回到基础 - 单独关注。

我通常的解决方案是使用 Microsoft Enterprise Libraries 来处理实际的日志记录；我会使用数据库作为存储库，然后您可以从任何应用程序（您现有的应用程序或完全独立的应用程序）随意查询它。

我喜欢 MS Ent Libs 的一点是您可以将它们配置为记录到各种存储库类型。如果需要，您可以扩展它们；我不确定您是否要针对性能/执行限制进行异步工作。

我更喜欢记录到数据库，因为它提供了良好的控制水平：它很容易查询并且相当容易管理数据。让 sia dthat Ent Libs 确实允许基于滚动文件的日志记录 - 这将帮助您管理文件大小 - 但使用 Db 会比读取文件更快。

我想这归结为“实时”的意思，即记录到数据库是否足够快。- 对计算机的实时性与对人的实时性有很大不同。

您可以登录到内存，然后异步迭代这些日志条目并将它们提交到日志存储 (DB)。对于报告，您可以使用内存中的副本来显示“当前”状态，并在更长的时间/更远的过去参考数据库。

于 2010-04-19T04:40:16.593 回答