Written by:
Monday, November 09, 2009 1:46:29 PM 

This is a step-by-step guide in multiple parts:

Part 1 will cover the Probe Actions Module Types: Part 1 is available on SCC or on code4ward 
Part 2 will be about creating a Data Source: Part 2 is available on SCC or on code4ward
Part 3 will cover creating a Monitor Type: Part 3 is available on SCC or on code4ward
Part 4 will cover the Unit Monitor itself

As always be careful with the samples provided here. Always use a test environment first to try those examples!

Will only work with OpsMgr 2007 R2 !

Part 4: Unit Monitor

Selecting a Target

In this demo, I will target the Root Management Server class to keep it simple. This way we do not have to go through all the steps to disable the monitor and enable it with an override, etc. Another way to find an appropriate target is to discover one. The environment we are working in, admins can configure their own monitoring by just providing some registry keys and values. This registry information is discovered, an instance of a custom class (which is hosted on a computer) will be created and most properties of this class are holding the configuration values for the monitor. My friend Tenchuu mentioned to publish some blog posts about PowerShell discovery and he also wants to blog about this concept.

Creating the Unit Monitor

	Change to the Health Model space and select Monitors in the tree. Right-click into the Monitors pane and select New->Custom Unit Monitor I specified as ID: code4ward.Sample.PowerShellMonitor.Monitor.FileContentCheck Display Name is: File Content Check Monitor As Target choose Browse all classes…
	As I mentioned earlier, for this demo we use the RMS. In production environments you do not want to do that. Always use own custom classes or target your monitors according to the best practice white papers and create appropriate overrides to enable your monitor for a group of instances. As Parent Monitor we will select System.Health.AvailabilityState
	In the Configuration tab we will click on Browse for a type… and select our monitor type we created in part 3 of this series.
	When we selected our type you will be presented with a generic configuration UI. These are the config values we defined in the monitor type. We will provide some hardcoded values in here (see screenshot). In this example we will set Debug to false by default but for troubleshooting you could create an override for a specific instance or a group of instances to enable debugging. As you may remember, we allowed the override of the debug parameter in our monitor type. You can also access your target’s properties using the fly-out button. So let’s pretend you discover your own class with a property called LogFile, you could target this monitor to that class and pull in the LogFile parameter into the File config value to dynamically fill in your file to monitor.
	The next tab looks familiar and provides to UI to define the health state conditions. The column Monitor Condition will show you the names/IDs we provided in our monitor type.
	As usual you can configure the alerting for the monitor. Notice that we pull out the MessageText value from our property bag. We will skip the Diagnostic and Recovery task for now. This is because we first need to successfully save the monitor before we actually can add a recovery or diagnostic tab. I’m not sure if this is by design or a bug, but when you try to do it before you actually saved the monitor you cannot select the parent monitor in the task configuration (because it just doesn’t exist yet).
	In the Options tab we adjust the Category to AvailabiliytHealth Usually you want to set Enabled to false by default and create an override to enable this monitor but in this case we leave it enabled because we targeted the RMS for this demo. Now let’s hit OK and reopen the monitor we just created.
	Change to the Diagnostic and Recovery tab, click on Add… and select Diagnostic for critical health state Specify a unique ID for that task like: code4ward.Sample.PowerShellMonitor.Diagnostic.FileContentCheck We name the task: Execute File Content Check Here a little hint: you can also create a diagnostic task for the healthy state. In the Configuration tab you can change the value in the drop down list: Execute when monitor’s health is: to Success
	In the Modules tab click on the Create… button in the Actions section and look for the Probe module we created in our first part. This time the one which is called AsTask at the end.
	You need to type in the same configuration as we provided for the monitor. If you do not want to execute this diagnostic task automatically when the state changes you need to disable the task in the Options tab.
	Creating an Agent Task is very similar. Just select to create a Custom Task and browse for the same type as in the diagnostic task. Provide a configuration and you are done.
	Create a file C:\test.txt or whatever file you specified in the config of the unit monitor. When the text file contains the string ERROR! you will get a unhealthy state for the monitor and an alert.   Import the MP and change the target type in the Discovered Inventory view to Root Management Server.
	Then open the Health Explorer and look for the monitor File Content Check Monitor. Also notice that we have our diagnostic task which can be executed and displays the property bag in the output.

That’s it. If you have any suggestions for improvement, questions or general feedback on this series, do not hesitate to contact me or leave a comment. I’ve also attached the complete management pack with this sample monitor.

cheers,
Stefan Koell
http://www.code4ward.net

Trackback Print

Tags:

Categories:

Location: Blogs Stefan Koell

Your name:
Your email:
	(Optional) Email used only to show Gravatar.
Your website:
Title:
Comment:
Security Code Enter the code shown above in the box below
Add Comment   Cancel