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 回答