Creating a Performance Counter Log in Windows 7


To create a performance counter log, follow these steps:

1. Open Performance Monitor, and navigate to the Data Collector Sets node in the tree on the left.

2. Right-click User Defined, and navigate the menu to create a new data collector set.

3. Give the new set a name, select the Create Manually option button, and click Next.

4. Choose the Create Data Logs radio button, select the Performance Counter check box, and then click Next.

5. Click Next again it’s not time yet to select the performance counters, but you can customize the sampling time interval for the performance counter log.

6. Specify a directory where you want the logs to be saved, and then click Next.

7. Click Finish.

8. Right-click the new entry under User Defined in the tree on the left, and navigate the menu to create a new data collector.

9. Give the new data collector a name, select the Performance Counter Data Collector radio button, and then click Next.

10. Choose the performance counters you want to log, specify the interval at which log samples should be taken, and then click Next.

11. Select the Open Properties For This Data Collector check box and then click Finish. In the Properties dialog box, you can customize the performance counters and sample intervals and log files for the selected data collector set.

You can now customize the data collector further by interacting with it from the main panel of the Performance Monitor, or you can start the entire data collector set by clicking the green Play button in the toolbar. When your logs are ready, go back to the main Performance Monitor window and press Ctrl+L to choose the log file you want to view instead of focusing on the system’s current activity.

Alternatively, you can use the Reports node of the Performance Monitor tree and find your data collector set there. You can also use Performance Monitor to configure a performance counter alert, which executes a certain action whenever a threshold you set for a specific counter is met. When the alert occurs, you can choose to generate an event log entry, start a data collector set (a performance counter log), or even launch a custom task that will remedy the situation. By now you are probably wondering how you can read performance counter information programmatically and how you can expose performance counters from your own code.

Exposing performance counters from managed code is easy thanks to the System.Diagnostics namespace in the Microsoft .NET Framework. This namespace contains everything you need to provide diagnostic information from your application or even to consume performance counters exposed by the operating system and other applications.

For example, assume that you want to provide a performance counter category related to your online gaming service. This type of counter is very useful for server administrators when game servers are deployed to production. Some performance counters that might make sense are the number of connected players, the number of ongoing games, and any other performance statistics you might find appropriate.

All you need to do to expose this information using the performance counter mechanism is create a new performance counter category (using the PerformanceCounterCategory class), create the performance counters that you want to belong to this category (using the CounterCreationDataCollection and CounterCreationData classes), and then update the performance counters whenever necessary (using the PerformanceCounter class).

Unfortunately, creating a performance counter category is an operation that requires administrative privileges. To some extent, this makes sense because the diagnostic information that you can obtain using performance counters might have an effect on administrative decisions on a system, and thus modifying the performance counter catalog is an operation available only to administrators. This means that you will have to wrap category creation in a separate elevated process or create the category during your application installation.

The following code sample demonstrates how to initialize the performance counter category and the counters inside it (this will not work if you do not have administrative privileges), and how to update the performance counter information whenever a new event is generated in the system:

//Within the initialization procedure:
   if (PerformanceCounterCategory.Exists("EmployeePresence"))
   PerformanceCounterCategory.Delete("EmployeePresence");
   CounterCreationDataCollection coll = new CounterCreationDataCollection();
   CounterCreationData counter = new CounterCreationData(
   "# employees", "The number of signed-in employees",
   PerformanceCounterType.NumberOfItems32);
   coll.Add(counter);
   PerformanceCounterCategory.Create("EmployeePresence",
   "Information about employee presence",
   PerformanceCounterCategoryType.SingleInstance,
   coll);
   _signedInEmps = new PerformanceCounter("EmployeePresence",
   counter.CounterName, false);
   //Elsewhere in the system when an employee signs in:
   _signedInEmps.Increment();
 

Consuming performance counters from managed code is even easier, and it follows a symmetric path: if you have a PerformanceCounter object, you can read its value at any time by using the RawValue property (or other properties, which are suited for more advanced usage). The following code demonstrates how this property is used in a simple user interface (UI) application that is part of this article’s sample code:

   lblEmpCount.Text = _signedInEmps.RawValue.ToString();
   pbarEmps.Value = (int)_signedInEmps.RawValue;

