Hi,

Here the placement for System Administrator – Abu Dhabi, UAE.

Position : System Administrator

No.Of Openings : 3

Experience : 3 years.

Qualification :

Location : Abu Dhabi, UAE.

Required Skill set :

• General understanding of Microsoft Windows Server OS and supporting systems including SMTP, Sites and directory object management.
• Knowledge of basic networking protocols such as TCP/IP, Kerberos and SNMP.
• Understanding of Server hardware and peripherals.
• Knowledge of Microsoft Windows based Operating Systems, networking best practices and troubleshooting techniques/
• Experience with Dell hardware and Dell Blade Servers.
• HP and/or Dell certification a plus.
• Hands on experience with a helpdesk ticket system. Remedy is preferred.
• Team oriented with a desire to succeed in a fast paced environment.
• Excellent customer service.

Would you be interested ?

Please send us your latest updated profile with contact nos.
current & expected salary details and joining time required toradha@kbsconsultants.com

You may also suggest this opening to your friends who may be interested.

Further Information:

KBS Consultants

Flat H,Kulothungan Apts,
No, 5 Natesan Road
Ashoknagar,
Chennai 600 083.
India
Phone: +91-44 2489 5341 / 2371 9622

Visit Our Sites:

International jobs: http://www.jobsearchworld.com/
SAP ERP Jobs : http://www.jobsvista.com/
Core Engineering Jobs : http://www.gotachance.com/
Technology Jobs : http://www.kbsconsultants.com/
India Jobs :http://www.kbsconsultants.org.in

La manera no intrusiva de monitorear parámetros de la máquina virtual de java, es habilitar la capacidad de emitir datos por SNMP (Simple Network Management Protocol) al agregar los siguientes parámetros en las opciones extra de la JVM:

JAVA_OPTS=$JAVA_OPTS ” -Dcom.sun.management.config.file=/path/to/file/jvm.management.properties”

Contenido del archivo /path/to/file/jvm.management.properties

# SNMP Management Settings
com.sun.management.snmp.interface=0.0.0.0
com.sun.management.snmp.port=8162
com.sun.management.snmp.acl=false
#com.sun.management.snmp.acl.file=filepath
#com.sun.management.snmp.trap=<hostname:port>

Para comprobar que los parámetros fueron aceptados de manera exitosa, podemos buscar el puerto establecido, en este caso 8162, con estado Idle con netstat de la siguiente manera:

netstat -an | grep 8162
*.8162                              Idle

Finalmente, con el comando snmpwalk (linux) obtenemos los datos de la JVM:

snmpwalk -v2c -m all -c public <server>:8162 .1

.

JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….$’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….%’ = BITS: 02 00 terminated(6)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….&’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….(‘ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….)’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….*’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….+’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….,’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….-’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’……..’ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….0′ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….1′ = BITS: 01 00 waiting(7)
JVM-MANAGEMENT-MIB::jvmThreadInstState.’…….2′ = BITS: 01 00 waiting(7)
.

When I first started in system administration, I asked a colleague who was talking about SNMP what the ETLA* stood for.

His response: Simply Not My Problem.

SNMP – The Simple Network Management Protocol, is something that a lot of people get hung up over in relation to NetWorker. There’s usually two complaints:

1. Why do I have to pay for SNMP integration?
2. Where’s the MIBs?

The first question is more easily answered after answering the second; there are no MIBs (well, no official MIBs) for NetWorker. NetWorker doesn’t support being controlled by SNMP; instead, its SNMP “module” simply supports sending SNMP traps – broadcasts onto the network.

So now we return to the first question – why do I have to pay for SNMP integration?

The short answer is you don’t. I wouldn’t. If I were back to being a regular system administrator and someone walked in with a quote for NetWorker and included the SNMP module in it, I’d grab the quote and draw a big red line through it as being a complete waste of money.

Why pay for being able to send SNMP traps when there are free tools available for practically every operating system that allow you to do just that?

As to whether you should get hung up about NetWorker not natively supporting SNMP traps without any additional licensing – honestly, it’s not worth getting worked up about. NetWorker has a very extensible notification system where you can assign any action (read: executable with any command line actions) to practically any event within the system. With that much flexibility you can whack a free SNMP utility on the system and go to town.

–
* ETLA – Extended Three Letter Acronym

Alhamdulillah, masih bisa nulis lagi nih

Cacti merupakan software untuk memonitoring trafik jaringan dan menampilkan datanya dalam bentuk grafik yang mudah dimengerti dan dipahami tentunya disini merupakan software yang opensource. Sekarang kita mulai bagaimana cara menginstall cacti step by step :

Karena saya menggunakan Ubuntu Sabily 9.04 maka harap disesuaikan saja apabila menggunakan distro yang berbeda . Langkah pertama kita install dahulu software cacti beserta dependensi yang dibutuhkan :

pada tahap installasi diatas kita diminta untuk mengisi password dan ikuti perintah sampai selesai (oya jangan lupa password nya ). Dan sekarang saatnya mengkonfigurasi snmp :

brokenz@brokenz:~$ sudo -i

[sudo] password for brokenz:

Script started, file is /var/log/activities/20091031-11:58.18-root.log

root@brokenz:~# echo “rocommunity pr0xy” > snmpd.conf

root@brokenz:~# exit

brokenz@brokenz:~$ sudo /etc/init.d/snmpd restart

* Restarting network management services:                               [ OK ]

Kemudian setelah service sudah kita restart, coba buka browser dan ketik alamat ini 127.0.0.1/cacti dan isikan

Username : admin

Password  : admin

Seperti terlihat gambar dibawah

dan inilah halaman home cacti yang sudah kita install, untuk konfigurasi cacti bagaimana cara menampilkan grafik di cacti akan saya bahas di tulisan berikutnya .

Zahlreiche Tools zur Überwachung von NetApp basieren auf dem Monitoring-Defacto-Standard SNMP. Dieses Protokoll ist praktisch, da allgemein bekannt, weit unterstützt und leider auch uralt. Das zeigt sich zum Beispiel darin, dass heutige komplexe Systeme wie die Speichergeräte von NetApp eigene APIs bereitstellen, die auch bei komplexen Operationen noch übersichtlich programmatisch angesprochen werden können. Die NetApp-API ist unter anderem mit C, Java oder Perl anzusprechen. Somit war es für mich logisch, die NetApp-Plugins für Nagios in Perl zu entwicklen und dabei aber auf diese API zurück zu greifen.

NetApp Manage ONTAP SDK (NetApp Community Blog Article)

I have previously written about using the combination of an SnmpProbe and script probe in Operations Manager work flows to facilitate manipulation of numeric values.   While this is currently the only way to perform numeric operations, there are some cases in which the only required manipulation of a numeric value is the calculation of a delta between two polls, such as calculating the number of interface collisions in an interval (from the ifTable) or calculating the number of interface resets in a polling cycle (from the Cisco locIfTable).  In these cases, the SnmpProbe can be combined with a System.Performance.DeltaValueCondition condition detection module to calculate the delta value without having to engage a script probe.

