我正在使用一個由幾個應用程序和服務組成的系統，幾乎所有的系統都使用SQL數據庫。使用性能計數器跟蹤Windows服務
Windows服務在不同的時間做不同的事情，我想跟蹤它們。這意味着在某些已部署的系統上，我們看到機器在CPU上運行得很高，我們看到sql進程運行得很高，但我們無法確定哪個服務對它負責。
我不知道性能計數器是否適合這份工作。
基本上我希望能夠在某個時刻看到哪些服務被喚醒並正在處理某些事情。
在我看來，我最終可能會得到一個perfcounter，每個服務只有值0或1才能顯示它是否正在執行某些操作，但這看起來不像perfcounters的正常用法。
性能計數器是否合適？
你認爲我應該用不同的方式跟蹤這個嗎？
如果您的監控框架/方法已經圍繞着監控性能計數器，這是一種可行的方法。
就我個人而言，我發現必須更詳細的儀器才能真正瞭解我的服務中發生了什麼（儘管也許這與我的服務的性質有關）。我使用.NET Logging Framework，因爲它很簡單，可以寫入多個目標，包括日誌文件，事件日誌和一個TCP套接字（我有一個簡單的監視器，它監聽每個應用服務器的日誌套接字並實時顯示我，時間發生了什麼）。
性能計數器很吸引人，因爲它們非常輕便，但正如您所說，它們只允許您捕獲數值。當然，您可以記錄多種不同類型的值，例如平均值，增量和總計，但必須是數字。
如果您需要更多的信息，那麼您必須使用其他類型的儀器。就你而言，這聽起來像你的需要在這個方向更多。
如果您的服務沒有喚醒並且經常自行暫停，那麼聽起來好像是對自定義事件日誌的信息消息可能是個好主意。如果您期望這些應用程序有相當數量的應用程序以防止泛洪常規應用程序事件日誌，請爲應用程序創建自定義事件日誌。
如果您希望檢測工具爲正常事件日誌生成太多數據，.NET Trace API將是更好的選擇。您可以根據app/web.config配置您的應用程序以跟蹤或不跟蹤，但更改將需要重新啓動應用程序。如果您只希望使用檢測工具進行故障排除，那麼這是一個不錯的選擇，但否則會產生太多數據或者跟蹤本身會降低性能。跟蹤API的另一個好處是，您可以在多個級別上跟蹤，因此即使您編寫了非常詳細的跟蹤代碼，如果啓用詳細跟蹤，也只能看到詳細的跟蹤數據。這樣可以更好地控制正在追蹤的內容。
Eric J有一個很好的觀點。我想如果你真的想要捕捉「時間表現」的表現，你必須使用其他類型的日誌記錄，並使用啓動和停止時間日誌。我個人喜歡log4net，雖然第一次配置可能很痛苦
我們將使用Log4Net來保持計時，因爲我們已經將它用於跟蹤和錯誤記錄。 – pauloya 2009-10-05 16:31:56