Since we know where our desired performance collection data can be found, we can dive into PowerShell to access it. We can see that this rule targets the class “Windows Server 2012 R2 Operating System”.
#Powershell get monitor model windows
In this screenshot, you can see the rule I’ve selected (“Processor Information % Processor Time Total Windows Server 2012 R2”) and the Target of that rule. If we search for performance collection rules which capture that counter, we’ll find that there are several – one for each version of the Windows operating system. Let’s use an example of the “% Processor Time” counter. To collect this information, all that is needed is to look at the configuration of the performance collection rule within SCOM and note the rule’s target. The short takeaway here is that the first step to access performance data with PowerShell is to know the type of class where the data will be stored. One doesn’t need to worry that logical disk performance counters on a computer with multiple disks will overlap with one another because each data set is associated with a specific disk, not with the computer hosting that disk. When the collected performance data is stored in SCOM, it is associated with the instance of the object which spawned it. What this means is that SCOM’s performance collection workflows all target specific object types. SCOM won’t attempt to monitor Exchange processes on a server where Exchange is not installed – the “Exchange Server” object won’t be present, so monitoring workflows targeting that “Exchange Server” object won’t run, as there will be no target for them to run against. This model allows SCOM to target its monitoring workflows at the specific object types relevant to those workflows, rather than targeting application-specific workflows at computers regardless of whether or not that application is present. For example, a single computer will be seen by SCOM as a “computer” object, an “operating system” object, a collection of “logical disk” objects, and more. When SCOM monitors a computer, it doesn’t see the computer as a flat plane, but rather as a collection of different types of objects. The key to remember is that SCOM is an application-focused monitoring program. This is no different from accessing the data via a view, though it does require understanding where SCOM stores performance data. In order to access performance data with PowerShell, the first prerequisite is knowing which type of object, or class, is going to contain the desired performance data.
#Powershell get monitor model how to
In this post, we’ll provide examples on how to access performance data within SCOM via PowerShell. The means to get the performance data does require a light understanding of SCOM’s data model, but no moreso than building views or reports. Using PowerShell, we can also access any of the performance data stored within SCOM’s operational database for use in scripted processes, custom monitors, or more. For the majority of users, accessing this data via the console and reports are all that is needed. Being able to view historical and trending performance data can be very useful when investigating system issues or justifying additional purchases. This collection allows a SCOM operator to access and compare performance data from monitored systems within the SCOM console’s views and reports. One of the most useful elements of SCOM’s monitoring is the collection and storage within SCOM of monitored system’s performance data. This post describes how to access performance data from SCOM via PowerShell.
0 kommentar(er)