The Performance.DeltaValueCondition module expects Performance Data as an input, so a System.Performance.DataGenericMapper must be used between the SnmpProbe and DeltavalueCondition modules to do the data conversion.   The DataGenericMapper accepts two options:  NumSamples and Absolute.   The NumSample parameter sets the number of value samples to maintain in memory, and the value returned is the difference between the first and last samples in memory.  The “Absolute” parameter, when true, causes the DeltaValueCondition module to return the delta as the raw difference between the samples, and when false, causes the module to return the percentage of change.

An example workflow can be represented in this diagram (the expression filter being used to validate the data returned from the SnmpProbe prior to continuing):

An example configuration of the DataGenericMapper in this workflow:

And an example configuration of the DeltaValueCondition module:

The output is in the System.PerformanceData format so the Value can be accessed with: /DataItem/Value in XPATH queries, or $Data/Value$ in value expressions.

I have been very busy lately so I apologise for not posting anything sooner. I have some more stuff on the shelf, so check back for more posts or simply add me on your RSS tracker if you regularly check back to my blog.

Ok, so this one is quite useful for you Solaris geeks that need to report uptime of machines on a regular basis. You could login with SSH and type uptime for your hosts, but if you have SNMP enabled, you can use snmpget commands to get the info on your screen or web port. The setup is very simple.

To get the uptime of a Solaris 10 host with SNMP enabled, simply run the following command, where 10.10.10.10 is the IP of your Solaris host:

root@server# /usr/sfw/bin/snmpget -v 2c -c dtv_ro 10.10.10.10 sysUpTimeInstance

The script below is a simple implementation of the command above, allowing you to add more IP addresses. You can alternative create an input file, which could be getting input from /etc/hosts. Obviously there are many ways of implementing this. I left it up to yourself to do that.

#!/bin/sh

echo
echo ${DATE}
for ip in ${IPS}
do
/usr/bin/printf "${ip}: "
${CMD} ${ip} ${OID}
done

Enjoy! For any other OS simply change the path for SNMP.

One of the realities of working with SNMP monitoring is that more often than not, the monitoring data are presented in a raw form that requires some kind of manipulation in order to render meaningful output.  For example, required data manipulation may be a simple arithmetic operation on two values to calculate a percentage, or in the case of Counter data, mathematical operations based on the delta between values recorded in multiple polling cycles.  In Operations Manager, these manipulations require exiting the realm of managed code and utilizing script-based modules to perform the operations or facilitate temporary storage of values from previous polling cycles.  Two sets of modules are available for the Operations Manager –supported scripting engines: WSH and PowerShell.  To date, I had been opting to use VB scripts when authoring Management Packs for two reasons: 1) WSH is universally deployed in Windows environments whereas PowerShell is not necessarily so – by using VB scripts, there is no requirement to install Power Shell on proxy agents 2) I had assumed that the resource utilization impact of PowerShell was equal or greater than that of WSH.   I had assumed that PowerShell would carry a heavier impact based on the simple notion that if one were to watch process resource utilization when simply launching powershell.exe and cscript.exe, powershell.exe consumes more memory and CPU time (assuming WSH 5.7 is installed).  

The resource utilization of these script providers becomes a major concern particularly when implementing script-based modules in SNMP monitoring scenarios.   To illustrate this point, if a proxy agent were configured to proxy SNMP requests for 10 Cisco switches, with each of these switches having an average of 20 interfaces discovered, and each interface monitored with two monitors that utilize a script probe action to manipulate the raw SNMP data (e.g. collisions and octets), 400 scripts would be executed in a single polling cycle for just the interface monitors for this small scale monitoring scenario.  This poses a threat to the scalability of SNMP monitoring and could severely limit the number of devices/objects a single proxy agent can handle effectively.  

In the course of trying to find a way to address this scalability issue, I was fortunate enough to communicate with someone possessing a great deal of insight into Operations Manager who helpfully suggested that the PowerShell modules should be more efficient than WSH-based modules in composite workflows.  I rewrote all of the scripts in the Cisco MP to convert them from VB Script to PowerShell and began some testing.  I was familiar with the tighter integration of PowerShell in R2 modules (PS scripts no longer have to be launched as external commands), but to be honest, I was expecting to see a large number of powershell.exe processes spawned as the monitors fired.   However, this is not the case.  Rather, it looks to me that the modules are executing the PowerShell script through the .NET framework within the context of the monitoringhost.exe process.   This does appear to be more efficient overall, as the overhead associated with spawning new processes is effectively eliminated, and my impressions thus far are that CPU utilization overall is reduced.

However, switching from WSH scripts to PowerShell scripts in R2 workflows is a little bit of jumping from the frying pan and into the fire in that, instead of spawning a large number of processes each consuming relatively small amounts of processor and memory resources, the PowerShell script modules drive a single process (monitroinghost.exe) to consume a large quantity of resources, particularly CPU cycles.   Overall, memory utilization looks a lot better with the PowerShell modules, and although CPU utilization does seem to be better, it is still a concern for scalability. 

Thus far, I have been doing this performance testing in a development environment, with OpsMgr running on some virtual machines on both on workstation and older server class hardware, neither of which provide a good indication of real-world scalability (particularly given the fact that I have these VM’s running SQL, all OpsMgr duties, and SNMP simulations to boot).  On one of these woefully over-utilized VM’s, something around 130-150 interfaces on 10 monitored Cisco devices seemed to be the breaking point, but a more realistic OpsMgr deployment scenario (segregated database, RMS, and MS duties) on physical hardware should be able to handle far more than that.   I will report an update once I get a chance to do some broader scalability testing with the PowerShell version of the MP on more appropriate hardware. 

In summary, both the WSH and PowerShell probe and write action modules introduce a relatively heavy CPU load when utilized for data manipulation – relative to the very simple operations required to manipulate SNMP data, and a managed code module would be far more desirable, if available.  However, at present, these two providers are the only supported mechanisms for handling data that require processing before returning to a rule or monitor.   My testing thus far appears to support the assertion that R2 implements the PowerShell modules more efficiently than the WSH-based modules, which is welcome news, given the relative ease and impressive flexibility of scripting with PowerShell.  I’ve seen a bit of talk that PowerShell V2 is supposed to bring significant performance improvements over V1, and I hope to do some testing with the CTP version of V2 on an OpsMgr proxy agent in the very near future to see if it helps address any of the scalability challenges in SNMP monitoring with OpsMgr.  As for the best approach for the present, it looks like PowerShell is the way to go, and the overall impact on the MS/proxy agents can be mitigated by spreading monitored objects across multiple proxy agents, focusing discovery to only those objects which are required to be monitored (i.e. interfaces), and avoiding overly-aggressive scheduling of monitors.

