我正在使用一个由多个应用程序和服务组成的系统，几乎都使用 SQL 数据库。
Windows 服务在不同的时间做不同的事情，我想跟踪它们。这意味着在某些已部署的系统上，我们看到机器在 CPU 上运行得很高，我们看到 sql 进程运行得很高，但我们不能确定哪个服务负责它。
我想知道性能计数器是否适合这项工作。
基本上我希望能够在某个时刻看到哪个服务唤醒并正在处理某些东西。
在我看来，我最终可以得到一个perfcounter只有值 0 或 1 的每个服务来显示它是否正在做某事，但这似乎不是perfcounters.
性能计数器是否合适？
你认为我应该以不同的方式跟踪这个吗？
如果您的监控框架/方法已经以监控性能计数器为中心，那么这是一种可行的方法。
就我个人而言，我发现需要更详细的工具才能真正了解我的服务中发生的事情（尽管这可能与我的服务的性质有关）。
我使用.NET Logging Framework，因为它很简单，可以写入多个目标，包括日志文件、事件日志和 TCP 套接字（我有一个简单的监视器，它监听每个应用服务器的日志套接字并实时显示发生了什么）。
性能计数器很有吸引力，因为它们非常轻巧，但正如您所说，它们只允许您捕获数值。当然，您可以记录大量不同类型的值，例如平均值、增量和总计，但它们必须是数字。
如果您需要更多信息，则必须求助于其他类型的仪器。就您而言，听起来您的需求更多地朝着这个方向发展。
如果您的服务不会过于频繁地唤醒和挂起自己，那么听起来像自定义事件日志的信息消息可能是个好主意。如果您期望有大量此类事件，请为应用程序创建自定义事件日志，以免淹没常规应用程序事件日志。
如果您希望检测为正常事件日志生成过多数据，.NET Trace API 将是一个更好的选择。您可以根据 app/web.config 配置您的应用程序以跟踪或不跟踪，但更改将需要重新启动应用程序。如果您只想使用工具进行故障排除，这是一个不错的选择，但否则会生成太多数据，或者如果跟踪本身会过多地降低性能。Tracing API 的另一个好处是您可以在多个级别上进行 Trace，因此即使您编写了非常冗长的 Trace 代码，如果您启用详细跟踪，您也只会看到详细的跟踪数据。这使您可以更好地控制正在跟踪的内容。
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