Writing a Custom SNMP Netapp management pack for System Center Operations Manager 2007 R2.
I have written this management pack to get the monitoring of your NetApp environment into System Center Operations Manager 2007 R2. I know there are other ways of monitoring your NetApp solution like NetApp Operations Manager and there is even a NetApp Management Pack from NetApp.
Although the NetApp MP looks promising at a first glance it is nothing more then basically 3 rules which catches SNMP traps based on severity “ Information, Warning, Error”. The only difference is that it uses the NetApp mibs to translate SNMP data into the alert description.
Because it only generates alerts it says nothing on the health status of your NetApp filers. Besides it has no health status and rollup there is also no performance collection. So with some basic snmp rules you would achieve the same which is by far not what I wanted!
Now because of these limitations I decided to start playing around with SNMP and the NetApp Simulator in my SCOM 2007 R2 test environment.
Although if you use NetApp Operations Manager along with SCOM it may give you a workable solution. But still you will have another console to use and I wanted everything in the good old Ops Mgr console 😉
Therefore I decided to write a custom management pack for NetApp filers which uses SNMP. The Management Pack and idea is based on an example from Kristopher Bash for monitoring Cisco devices.
These series will cover the total solution of designing the MP it is in a very detailed level so even though you don’t have NetApp running these series will be beneficial in designing your management packs. This way I can maybe help other people with building their own.
When writing these series I noticed the announcement for xSNMP Management Pack Suite which looks really promising! Especially the performance part! Will look into this as soon as it is available!
The tools used when desiging this MP are the common tools:
SNMP with Ireasoning
XML Editor with Notepad++
Besides these tools I created a test environment with Ops Mgr 2007 R2 and installed the NetApp simulator. This simulator acts as if it is a real Netapp Filer appliance it can be download from the NetApp website (login required). The cool thing is after installation you can also query the device by SNMP in your test environment ideal if you want to do some serious testing!
Maybe needless to say but always do your testing in a test environment!
Before we start with SNMP tools, mibs and authoring console it is crucial to design your model, classes and their properties and relationships. Therefore for every management pack you want to create start with a design and name your goals.
- How does the solution work?
- What tells me the application is running smooth?
- What classes make up the application and how do they relate to each other?
- How can I collect data?
- Which performance data is relevant?
- What do you want to monitor and how should it reflect the health state?
There are more but if you can answer these questions you should have enough information to start with the design.
Designing the Management Pack
First I started with designing the different parts (classes, objects) which made up a filer. Please always start with a clear design, because adding parts later on can be a real challenge if your classes are hosted and their relationships!
Basically the main classes for a NetApp Appliance are Filer – Aggregate – Volume – Lun
Remember a Hosted class cannot exist without its host!
When you look at the design
An Aggregate cannot exist without a Filer ————> Aggregate Hosted by a Filer
Voila we have now already created our Classes and relationships!
Now we have named our classes we need to start designing what kind of properties (attributes) we want to discover.
First let’s start with the filer we want to discover. This is the easiest one since we are targeting the discovery on the Base Class Microsoft.SystemCenter.Networkdevice we don’t need to add any key properties.
The properties we want to discover for a filer are:
Since its base class is Microsoft.SystemCenter.Networkdevice it automatically inherits the properties of the base class which are:
This means a filer has all its own properties and the ones it inherits from the networkdevice class.
The screenshot shows all properties belonging to a Filer Class.
Notice a Network device has a key property of IPAddress. A filer inherits the properties from a network device so we can use them in the rest of our management pack design!
Because the Filer its base class is a network device which is a non-abstract class the filer can’t have a key property. Therefore we don’t need to add one.
The other classes have hosted relationships and therefore a key property is required. For a class to be hosted by another class you need to declare key properties. Why is this needed?
When you discover a volume you will also need to discover on which aggregate the volume is hosted and on which filer. A key property is what makes the difference between instances of a class.
Let’s take the earlier example again
When you are discovering a volume (instance of a volume class like volume-2) the discovery will also need to know on which aggregate (instance of an aggregate class Aggregate-1) the volume (Volume-2)resides.
As you can see one filer can host multiple aggregates and each aggregate on its turn can host even more volumes. So how can you tell the difference of an Aggregate….well in our case by its name!
There is our key property for an Aggregate!
Now we know the unique property of an aggregate we need to discover the volume and it’s key property which is again its name! The same goes for the Lun class as well.
Our discovery which we are designing in the next post will discover the volume name and aggregate name. This way volume-2 is discovered which is hosted by Aggregate-1.
We have the key properties and we can fill in the other properties as well. Our total design is now complete:
Notice the key properties and the other properties as well. The important one is the key property the others you are free to create yourself.
I skipped a little part about the properties but with the SNMP tool you are able to tell which properties are appropriate for you. Next Series will cover this together with the actual discoveries.
Although there are a few pointers:
- Always be aware of the fact Ops Mgr is not SCCM….. Discovering attributes should only be used when you are going to use them in the future. When your purpose is collecting inventory System Center Configuration Manager is your friend and does this far more efficient then Ops Mgr.
- Also don’t use Attributes which frequently change like free disk space…this also causes pressure on the discoveries.