Due to the ubiquity of the Net-SNMP agent, the Net-SNMP management packs can be used for a wide range of UNIX/Linux devices, and one of my primary intentions in creating these management packs was to extend them to Linux-based proprietary platforms such as Check Point Secure Platform and VMWare ESX.  To that end, I am currently putting the finishing touches on management packs for Check Point Splat and VMWare ESX SNMP monitoring that reference the Net-SNMP Library MP. 

Check Point Secure Platform

SPlat is a hardened Linux kernel, which conveniently supports the Net-SNMP agent for manageability.  The Check Point-specific SNMP objects are exposed through the extended Net-SNMP agent as described in the CHECKPOINT-MIB.   So in this case, the Net-SNMP Monitoring MP can be used for basic system health, while an additional Check Point MP can be added to monitor the Check Point software modules for availability status and Firewall/VPN/Etc performance metrics.  

VMWare ESX – SNMP

Of course, ESX server is a modified Red Hat Enterprise Linux distribution that also utilizes the Net-SNMP agent for SNMP support.  VMWare exposes ESX-specific objects to SNMP via dlMod extensions to the Net-SNMP agent, including VM Guest info and some performance metrics.   So, in VMWare environments, the host operating system can be monitored for health through traditional Net-SNMP-implemented MIBs (UCD-SNMP, HOST-RESOURCES), while VMWare-specific counters can be monitored through the use of the VMWare MIBs.  

When it comes to monitoring of VMWare,  the VMWare SNMP implementation has the advantage of being easy to deploy and rather lightweight, and given the likelihood that SNMP may be used in VMWare environments for full vendor hardware monitoring, the VMWare SNMP implementation is a good way to introduce some monitoring of the hypervisor virtualization layer.  That being said, the VMWare SNMP implementation does leave a lot to be desired; for example, alarms/events are only exposed in SNMP through traps, only a few performance counters are available, and many VMWare Infrastructure objects are not represented.    For more complete/comprehensive monitoring of VMWare environment, the only data provider choice seems to be the VMWare API.   I’m working on something along those lines presently, but I’ll post more on that at a later date.

Así reza el eslogan de un fabricante de neumáticos, y no le falta razón.

Tambien viene al caso otra famosa frase:  “Lo que mides es lo que tienes” (Que afirma que si no se conoce el estado de algo, no es posible afirmar que funciona correctamente o se le saca todo el partido de que es capaz)

Ambas frases aportan algo tan simple como la necesidad que existe de medir y controlar todos los aspectos del centro de datos.

Hay ciertos aspectos fácilmente medibles, pero otros son de más difícil consecución.

Pongamos un ejemplo:

Se adquiere un switch con 48 puertos  Gigabit y una vez instalado se comienza a agregar tráfico por cada uno de esos puertos. Una vez se empieza a detectar que existe un descarte  de paquetes, colisiones de red u otros problemas es muy fácil detectar el problema pero hubiese sido más efectivo conocer que la CPU del dispositivo no puede con ese nivel de tráfico. El problema reside en que no todos los switches nos informan directamente de su nivel de carga de CPU,  throwput total y otros valores importantes que permitan conocer en cada momento el estado del mismo y el potencial de desempeño libre que dispone en cada momento.

Herramientas como los gestores SNMP, Nagios o  Network PRTG, por poner algunos de los más conocidos, son hoy en día indispensables en el centro de datos y permiten un control pormenorizado de los elementos y servicios .

Igualmente, cada elemento a incluir en el equipamiento del centro de datos debe ser compatible con protocolos de monitorización estandarizados, huyendo siempre de los métodos propietarios de unos u otros fabricantes.

De igual importancia son la correcta gestión de los mensajes, alertas, e-mails, alarmas sonoras y demás señales que estas herramientas generan y que deben ser tratadas, de forma automatizada unas y de forma manual otras.

Switches Virtuales

Un reto actual consiste en monitorizar con la misma capacidad, flexibilidad y potencia las redes virtuales que se están apoderando de los centros de datos. Los datos que pasan por los “virtual switch”, no son tan fáciles de monitorizar como lo son en este tipo de elementos físicos tradicionales y si bien es cierto que ya empiezan a surgir herramientas que facilitan estos menesteres, no se conseguirá un control  perfecto mientras estos switches virtuales no incluyan interfaces snmp, y módulos creados al efecto.

# virt-uname CentOS5x32
Guest            System name
CentOS5x32       Linux centos5x32.home.annexia.org 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:20:55 EDT 2009 i686
# virt-uname CentOS5x32 --csv
Guest,System name
CentOS5x32,Linux centos5x32.home.annexia.org 2.6.18-128.7.1.el5 #1 SMP Mon Aug 24 08:20:55 EDT 2009 i686

The query is done over an authenticated and encrypted SNMPv3 connection into the guest. This requires that the guest is running snmpd, but the end game here would be to have snmpd installed routinely, with a minimal config that only answers localhost connections which are properly encrypted with the key known only by the host and the guest.

Code here, and previous discussion.

Edit:

# virt-uptime CentOS5x32
Guest            Uptime
CentOS5x32       3 hours, 16:33.96
# virt-ping 
Guest            Status
CentOS5x32       ok

In Azienda è ormai onni presente il problema del monitoraggio dei server e degli apparati di rete. Ormai molti software, anche Open Source, ci permettono di tenere sotto controllo funzioni cruciali delle nostre macchine quali risorse CPU, spazio disco, funzionamento di servizi o demoni unix ecc. Inoltre, i software che sono compatibili SNMP, ci danno la possibilità di controllare anche apparati normalmente più difficili da tenere sotto controllo, quali Router, Switch e altri apparati. Questi sistemi, adeguatamente configurati possono avvertire, tramite SMS, email o POPUP di eventuali problemi verificatisi sulle macchine.

Personalmente avevo un’altra necessità, controllare che la temperatura della sala server rimanesse entro certi parametri. L’idea era di trovare non un semplice termometro che allertasse in qualche modo in caso di pericolo, ma un apparato che fosse collegabile al nostro sistema di monitoraggio.

La scela è ricaduta sull’ENVIROMUX Mini di NTI (link) un sistema a abbastanza economico (anche se il costo in Italia in Euro, è superiore al costo negli Stati Uniti in Dollari ndr) al quale è possibile collegare tutta una serie di sensori fra cui:

• Temperatura
• Umidità
• Allagamento

e dispone inoltre di 4 contatti “switch” al quale collegare anche sensori fatti in casa (contatti apriporta o altri ad esempio) è inoltre monirotabile e configurbile via SNMP il che gli permette di essere visto anche da Zabbix (link) il nostro sistema di monitoraggio.

Attualmente ho installato la 1.6.5 che ha la possiblità di lavorare utilizzando template per la configurazione veloce di apparati conosciuti. Una (grande) serie si trova già all’interno, e, dove sia utile farlo, è possibile crearne di personalizzati.

di Seguito ecco quello che ho creato per l’Enviromux da me acquistato. Premetto immediatamente che ho acquistato il solo sensore di temperatura, quindi Item monitorati e Trigger configurati sugli stessi sono relativi al solo sensore della temperatura. Nell’XML è presente un HOST già monitoratocon Indirizzo 10.10.10.10

Per utilizzarlo è sufficente copiare ed incollare in un file il codice XML presente nella wiki del sito ZABBIX, quindi importare nella sezione import/export della configurazione il file così ottenuto.

Qui il link al Thread sul Forum Ufficiale contenente le presentazioni di tutti i template caricati dagli utenti

I have completed the first version of the Cisco Management Pack for SP1 compatibility.  The monitoring in the management pack is identical to the R2 version of the MP, described most recently here.      Due to the dependence on the WMI SNMP provider for object discovery, there are inevitably some scalability limitations intrinsic to the SP1 edition of this MP, but I haven’t done enough full-scale testing to ascertain those limitations as of yet.   Additionally, deployment of this management pack requires some additional steps.   These steps are detailed below (taken from the MP documentation):

Prerequisites

This management pack utilizes the WMI SNMP provider to perform discovery of SNMP objects.  In order to use this management pack, the following steps must be completed on each server that will function as a proxy agent for SNMP-monitored Cisco devices.

Install the SNMP protocol and WMI SNMP provider

• To install these components, access Add/Remove Programs in the Control Panel, and select Add/Remove Windows Components.  Under Management and Monitoring select: Simple Network Management Protocol and WMI SNMP Provider

The following MIBs must be exported to MOF files with smi2smir.exe and imported with MOFComp.exe:  CISCO-ENVMON-MIB and CISCO-MEMORY-POOL-MIB.  

• The MIBs and a batch file to perform these steps can be found in the /Setup directory included with this MP distribution.   Run the RegCiscoMibs.cmd file and check the output log: register.log to confirm that the mibs were successfully compiled and imported.

Recommended Proxy Agent Configuration

If WMI receives too many requests in a short time, it may suspend processing of requests for a period of time.   This can impact the ability of this management pack to discover Cisco SNMP objects in a timely fashion (WMI SNMP is only used by this MP for discovery, and not object monitoring).   In order to minimize the chances of this situation occurring, the object discoveries in this MP should not be scheduled too aggressively.   Additionally, it is recommended that if a large number of Cisco SNMP devices are to be monitored, they should be distributed across multiple proxy agents for load-balancing of the WMI SNMP requests. 

It is highly recommended that all agents that will function as proxy agents for SNMP devices have the Windows Script Host version 5.7 installed.  Version 5.7 is far more efficient than previous versions and reduces the resource utilization by the cscript.exe process dramatically.

It is also highly recommended that all agents that will function as proxy agents for SNMP devices have the hotfix: KB96163 applied.  This hotfix resolves instability with SNMP monitoring in Operations Manager 2007 SP1. http://support.microsoft.com/default.aspx/kb/961363

I’m interested to hear how this SP1 edition of the Cisco Management Pack functions in different environments, so any feedback is most certainl welcome.  I will continue to post updates to this site so be sure to check back regularly.   For more information about the scripts utilized in discoveries in this edition of the MP, this post should sum it up.

I’m hoping to finish up the SP1 version of the Cisco Management Pack pretty soon, but I’ve modified the R2 version to include several new changes.  The current version: 1.0.2.6 can be downloaded here. 

The changes in this version are:

• Added three new containment classes:  Cisco Device Chassis, Cisco Device System Components, and Cisco Device Interfaces.   These classes contain monitored objects to add an additional level of hierarchical organization.
• Added discovery of the IFAlias property for Interfaces
• Added discovery of the Hostname (OLD-CISCO-MIB) and Chassis description for the Cisco Device class.
• Updated the properties displayed by default in the Device and Interface views
• Added a rule to clean up unused XML temporary files once a day.   Several of the monitors utilize temporary XML files written to the %TEMP% path.  In the previous version, old files would be left on the file system if a previously monitored object was removed.  This rule will remove those temporary files.
• Modified discovery intervals for some objects for more balanced timing.
• Added four new monitors for switches that implement the CISCO-STACK-MIB.  The monitors are targeted at the Cisco Device Chassis class and include
  • Fan Alarm
  • Temperature Alarm
  • Minor Alarm
  • Major Alarm

With the new containment classes, the diagram view looks a lot better:

I’ve made a few minor updates to the Net-SNMP Management Packs, available at the same download location.   The changes in 1.0.1.30 are:

• Implemented new class:  Net-SNMP Monitored Process Instance, along with rules to collect and monitor process instance CPU and memory use.  Reference the MP documentation in the zip file (and the preceding post) for more information.
• Updated all alerts to include the hosting device name.
• Added a rule to periodically purge old temporary files used by the Interface Utilization data source.

Any future updates will be posted to this blog, and thanks to everyone who has commented on these management packs. 

Some screenshots of the new process instance monitoring capabilities:

Regardless of the operating system, monitoring of the availability and resource utilization of individual processes is a pretty standard requirement.  Between WMI and PerfMon counters, this is easy on Windows systems, but doing the same on UNIX/Linux systems can be a little bit more complicated.   In Operations Manager 2007 (R2) environments, there are three general approaches (excluding third party products) that can be utilized to monitor individual processes on UNIX and Linux systems:

1. An agent-based solution using the R2 Cross Platform agents
2. A purely SNMP solution using tables in the HOST-RESOURCES MIB
3. An extended SNMP solution using the proc or exec directives in the Net-SNMP agent’s snmpd.conf file

I think it’s fair to say that in most cases (and when it is supported), the R2 Cross Platform agent is the best and most robust approach.   However, it’s almost an inevitability in medium and large enterprises that there will be some UNIX or Linux servers or appliances running distributions not supported by the R2 agents.  In these cases, or if there is another compelling reason not to deploy agent software to the device, SNMP may be the best or only option.   The pure SNMP option is probably the most universally applicable approach, but introduces a number of challenges, which I will discuss in this post.  The third option brings a great degree of flexibility (particularly with the exec directive, which can return the result of an on-demand shell script to an SNMP OID) but requires decentralized configuration. 

The approach that I took in the Net-SNMP Management Pack is a hybrid of the pure SNMP and extended SNMP options.  The latest version of the MP (which I will be posting soon) supports process resource utilization through the HOST-RESOURCES MIB tables in addition to process availability monitoring facilitated by identifying the monitored processes with the proc directive in snmpd.conf.  And as described in the previous post about the MP, if ultimate flexibility is needed, the Extensible Object capability with the exec directive is still supported.  

UNIX/Linux SNMP Process Monitoring In-Depth

