An interesting alternative to the instance-centric approach, outlined above, is using the Performance Monitoring provider as a property provider. Just as it is the case with the instance provider, to make the property provider work, you have to define the WMI classes to represent the performance data. Additionally, instances of these classes also have to be defined manually, since the property provider is not capable of returning the instance-level data to its clients. Consider the following sample MOF code:

class PerfMonProp_TCP {
[Key]
string KeyProp;
real32 ConnectionsEstablished;
real32 ConnectionsActive;
real32 ConnectionsPassive;
};
[DYNPROPS]
instance of PerfMonProp_TCP {
KeyProp = "tcp1";
[PropertyContext("local|TCP|Connections Established"),
Dynamic, Provider("PerformanceMonitorPropProvider")]
ConnectionsEstablished;
[PropertyContext("local|TCP|Connections Active"),
Dynamic, Provider("PerformanceMonitorPropProvider")]
ConnectionsActive;
[PropertyContext("local|TCP|Connections Passive"),
Dynamic, Provider("PerformanceMonitorPropProvider")]
ConnectionsPassive;
};

The class definition for PerfMonProp_TCP is fairly straightforward and does not include any special qualifiers. The class has a key property KeyProp, although it is not, strictly speaking, necessary. Since properties of this class refer to global performance counters, the class may as well be marked as a singleton.

The instance definition is a bit more interesting. First, the instance is decorated with the DYNPROPS qualifier, which simply indicates that the instance is to house the values, backed by a property provider. The KeyProp property is initialized to an arbitrary value to guarantee the uniqueness of the instance identity. Finally, each of the instance's properties is marked with the already familiar PropertyContext qualifier. However, rather then simply referring to the display names of the associated performance counters, these PropertyContext qualifiers include the machine and performance object names as part of their initialization strings. This information is necessary in order for the property provider to bind to a correct performance object for each property. Additionally, each property is decorated with the Dynamic qualifier to indicate that a property provider backs it, and with the Provider qualifier, which refers to the proper provider registration entry.

Using the PerfMonProp_TCP class is no different than using the previously defined PerfMon_TCP class. There is, however, an interesting twist. Since the performance data is provided at the property level rather than the instance level, the WMI class definition no longer has to correspond to a single performance object. In fact, it is perfectly legitimate to define a class that combines the performance counters from multiple categories into a single package:

class PerfMonProp_Combo {
[Key]
string KeyProp;
real32 ConnectionsEstablished;
real32 AvailableBytes;
};
[DYNPROPS]
instance of PerfMonProp_Combo {
KeyProp = "combo1";
[PropertyContext("local|TCP|Connections Established"),
Dynamic, Provider("PerformanceMonitorPropProvider")]
ConnectionsEstablished;
[PropertyContext("local|Memory|Available Bytes"),
Dynamic, Provider("PerformanceMonitorPropProvider")]
AvailableBytes;
};

This is certainly convenient because the management application is afforded the luxury of defining its single performance monitoring class, which includes all counters of interest. Unfortunately, there does not appear to be a way to retrieve nonglobal performance counters with the property provider. For instance, it is not possible to alter the definition of the WMI class above to refer to, say, the "% Processor Time" counter for CPU 0.

Source of Information : Dot NET System Management Services - Apress

0 comments


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner