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