Availability Monitoring:

While it would be possible to configure SNMP process monitoring in a centralized fashion by defining processes to be monitored on an  SNMP management server and then monitoring by walking the agent’s hrSwRun SNMP table, this poses a number of challenges with Operations Manager.   The challenges exist on multiple levels and may be best illustrated with some examples.

In the simplest scenario, suppose the monitoring requirement was to confirm that a particular process was running on a system, at least once.   An SnmpProbe could be configured to walk the hrSwRunName column in the hrSwRun table, with the output data items passed to an ExpressionFilter that matches the returned value to a defined process name variable.   For any match, the workflow would continue and could be passed to a monitor type.   However, if no match were found (indicating a problem), no data item would make it through the filter and there would be nothing to evaluate in subsequent modules.     

Even if a creative solution were implemented to get around the filtering issue, there is still an issue when the monitoring requirement is to monitor both a minimum and maximum number of instances of the process.   If the workflow of scheduler -> SnmpProbe (walk) -> Expression Filter were used in this scenario, every matched data item that passes through the Expression Filter would be handled distinctly.  There would be no easy way to calculate the count of the data items to derive a number of running processes, making this an unappealing option in most cases (I did utilize something like this in the Net-SNMP MP though, for more details, reference the discussion of the zombie process count below). 

What I concluded to be a more reasonable approach is to utilize the process monitoring capabilities of Net-SNMP and require that processes to be monitored for availability (minimum and maximum counts) be configured with proc directives in the snmpd.conf.   Processes configured for monitoring in this fashion are then exposed in the UCD-SNMP prTable, which includes the process name, current count, an error flag value, and a pre-formatted error message.   With this information readily exposed, it is easy to discover the defined process monitors in this table as OpsMgr monitored objects and monitor the error flag (and collect the error message for alert descriptions).

For the sake of thoroughness, there are some conceivable scenarios where a Scheduler -> SnmpProbe (walk) -> Condition Detection workflow would be an ideal approach for monitoring.   For example, if the presence of a process in one or more instances indicated a problem condition, this workflow could be configured followed by an alert-generating write action which would fire an alert for every instance matched. 

Resource Utilization Monitoring

Having settled on using the Net-SNMP agent’s process monitoring configuration for process availability monitoring, I deliberated on monitoring process resource utilization for some time (and skipped it altogether in the first version of the Net-SNMP MP).   Performance metrics (memory used and cpu time) can be accessed in the hrSwRunPerf table, and rows in the hrSwRunPerf table correspond to rows in the hrSwRun table through the Index values (which match the PID of the process on the agent).    This too poses a number of challenges which I will try to describe through hypothetical examples. 

If one wanted to monitor for any process consuming memory above a certain threshold, the hrSwRunPerfMem column of the hrSwRunPerf table could be walked and filtered to match only processes that exceeded the threshold.   This could then be passed to an alert-generating write action.  However, the only values available in this SnmpDataItem would be the OID and the memory use value, which would not make for a very friendly alert description.  

Supposing the requirement was to monitor the memory utilization of a particular process, it would be even more difficult.   The hrSwRun table would have to be walked to find the OID of the process that had a matching name, and then this OID would have to be passed to a script probe to calculate the PID/Index, and then another SnmpProbe would have to be initiated to retrieve the values – made all the more complicated by the fact that there may be more than one instance of the process to monitor.

One way to work around these challenges is to forgo SNMP walks in the monitors, and use SNMP walks to periodically discover the processes in the hrSwRun table and their properties, and then use the discovered index to formulate specific OIDs for use by the SnmpProbe with SNMP get requests.   Running processes can be quite numerous and dynamic, so such an approach with discoveries would necessitate filtering by process name to restrict discovery only to processes to be monitored.    Because I had already decided on using the proc directive to facilitate process availability monitoring in the Net-SNMP MP, I decided to extend that configuration by adding a new class for Monitored Process Instances, which are hosted by the Monitored Process objects.   So, as it is configured in the MP, process monitoring items defined in the snmpd.conf are discovered (followed by a second property discovery).  Another discovery then walks the hrSwRun table to match process names in the table to already discovered Monitored Process objects, and then a final discovery discovers the properties of these monitored processes.    The Monitored Process object is monitored for availability by polling the prTable for the errorflag value, and data for the Monitored Process Instance objects are collected by polling the hrSwRunPerf table.   While the discoveries introduce some latency in the performance monitoring every time a PID changes, the assumption is that the processes singled out for monitoring will not be that variable as they likely represent production services that do not recycle with high frequency.

Process CPU Monitoring with the hrSwRunPerf Table

The reason I used the process memory utilization in the preceding examples is because the CPU utilization monitoring is more complex.  The hrSwRunPerfCpu object is an SNMP counter, indicating the number of centiseconds of total CPU time used by the process.   This value is only meaningful (similar to other SNMP counters like ifOctets in the ifTable) when two samples are compared over time.   If my math is correct, the calculation should be as follows:

There are 100 centiseconds in 1 second of “wall-clock” time (as the MIB describes it).  So, 100% of CPU time in 1 second would be 100 centiseconds.    50% of CPU time in 1 second would be 50 centiseconds.   25% of CPU time in 60 seconds would be 1500 centiseconds.   The formula to calculate percent of CPU (in decimal notation 0 – 1 ) would be X = delta / (time * 100), thus  1500/(60 * 100) = .25.   The formula to return the percentage in a 0 – 100 value would be: (delta * 100)/(time * 100) or simply delta/time.   As for calculating the delta, I utilized a similar approach as in a number of monitors in the Cisco MP.  That approach is to maintain a small XML file in a temporary directory (%temp%\Custom_SNMPFiles\) for the each object to be monitored by this data source.   If an existing file is found, the data source (via a property bag script probe) compares the time stamp and preceding value (if they are recent enough) to the current values, returns the calculated values as a property bag, and then writes the current values to the XML file.   It should be noted that the MIB definition for the HrSwRunPerfCpu counter warns that multi-processor systems may report values in excess of “wall-clock” time, which could create percent utilization values above 100%.   However, I believe this is an issue that has been resolved in most UNIX/Linux distributions.  

Zombie Process Monitoring

I never fully understood why many UNIX monitoring packages included monitoring for zombie process until one instance many years ago when I was troubleshooting a problem on an AIX 4.3 server.  In the course of troubleshooting, I checked the running processes with a ps –ef command and was a bit suprised as thousands of processes scrolled by.  It may not be a common problem, but it was one that I wanted to include monitoring for in the Net-SNMP MP.   To implement this monitor, I utilized a collection rule that fires an SnmpProbe that walks the hrSwRun table and filters for processes with a status of Invalid.   Every match is passed to a script write action that writes the device IP and pid to a text file in a temporary directory.   The monitor itself utilizes a script which scans the temporary directory for files that match the device IP (and are recently modified) to tabulate a count of zombie processes.   This value is then compared to a threshold to determine health state.   To keep the monitoring script running in a reasonable time, it also cleans up old files in the temporary directory.   In some cases, it would be possible for the collecting data source to spawn a high number of cscript processes concurrently if many matches were found, but I don’t think this will be a problem as the condition should be relatively rare and the default threshold (25) is pretty low.   The chances of a high number of monitored hosts simultaneously having a high number of zombie processes concurrently are pretty low. 

