使用性能计数器跟踪 Windows 服务
我正在使用一个由多个应用程序和服务组成的系统，几乎全部使用 SQL 数据库。
Windows 服务在不同的时间做不同的事情，我想跟踪它们。这意味着在某些已部署的系统上，我们看到机器的 CPU 运行较高，我们看到 sql 进程运行较高，但我们无法确定哪个服务负责它。
我想知道性能计数器是否适合这项工作。
基本上我希望能够在某个时刻看到哪个服务醒来并正在处理某些内容。
在我看来，我最终可能会得到一个 perfcounter ，每个服务只有值 0 或 1 来显示它是否正在做某事，但这似乎不是 的正常用法。代码>性能计数器。
性能计数器合适吗？
你认为我应该以不同的方式追踪这个问题吗？
I'm working with a system that consists of several applications and services, almost all using a SQL database.
Windows services do different things at different times, and I would like to track them. Meaning that on some deployed systems we see the machine running high on CPU, we see that the sql process is running high, but we can't be sure about which service is responsible for it.
I wonder if Performance Counters are good for this job.
Basically I would like to be able to see at a certain moment which service woke up and is processing something.
It seems to me that I can end up having a perfcounter that only has the value 0 or 1 for each service to show if it is doing something, but this doesn't seem like a normal usage for perfcounters.
Are performance counters suitable?
Do you think I should track this in a different way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您的监控框架/方法已经以监控性能计数器为中心，那么这是一种可行的方法。
就我个人而言，我发现需要更详细的工具才能真正了解我的服务中发生的情况（尽管这可能与我的服务的性质有关）。
我使用 .NET 日志框架，因为它很简单，并且可以写入多个目标，包括日志文件、事件日志和 TCP 套接字（我有一个简单的监视器，它监听每个应用程序服务器的日志记录套接字并实时显示正在发生的情况）。
If your monitoring framework/approach already centers around monitoring performance counters, this is a viable approach.
Personally I find more detailed instrumentation necessary to really understand what's happening in my services (though maybe that has to do with the nature of my services).
I use .NET Logging Framework because it's simple and can write to multiple targets including log files, the event log, and a TCP socket (I have a simple monitor that listens on the logging socket for each app server and shows me in real-time what's happening).
性能计数器很有吸引力，因为它们确实很轻量级，但正如您所说，它们只允许您捕获数值。当然，您可以记录许多不同类型的值，例如平均值、增量和总计，但它们必须是数字。
如果您需要更多信息，则必须求助于其他类型的仪器。就您而言，听起来您的需求更多地朝着这个方向发展。
如果您的服务不经常唤醒并挂起自己，听起来向自定义事件日志发送信息消息可能是个好主意。如果您期望有相当数量的自定义事件日志，请为应用程序创建一个自定义事件日志，以免淹没常规应用程序事件日志。
如果您希望检测为正常事件日志生成过多数据，则 .NET Trace API 将是更好的选择。您可以根据 app/web.config 将应用程序配置为跟踪或不跟踪，但更改需要重新启动应用程序。如果您只想使用仪器进行故障排除，但它会生成太多数据，或者跟踪本身会严重降低性能，那么这是一个不错的选择。 Tracing API 的另一个好处是您可以在多个级别上进行跟踪，因此即使您非常详细地编写了 Trace 代码，如果您启用了详细跟踪，您也只会看到详细的跟踪数据。这使您可以更好地控制所跟踪的内容。
Performance Counters are attractive because they are really lightweight, but as you say, they only allow you to capture numeric values. Sure, there's a slew of different types of values you can record, such as averages, deltas and totals, but they have to be numbers.
If you need more information than that, you must resort to some other type of instrumentation. In your case, it sounds like your need goes more in that direction.
If your services don't wake up and suspend themselves too often, it sounds like informational message to a custom event log might be a good idea. Create a custom event log for the application if you expect a fair amount of these so as to not flood the regular Application event log.
The .NET Trace API will be a better option if you expect the instrumentation to generate too much data for the normal event log. You can configure your application(s) to trace or not based on app/web.config, although a change will require a restart of the app. This is a good option if you only wish to use the instrumentation for troubleshooting, but it otherwise generates too much data or if tracing itself degrades performance too much. Another good thing about the Tracing API is that you can Trace on multiple levels, so even if you have written code to Trace very verbosely, you will only see that verbose trace data if you enable verbose tracing. That gives you better control of just what is being traced.
Eric J 有一个很好的观点。我认为如果您确实想捕获“计时”性能，则必须使用其他类型的日志记录并使用开始和停止时间日志。我个人喜欢 log4net，尽管第一次配置可能会很痛苦
Eric J has a good point. I think if you really want to capture "timing" performance you'll have to use some other sort of logging and use start and stop time logs. I personally like log4net though it can be a pain to configure the first time around