Exposing and consuming performance counters from native code is not quite as easy and is outside the scope of this article. You can find samples and documentation on the Microsoft Developer Network (MSDN) Web site at http://msdn.microsoft.com/enus/library/aa373209.aspx.

Note The Win32 performance counter API (also called Performance Data Helpers, or PDH) is complicated, and we have no room to cover it here. Among other things, you can use the PDH interfaces to read performance counter information, configure performance counter logs, parse and aggregate performance counter logs, and access lots of other functionality that is not available to managed code.

In closing, performance counters are a powerful monitoring mechanism that ships with Windows. Analyzing performance information, generating logs of monitoring activity, and distributing alerts whenever a threshold is breached are just some of the things performance counters can help you with.

Windows Management Instrumentation

Windows Management Instrumentation (WMI) is a built-in command and control (C&C) infrastructure for Windows. Using WMI, C&C providers can expose diagnostic information, run-time state, and events to C&C consumers, which can obtain this information in real time and invoke provider methods to modify the state of the system. Essentially, WMI is a fullblown distributed system infrastructure, geared toward command and control scenarios.

Unlike performance counters, which can be used to expose only read-only numeric information within a limited hierarchical form, WMI objects can use standard programming techniques such as inheritance, composition (aggregation), complex collections, events, and overridden methods. This richness is accessible from almost every programming language for Windows because WMI is COM-based and DCOM-based even scripting languages can use WMI objects through late-bound COM invocations. Additionally, the emerging Windows PowerShell scripting platform for IT professionals (included with Windows 7) has special commands for interacting with WMI objects.

Here are some of the tasks made possible by WMI. Some tasks on this list are very difficult to perform without WMI, and other tasks are simply impossible without it.

In addition to standard programming interfaces that allow you to create WMI objects, retrieve their properties, and invoke their methods, a specialized query language called WMI Query Language (WQL) is available that can be used to retrieve specific objects. For example, the following WQL statement retrieves all Notepad processes on the system:

   SELECT * FROM Win32_Process WHERE ProcessName='Notepad.exe'

Writing a WMI consumer means interacting with the WMI COM interfaces to retrieve objects, register for events, handle event notifications, and invoke WMI provider methods.

In unmanaged code, this interaction is done directly against the WMI interfaces, such as IWbemServices, and an explanation of how to do this is outside the scope of this article. (See http://msdn.microsoft.com/en-us/library/aa389761.aspx for more information.) In managed code, you use the System.Management namespace, specifically classes such as ManagementObject, ManagementQuery, and ManagementEventWatcher.

Legal Disclaimer

Our website is not responsible for the information contained by this article. Webworldarticles.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.


This article was sent to us by: Ramon H. at 01282010

Related Articles

1. Handling the WM GESTURE Message
To work with gestures, you’ll need to handle the WM_GESTURE messages that are sent to your application. If you are a Win32 programmer, you can check for WM_GESTURE ...

2. How Multitouch Works in Windows 7
New hardware and API elements in the Windows 7 operating system provide applications the ability to receive and handle touch and multitouch input. This capability enables...

3. Organize My Data Libraries in Windows 7
This article details the new functionality offered by Windows 7 Libraries. We’ll review the Windows Explorer changes that promote the new user experience that Libra...

4. Changes Made to Windows Explorer in Windows 7
Changes Made to Windows Explorer in Windows 7 In Windows 7, Libraries address the problem of users’ data being stored all over the PC by allowing users to...

5. Make Your Windows 7 Application Library Aware
Libraries under the Hood Now that we have a better understanding of what libraries represent and how users as well as developers can benefit from them, let&rsqu...

6. Working with the Shell Namespace in Windows 7
Working with the Shell Namespace Before we dive into the Shell Libraries programming model, we need to understand how the Windows Shell works. The Windows Shell...

7. Windows 7 Multitouch Programming Models
Windows 7 Multitouch Programming Models The Windows 7 multitouch platform enables you to build touch-aware applications. Keep in mind that with time, the amount...