While this has been a rather wordy post, I hope that I was able to illustrate some of the challenges in the monitoring of tabular SNMP objects with OpsMgr 2007 R2 and the methods that I implemented to address those challenges in the Net-SNMP MP.

I have completed version 1.0.1 of the Net-SNMP management packs for OpsMgr 2007 R2 , and I thought I’d go ahead and share them.  At this point, my testing of the management packs has been on a small development network with Sun and CentOS servers, but so far everything is looking pretty good.   These management packs should provide a pretty good set of monitoring for UNIX and Linux servers that run the Net-SNMP agent, which includes Solaris, most Linux distributions, and even VMWare ESX and Checkpoint Secure Platform. 

As I had discussed in my last post, there are two management packs in this set.  The Net-SNMP Library management pack defines the classes and performs discoveries.   This can be imported by itself to facilitate completely custom monitoring or to be referenced in other management packs.   The Net-SNMP Monitoring management pack implements a pretty standard set of monitors for UNIX/Linux server performance and availability monitoring and supports the Exec, Proc, and File directives of the Net-SNMP agent configuration. 

The management packs can be downloaded here.  They are released under the GNU Public License and can be used, modified, and distributed freely, as long as the attribution remains intact. 

Some screenshots:

More details can be found in the documentation included in the .zip file, but here’s the abbreviated list of monitors and rules in the Net-SNMP Monitoring MP:

Monitors

Net-SNMP Device

• Net-SNMP CPU Context Switches per Second
• Net-SNMP CPU Interrupts per Second
• Net-SNMP CPU Percent Idle
• Net-SNMP CPU System Percent Utilization
• Net-SNMP CPU User Percent Utilization
• Net-SNMP Percent Real Memory Free
• Net-SNMP Percent Swap Memory Free
• Net-SNMP Zombie Process Count Monitor

Net-SNMP Network Interface

• Net-SNMP Network Interface Status
• Net-SNMP Network Interface Percent Utilization

Net-SNMP Monitored Extensible Object

• Net-SNMP Extensible Object Status

Net-SNMP Monitored File

• Net-SNMP Monitored File Status

Net-SNMP Monitored File

• Net-SNMP Monitored Process Status

Net-SNMP Volume

• Net-SNMP Volume Percent Utilization

Rules

Net-SNMP Device

• Alert on Net-SNMP Device Rebooted
• Collect Net-SNMP Total Available Memory
• Collect Net-SNMP Swap Memory Percent Free
• Collect Net-SNMP Real Memory Percent Free
• Collect Net-SNMP Number of Current Users
• Collect Net-SNMP Number of Current Processes
• Collect Net-SNMP I/O Sent
• Collect Net-SNMP I/O Received
• Collect Net-SNMP CPU Interrupts per Second
• Collect Net-SNMP CPU User Percent Utilization
• Collect Net-SNMP CPU System Percent Utilization
• Collect Net-SNMP CPU Percent Idle
• Collect Net-SNMP CPU Context Switches per Second
• Collect Net-SNMP Zombie Processes

Net- SNMP Network Interface

• Collect Net-SNMP Network Interface Out Percent Utilization
• Collect Net-SNMP Network Interface In Percent Utilization

Net-SNMP Volume

• Collect Net-SNMP Volume Percent Utilization

Be sure to check back here for updates to these management packs and if you give thema try, I’d love to hear your impressions or suggested changes!

The Net-SNMP agent is a cross-platform SNMP agent that is often bundled with UNIX (e.g. Solaris) and Linux distributions (including VMWare and Checkpoint Splat).   The agent implements some relatively standard MIBs, such as the UC Davis (UCD-SNMP-MIB) and HOST-RESOURCES MIBs, exposing a good selection of operating system metrics for monitoring.  Furthermore, the agent is remarkably extensible in a few different ways.  The agent can be extended with “dlMod” module extensions to integrate additional SNMP components, such as the VMWare or HP Insight Management Agent modules.   Additionally, the Net-SNMP agent can be configured to proxy for another SNMP agent listening on a different port, which is how the Sun SunFire Management Agent is typically configured.   Lastly, the Net-SNMP agent provides the ability to define processes, files, extensible objects, load average objects, and disks for specific monitoring.  For each of these, directives are configured in snmpd.conf with parameters and thresholds, and an SNMP table is exposed that will return the monitored value and status value to an SNMP poll, on-demand.   I had previously  posted an article on using the ext (Extensible Object/Arbitrary Extension) capabilities of the Net-SNMP agent to utilize shell scripts for monitoring of Sun hardware.   With this degree of flexibility, it’s easy to understand why the Net-SNMP agent is so widely utilized.

Design Approach for the Net-SNMP Management Pack

Building on the lessons learned from developing the Cisco Management Pack, I wanted to create a management pack with similar capabilities for monitoring of Net-SNMP agents, followed by a set of management packs for monitoring of vendor-specific hardware (e.g. HP Proliant servers running Linux).   After some thought, I decided that it would be advantageous to split the Net-SNMP management pack into two separate management packs, one that defines the base classes and performs discovery of the classes and one for the actual monitoring.   The reason for this is that I wanted a base management pack without any actual monitoring functions so that it could easily (and more flexibly) be reused for future hardware monitoring management packs.   To illustrate this point, if the native UNIX agent capabilities of R2 are being used to monitor OS-level objects, there is still a need to discover the Net-SNMP agent and create base classes for use in SNMP-based hardware monitoring, but in this case, monitoring OS-level objects with SNMP and the OpsMgr agent would be redundant.  With the multiple MP approach, just the base Net-SNMP management pack could be imported along with the hardware monitoring management packs, skipping the Net-SNMP monitoring management pack altogether.  Additionally, I wanted to leave the monitoring management pack unsealed for easy customization, and MP references can only be made to sealed management packs.  In this way, the Net-SNMP Library MP will be sealed, but the monitoring MP can remain unsealed.

The Net-SNMP Library Management Pack

As described above, this management pack just defines the Net-SNMP object classes and performs the discovery of these objects.  The discovery methodology is pretty much the same as in the Cisco Management Pack, but I did do some things a bit differently.  Most notably, I added an additional layer of classes in the containment hierarchy.   In this management pack, the Net-SNMP Device class hosts a set of containment classes such as Network Interfaces, Volumes, and Monitored Processes.  These classes in turn host the actual objects to be monitored:  Network Interface, Volume, and Monitored Process.  My motivation for this was primarily to keep the object relationships more neatly organized, particularly when viewing the objects in a Diagram View.   This does add a slight degree of complexity, but I think the benefits of having a more usable Diagram View justify the additional complexity. 

