2009-09-13 51 views
5

我正在使用一个由几个应用程序和服务组成的系统,几乎所有的系统都使用SQL数据库。使用性能计数器跟踪Windows服务

Windows服务在不同的时间做不同的事情,我想跟踪它们。这意味着在某些已部署的系统上,我们看到机器在CPU上运行得很高,我们看到sql进程运行得很高,但我们无法确定哪个服务对它负责。

我不知道性能计数器是否适合这份工作。

基本上我希望能够在某个时刻看到哪些服务被唤醒并正在处理某些事情。

在我看来,我最终可能会得到一个perfcounter,每个服务只有值0或1才能显示它是否正在执行某些操作,但这看起来不像perfcounters的正常用法。

性能计数器是否合适?

你认为我应该用不同的方式跟踪这个吗?

回答

4

如果您的监控框架/方法已经围绕着监控性能计数器,这是一种可行的方法。

就我个人而言,我发现必须更详细的仪器才能真正了解我的服务中发生了什么(尽管也许这与我的服务的性质有关)。我使用.NET Logging Framework,因为它很简单,可以写入多个目标,包括日志文件,事件日志和一个TCP套接字(我有一个简单的监视器,它监听每个应用服务器的日志套接字并实时显示我,时间发生了什么)。

+0

我们将使用Log4Net来保持计时,因为我们已经将它用于跟踪和错误记录。 – pauloya 2009-10-05 16:31:56

1

性能计数器很吸引人,因为它们非常轻便,但正如您所说,它们只允许您捕获数值。当然,您可以记录多种不同类型的值,例如平均值,增量和总计,但必须是数字。

如果您需要更多的信息,那么您必须使用其他类型的仪器。就你而言,这听起来像你的需要在这个方向更多。

如果您的服务没有唤醒并且经常自行暂停,那么听起来好像是对自定义事件日志的信息消息可能是个好主意。如果您期望这些应用程序有相当数量的应用程序以防止泛洪常规应用程序事件日志,请为应用程序创建自定义事件日志。

如果您希望检测工具为正常事件日志生成太多数据,.NET Trace API将是更好的选择。您可以根据app/web.config配置您的应用程序以跟踪或不跟踪,但更改将需要重新启动应用程序。如果您只希望使用检测工具进行故障排除,那么这是一个不错的选择,但否则会产生太多数据或者跟踪本身会降低性能。跟踪API的另一个好处是,您可以在多个级别上跟踪,因此即使您编写了非常详细的跟踪代码,如果启用详细跟踪,也只能看到详细的跟踪数据。这样可以更好地控制正在追踪的内容。

1

Eric J有一个很好的观点。我想如果你真的想要捕捉“时间表现”的表现,你必须使用其他类型的日志记录,并使用启动和停止时间日志。我个人喜欢log4net,虽然第一次配置可能很痛苦