I chose to create hosted classes for the following objects:  Network Interfaces, Volumes (logical disks and memory pools from the hrStorage table), Monitored Processes, Monitored Files, and Monitored Extensible Objects.   I ignored the customizable Load Average and Disk monitoring capabilities of the Net-SNMP agent because those objects can be monitored through existing SNMP objects in the UCD-SNMP and HOST-RESOURCES MIBs and I wanted to keep the monitoring configuration within OpsMgr as much as possible (instead of in the agent snmpd.conf).   The Files, Processes, and Extensible Objects monitoring capabilities of the Net-SNMP agent cannot easily be replicated with other SNMP monitors, so I included those to maintain a high degree of monitoring extensibility. 

The class diagram for the Net-SNMP Library MP is:

Results

With just the NetSNMP.Library MP imported, the Diagram View is a pretty good demonstration of the MP in action:

As previously mentioned, the Cisco Management Pack that I have been describing in the past several posts is specific to OpsMgr R2, due to its reliance on the capability of the System.SnmpProbe’s function to return multiple items in an SNMP walk, which is a feature introduced in R2.   My intention was to design the management pack so that it could easily be made SP1 compatible by substituting the discovery methodology, but keeping the classes and monitoring objects intact.   I am still doing more testing to finalize the SP1 version, but in this post, I am going to introduce the discovery methods that I have implemented for SP1 compatibility.

In general, when dealing with SNMP objects stored in tables, options in SCOM 2007 SP1 are a bit limited.  If the table objects are static, rules could be configured targeting specific OID’s, but this is unlikely to be a common scenario.   Another option (and a quite good one) would be to segregate monitoring duties between SCOM (for servers and applications) and a task-specific SNMP monitoring tool like SolarWinds or JalaSoft for SNMP device monitoring.   But for the purposes of this management pack, the option I pursued involves wrapping an external SNMP provider in WSH scripts to perform the discovery.   I chose to use the WMI provider because of its easy use in VBscripts and object-oriented capabilities, but something like the Net-SNMP binaries could be called with ShellExec methods in a vbs script to accomplish the same goal.  

Before I get into the use of the WMI SNMP provider in this MP, there is some background information that should be discussed.  Firstly, when the WMI SNMP provider is installed, it includes support only for the RFC-1213 MIB.   In order to use the WMI SNMP provider for OID’s not in the RFC-1213 MIB, the MIB files must be converted to MOF files with smi2smir.exe and then imported with mofcomp.exe.    This can get a bit tricky, largely depending on how well constructed the vendor’s MIB is and the dependencies of the MIB.   Once these steps are completed, the WMI SNMP provider exposes SNMP objects as collections that can be accessed natively in VBscripts.   However, the WMI provider is not terribly scalable and when overloaded with requests, WMI will cease to function in a timely fashion.   I had done some testing with using the WMI SNMP provider for rules and monitors, but decided against this approach due to the ease with which the provider can be overloaded when monitoring a handful of objects with reasonably aggressive frequencies.   On the other hand, discoveries are not as time-sensitive as monitors/rules and don’t need to run as frequently, so by using the WMI SNMP provider for discoveries, and the System.SnmpProbe provider for monitors and rules, this hybrid approach should remain pretty scalable. 

Implementation Overview

Installing the WMI SNMP Provider

The WMI SNMP Provider can be installed through the Control Panel’s Add/Remove Programs (or Program and Features for 2008) applet, by select Add/Remove Windows Features, then selecting the WMI SNMP Provider (and SNMP if it isn’t installed) under Management and Monitoring Tools.

Registering MIB’s with the WMI Provider

To register MIBS with the WMI SNMP Provider, they must first be converted to MOF files with smi2smir.exe and then imported with mofcomp.exe.  Both of these can be found under the %systemroot%\system32\wbem\ directory, with smi2smir.exe being in the \snmp subdirectory.  If the MIB file has dependencies on other MIBs, they must also be available and specified in the smi2smir.exe command.   To illustrate this, to create an MOF file for the CISCO-ENVMON-MIB, the command ends up as:

%SYSTEMROOT%\system32\wbem\snmp\smi2smir.exe /g CISCO-ENVMON-MIB.mib CISCO-SMI.mib > CISCO-ENVMON.MOF

Then the mofcomp.exe import can be run with:

%SYSTEMROOT%\system32\wbem\mofcomp.exe CISCO-ENVMON.MOF

For the purposes of this management pack, all WMI SNMP discovered objects are available in the RFC-1213, Cisco-EnvMon, and Cisco-Memory-Pool mibs, so only two MIBs have to be imported.   The monitors/rules will continue to use the System.SnmpProbe, which can target an OID without importing the MIB.

Querying the Snmp Provider

Once the MOF is registered with the WMI SNMP provider, a VBScript can instantiate the provider and represent an SNMP table as a collection object, such as:

Set objWMILocator = CreateObject(“WbemScripting.SWbemLocator”)
Set objWMIServices = objWMiLocator.ConnectServer(“”,”root\snmp\localhost”)
Set objWmiNamedValueSet = CreateObject(“WbemScripting.SWbemNamedValueSet”)
objWmiNamedValueSet.Add “AgentAddress”, cstr(DeviceIP)
objWmiNamedValueSet.Add “AgentReadCommunityName”, cstr(CommStr)

Set colPowerSupplies = objWmiServices.InstancesOf(“SNMP_CISCO_ENVMON_MIB_ciscoEnvMonSupplyStatusTable”, , objWMINamedValueset)

For each objItem in colPowerSupplies
   sDesc = objItem.ciscoEnvMonSupplyStatusDescr
  nIndex = objItem.ciscoEnvMonSupplyStatusIndex
Next

By using this in a script discovery probe, the values retrieved from WMI SNMP can be used to discover objects and properties all in one script.  Continuing with teh Cisco power supply example, the objectdiscovery portion of the script would look something like:

set oInst = oDiscoveryData.CreateClassInstance(“$MPElement[Name='CiscoSNMP.Class.CiscoDevice.PowerSupply']$”)
call oInst.AddProperty(“$MPElement[Name='MicrosoftSystemCenterNetworkDeviceLibrary!Microsoft.SystemCenter.NetworkDevice']/IPAddress$”, DeviceIP)
call oInst.AddProperty(“$MPElement[Name='CiscoSNMP.Class.CiscoDevice.PowerSupply']/Index$”, cdbl(nIndex))
call oInst.AddProperty(“$MPElement[Name='System!System.Entity']/DisplayName$”, sDesc) 
call oDiscoveryData.AddInstance(oInst)               

At the risk of going too far off on a tangent, I’ve come upon a few idiosyncrasies in working with the WMI SNMP provider for this MP.  The first peculiarity is that the index value in the Cisco EnvMon tables is properly populated. When browsing the Cisco EnvMon objects with a MIB browsing utility or using the System.SnmpProbe, these index values are not populated, so I’m not sure why it works with WMI SNMP and not these other more traditional methods.   The second peculiarity is that I have found that in some cases, octetstrings are not properly converted to text strings when using the WMI SNMP Provider.  Specifically, the names of some of the Cisco EnvMon objects would be returned as hex strings for some objects and text strings for others.   To work around this issue, I added a little function in the discovery scripts that attempts to convert the names from hex to strings, and only uses the converted value if no errors were trapped in the conversion (which should indicate that it is actually a hex string).  This function looks like:

Function HexToString(str)
                on error resume next
                sOutput = “”
                For x = 1 To len(str) Step 2
                                sChar = Chr(Clng(“&h” & Mid(str,x,2)))
                                sOutput = sOutput & sChar
                Next
                if err.number = 0 then
                                HexToString = sOutput
                Else
                                HexToString = str
                end if
End Function

Other than the discoveries, everything else in the MP should remain pretty much unchanged (unless something unexpected is exposed in testing).

I have uploaded version 1.01.27 of the Cisco Management Pack.   This minor update includes a few fixes and some new features added in response to some helpful comments from readers who have tried this MP out.  The changes in this version are:

1. Group Population rules have been fixed so that they can be edited in the GUI
2. Performance data collection has been modified to not collect data when the interface is in a partially discovered state.  This should prevent duplication of performance counters for interfaces going forward.   Because the Interface discovery occurs in two parts: 1) discovering the interfaces and 2) discovering the interface properties, I added a property to the Interface class named: Discovered.  When the Interface discovery runs (which just discovers the index), the discovered property will be set to False.  Once the Interface Property discovery runs, this property will be set to True.   The performance collection rules have been modified to only collect data if this property is set to true. 
3. Index discovery can now be filtered with a RegEx expression for a device via an override (create the override on the Discover Cisco Interfaces discovery).   By default, the RegEx expression:  (.|..|…) will be used to discover interfaces, which will discover all interfaces with indexes with 1, 2, or 3 digits in length.  To filter by interface index, the expression can be modified to:  (1|2|3|10|15) where the numbers are the index values for the interfaces to be discovered, separated by pipe characters.   The override for this filter can be targeted at all Cisco devices, a group, or specific devices.
4. I have added a new property to the Interface class named:  “Speed – Override.”  This property allows for manually defining a speed value for the interface to be used in utilization calculations.  There are two scenarios where this is useful: 1) sometimes the value reported in the RFC-1213 ifTable for an interface’s speed isn’t accurate, and 2) if an Ethernet port is the last monitored hop before a lower bandwidth wide-area connection (i.e. the vendor equipment is not monitored), it can be useful to monitor the Ethernet port as if its speed were equivalent to the wide-area connection bandwidth.   For example, if a switch is the last monitored device before connecting to a vendor-managed MetroE connection with a maximum bandwidth of 500Mbit, monitoring utilization on the gigabit switch port will be more accurate if the speed were overridden to 500Mbit.  This property can be set with an override on the Discover Cisco Interface Properties object discovery, by setting the OverrideIFSpeed value to the desired speed, in bits per second.

Note:  Updates to this MP are described here.

I still have some more full-scale testing to complete, but I have finished the first version of the Cisco monitoring management pack that I have described in the last few posts.   This version is R2 only, but I hope to have an SP1 version of it complete soon.  The management pack can be downloaded here.  

I have decided to license this management pack under the GNU Public License; so in short, you are free to use, modify or distribute it as long as any distribution maintains the original attribution.   Be sure to check back at this site for updates to the management pack, and feel free to let me know if you come upon any issues with this management pack or want to request additional features.

More complete documentation of the management pack can be found in the zip file, but the management pack elements are as follows:

Classes

• Cisco Device
• Cisco Interface
• Cisco Power Supply
• Cisco Fan
• Cisco Temperature Sensor
• Cisco Memory Pool

Groups

• Cisco Devices
• Cisco Ethernet Interfaces
• Cisco Serial Interfaces

Monitors

• Cisco Device Default GW Changed Monitor: 
  Monitor that detects and alerts on changes to the device’s default gateway, as defined in the IP route table.
• Cisco Device CPU Utilization Monitor: 
  Monitor that generates an alert on high CPU utilization.
• Cisco Interface Status Monitor: 
  Monitor that generates an alert when the OperStatus for the interface is not up.  Alert is only generated when AdminStatus is up. 
• Cisco Serial Interface Flapping Monitor: 
  Monitor that generates an alert when the ifResets counter for the interface increases by more than 2 in a polling cycle. 
• Cisco Interface Collisions Monitor: 
  Monitor that generates an alert when the collisions reported on an interface increase by more than 25 in a polling cycle. 
• Cisco Interface Utilization Monitor: 
  Monitor that generates an alert when the percentage of inbound or outbound utilization is above 85.
• Cisco Power Supply Status: 
  Monitor that generates an alert when the power supply status is not ok.
• Cisco Fan Status Monitor: 
  Monitor that generates an alert when the fan status is not ok. 
• Cisco Temperature Sensor Status Monitor: 
  Monitor that generates an alert when the temperature sensor status is not ok.
• Cisco Memory Pool Utilization Monitor: 
  Monitor that generates an alert when the utilization of the memory pool is greater than 90 percent.

Rules

• Collect Cisco CPU Utilization 5min:
  Rule that collects the average CPU load over the past five minutes for performance reporting
• Alert on Cisco Device Rebooted:
  Rule that generates an alert when the SysUptime is less than 10 minutes, indicating a reboot
• Collect Interface In Utilization:
  Rule that collects the percentage of inbound interface utilization for performance reporting, calculated from the change in ifInOctets in the past polling cycle and divided by the interface speed.
• Collect Interface Out Utilization:
  Rule that collects the percentage of outbound interface utilization for performance reporting, calculated from the change in ifOutOctets in the past polling cycle and divided by the interface speed.
• Collect Cisco Interface Collisions:
  Rule that collects the number of collisions recorded for the interface in the last polling cycle for performance reporting.
• Collect Cisco Memory Pool Utilization:
  Rule that collects the percentage of memory pool utilization determined from the free and available bytes counters, for performance reporting
• Collect Cisco Temperature Sensor Data:
  Rule that collects the reported temperature value of a temperature sensor for performance reporting. 

Views

• Cisco Device Alerts:  Alerts view
• Cisco Device Performance:  Performance view
• Cisco Devices: State view
• Cisco Fans:  State view
• Cisco Interfaces:  State view
• Cisco Memory Pools:  State view
• Cisco Power Supplies:  State view
• Cisco Temperature Sensors:  State view