Folgende Parameter sollen beachtet werden:

• Ueberwachung von Zope spezifischen Metriken
• Ausfuehren von Control Actions
• Autodiscovery
• moeglichst kein JAVA programmieren

Zunaechst moechte ich die oben aufgefuehrten Punkte und Begriffe erlaeutern. Im Administrationsmenu des Zope Servers, dem Control Panel, lassen sich verschiedene Statusinformationen abrufen und einige weitere Metriken lassen sich durch die Zope API abfragen.  Die Firma gocept aus Halle hat sich darueber schon Gedanken gemacht und ein entsprechendes Plugin fuer Open Source Monitoringsoftware Nagios entwickelt.  Dieses Zope-Product ZNagios dient als Grundlage um die Metriken aus Zope auszulesen.

Unter Control Actions versteht man bei Hyperic HQ das Ausfuehren von beliebigen serverspezifischen Kommandos. Im Hyperic-Universum versteht man unter einem Server eine auf einer Plattform installierte Software. Als Beispiele fuer solche Kommandos kann man z.B. das Reorganisieren einer Datenbank, das Erstellen eines Snapshots einer VMWare Virtual Machine oder den Neustart eines Daemons nennen. Am Beispiel von Zope sollen  folgende Control Actions ausgefuehrt werden:  Stoppen, Starten, Restarten und den Abfragen des Serverstatus des Zope-Servers.

Die Autodiscovery-Funktion ist eine der grossen Staerken von Hyperic HQ, wie auch bereits in einem frueheren Posting beschrieben. Nach Moeglichkeit sollen nach der Installation eines HQ Agent auf einer Plattform soviele Server und Services wie moeglich automatisch erkannt, zum Inventory des Servers hinzugefuegt und ueberwacht werden.

Der oder die installierten Zope-Server muessen auf dem System entdeckt und identifiziert werden. Da es bei Zope-Umgebungen nicht unueblich ist, mehrere Zope-Server auf einer Plattform laufen zu lassen muss hier leider noch haendisch Konfigurationsparameter geaendert werden. Die Autodiscovery-Funktion von Hyperic HQ gibt zur jetzigen Zeit (Version 4.0)  leider nicht her, mehrere Server eines Typs auf einer Plattform automatisch zu “entdecken”.

Nach Moeglichkeit sollen alle oben aufgefuehrten realisiert werden, ohne Java Code zu schreiben und ein handliches JAR-Paket zu schnueren. Stattdessen soll eine einzige XML-Datei ausreichen.

Bei der Plugin-Entwicklung mit Hyperic HQ gibt es zwei  grosse Fehler, die man unbedingt vermeiden sollte.  Ein Fehler besteht darin,  sein unfertiges Plugin  im Server einzuspielen zu testen.  Das Deployment des Plugins in der (womoeglich)  Hyperic HQ Produktitvumgebung sollte zu den letzten Schritten gehoeren. Fuer die Entwicklung und alle Tests reicht ein Hyperic HQ Agent voellig aus !

Der zweite Fehler ist eher eine architekturbedingte Schwachstelle in Hyperic HQ. Wird ein neuer Service in Hyperic HQ Server angelegt, sei es durch manuelles Hinzufuegen oder durch die Autodiscovery Funktion, erfolgt das auf Basis des zum Zeitpunkt des Imports vorhandenen Plugins und dessen Metriken und Funktionen. Sollte man sich zu einem spaeteren Zeitpunkt entscheiden Aenderungen an dem Plugin durchzufuehren, z.B.  neue Metriken  hinzufuegen, so haben diese Aenderungen nur Einfluesse auf Server, die neu in Hyperic HQ angelegt werden.
Da die bereits angelegten Server auf Basis der alten Pluginversion erstellt wurden, werden die Aenderungen nicht wirksam. Die einzige Moeglichkeit besteht darin, die Server aus dem HQ Inventory  zu loeschen und neu anzulegen bzw. den naechsten Autodiscovery Durchlauf abzuwarten. Leider gehen alle bisher erfassten Daten und erstellten Alarme und Verknuepfungen verloren. Daher sollte man bei der Pluginentwicklung darauf achten, moeglichst alle Metriken und Funktionen zu implementieren.

Hier noch ein paar generelle Empfehlungen zur Pluginentwicklung:
Wenn man im Lesen von JAVA Sourcecode geuebt ist, empfiehlt es sich den Sourcecode von Hyperic HQ bereitzuhaben.  Man kann einfach einen SVN-Abzug herunterladen. Aus meiner Sicht ist die Dokumentation auf  den Webseiten von Hyperic und im Wiki recht umfangreich, jedoch ist es manchmal absolut noetig Konfigurationsparameter im Quelltext nachzulesen. Ausserdem hat man dadurch alle bei Hyperic HQ enthaltenen Plugins im Quelltext vorliegen.

Hyperic bietet mehrere vordefinierte Plugins, vielleicht am besten als Plugin Support Classes zu bezeichnen.  Es empfiehlt sich sein eigenes Plugin um diese Helper Klassen zu bauen. Dank dieser Helper Klassen braucht man auch nicht unbedingt Java zu programmieren Ich habe damit begonnen Funktionen und Parameter der Plugin Support Classes zu dokumentieren.

Die Monitoringsoftware Nagios bietet eine Vielzahl an Plugins fuer diverse Software. Um das Rad nicht zu erfinden, nimmt man ein bestehendes Nagios Plugin als Grundlage. Anlaufstelle fuer Nagios Plugins ist nagiosexchange.org

Die ZNagios Erweiterung  fuer Zope liefert unter einer  mit HTTP Authentication geschuetzten URL die erfassten Metriken zurueck. Um die Metriken mit Hyperic HQ zu verarbeiten muessen sie zunaechst ausgelesen und in die   Notation key=value umgewandelt werden. Dazu wird das Hyperic Script-Plugin verwendet. Mit Hilfe dieses Plugins koennen beliebige Programme/Scripte ausgefuehrt werden.  Um die Werte auszulesen kann man z.B.  ein Script um die Programme curl oder wget schreien  oder sich an dem Plugin fuer nginx orientieren und ein in Python geschriebenes Script verwenden.

Die ZNagios Erweiterung liefert die Daten in folgendem Format zurueck:

uptime: 835.0
db-objects: 2719.0
db-stores: 0.0
db-cache-total-size: 52.0
db-cache-conn0-total-objects: 280.0
db-loads: 0.0
db-cache-conn0-active-objects: 52.0
db-bytes: 1370966.0
errors-total: 0.0
db-connections: 0.0
db-cache-target-size: 5000.0
refcount-total: 17193.0

Die Daten muessen also folgendermassen umformatiert werden:

uptime=835.0

Wir gehen mal davon aus das wir uns unter Unix/Linux befinden und das durch einen einfachen sed Kommando erreicht werden. Mit dem Skript ist ein wesentlicher Teil des Zope-Plugins fertiggestellt. Es handelt sich um ein einfaches Shell Skript an das vier Argumente uebergeben werden muessen.

#!/bin/sh
 
if [ $# -ne 4 ]
then
 
exit 0
 
else
 
ZOPE_URL='http://'$1':'$2'/Control_Panel/munin'
 
if
[ -x /usr/bin/curl ]
then
 
/usr/bin/curl -u $3:$4 $ZOPE_URL 2>/dev/null | /bin/sed s/": "/=/
exit 0
else
 
[ -x /usr/bin/wget ]
 
/usr/bin/wget --user=$3 --password=$4 -qO- $ZOPE_URL | /bin/sed s/": "/=/
exit 0
fi
 
exit 0
 
fi
 
exit 0

Die Skript Argumente der Reihenfolge nach: Hostname oder IP-Adresse des Zope-Servers, Port, Nutzername und Passwort.
Der Plugin XML Descriptor sieht zum derzeitigen Stand folgendermasssen aus:

<?xml version="1.0"?>
 
<!DOCTYPE plugin [
  <!ENTITY process-metrics SYSTEM "/pdk/plugins/process-metrics.xml">
]>
 
<plugin>
  <server name="Zope"
          version="2.x">
 
    <config>
      <option name="process.query"
              description="Process Query"
              default="State.Name.ct=python,Args.1.ct=Zope2/Startup/run.py"/>
      <option name="hostname"
              description="Zope IP-address or hostname"
              default="localhost"/>
        <option name="port"
              description="Zope HTTP port"
	      default="8080" />
	<option name="username"
              description="Zope username"
	      default="zopeadm" />
      <option name="credentials"
              description="Zope password"
	      type="secret"
	      default="changeme" />
 
    </config>
 
    <property name="PROC_QUERY" value="State.Name.ct=python,Args.1.ct=Zope2/Startup/run.py"/>
 
    <plugin type="autoinventory"
            class="org.hyperic.hq.product.DaemonDetector"/>
 
    <plugin type="measurement"
            class="org.hyperic.hq.product.MeasurementPlugin"/>
 
 <metric name="Availability"
            alias="Availability"
            template="sigar:Type=ProcState,Arg=%process.query%:State"
            category="AVAILABILITY"
            indicator="true"
            units="percentage"
            collectionType="dynamic"/>
 
    &process-metrics;
 
<filter name="template" value="exec:args=%hostname% %port% %username% %credentials%,file=pdk/work/scripts/zope/zope-stat:${alias}"/>
 
	<metric name="uptime" 
         units="sec"
	 indicator="false"/>
 
	<metric name="db-objects"
	 indicator="true"/>
 
</plugin>

Im zweiten Teil nehmen wir den Plugin Descriptor auseinander. Fortsetzung folgt.

root@domU-12-31-39-00-B5-63:/mnt/hyperic/sigar# java -jar sigar.jar
sigar> version
Sigar version.......java=1.6.2.7, native=1.6.2.7
Build date..........java=02/13/2009 04:05 AM, native=02/13/2009 05:25 AM
SCM rev.............java=ae289d3, native=ae289d3
Archlib.............libsigar-x86-solaris.so
Current fqdn........domU-12-31-39-00-B5-63.compute-1.internal
Current user........root
 
OS description......Solaris 11
OS name.............Solaris
OS arch.............i386
OS machine..........i86pc
OS version..........5.11
OS patch level......unknown
OS vendor...........Sun Microsystems
OS vendor version...11
OS code name........
OS data model.......32
OS cpu endian.......little
Java vm version.....11.0-b15
Java vm vendor......Sun Microsystems Inc.
Java home.........../usr/jdk/instances/jdk1.6.0/jre
sigar> df
Filesystem      Size Used Avail Use% Mounted on      Type
rpool/ROOT/opensolaris 8.6G 2.8G  5.8G  33% /               zfs/local
/devices          0    0     0     - /devices        devfs/none
/dev              0    0     0     - /dev            dev/none
ctfs              0    0     0     - /system/contract ctfs/none
proc              0    0     0     - /proc           proc/none
mnttab            0    0     0     - /etc/mnttab     mntfs/none
swap            1.6G 324K  1.6G    - /etc/svc/volatile tmpfs/none
objfs             0    0     0     - /system/object  objfs/none
sharefs           0    0     0     - /etc/dfs/sharetab sharefs/none
/usr/lib/libc/libc_hwcap3.so.1 8.6G 2.8G  5.8G  33% /lib/libc.so.1  lofs/none
fd                0    0     0     - /dev/fd         fd/none
swap            1.6G  36K  1.6G    - /tmp            tmpfs/none
swap            1.6G  44K  1.6G    - /var/run        tmpfs/none
rpool/export    5.8G  19K  5.8G    - /export         zfs/local
rpool/export/home 5.8G  18K  5.8G    - /export/home    zfs/local
rpool           5.8G  72K  5.8G    - /rpool          zfs/local
mnt             147G 793K  147G    - /mnt            zfs/local
sigar>

Check it out right here:

http://svn.hyperic.org/projects/sigar_bin/dist/SIGAR_1_6_2/lib/

<metric name="custommetric1"
indicator="false"/>
 
<metric name="custommetric2"
indicator="false"/>

Ich weiss nicht ob es unbedingt clever ist, aber ich kenne derzeit keine andere Alternative.
Die Nachteile der Loesung: der Metrikname ist derzeit nicht veraenderbar und allgemein gehaltene Namen wie custommetric2 nicht eindeutig.

activemq alfresco apache bind coldfusion db2 dotnet exchange geronimo glassfish groovy-scripting hqagent hq-internal iis informix iplanet jboss jetty jmx memcached mqseries mssql mysql nagios netdevice netservices ntds ntp oc4j openldap oracle perlbal postfix postgresql resin samba sendmail servlet sqlquery sybase system tomcat vim vmware weblogic websphere xen zimbra

For example on non-MS Windows platforms it makes sense to add the following line to your agent.properties file to blacklist the plugins:

plugins.exclude=exchange,iis,dotnet,mssql

It saves you some memory and maybe some CPU time for autodiscovery every 15 minutes

On virtual guests you could probably add the following line:

plugins.exclude=vmware,xen

Currently only blacklisting of plugins is possible. Don’t forget to include plugins if you change the software set on your server .
If you’re not sure what the plugin is for, don’t exclude it

Okay, this is only a minor release but there are a lot of important bux fixes and since the upgrade process works fine every time I upgraded, I definetly encourage everybody to upgrade their installations. Don’t forget to upgrade your HQ Agents ! You’ll find a list of all Agents with version numbers in HQ Health.

Also included in 3.2.4: Postgres 8.2.3  and Exchange 2007 support

I’ll create some Solaris Packages for the Agent in the next couple of days.

Starting with version 3.2 Hyperic HQ offers a new function called HQ Health. You can find the function in the Administration Menu Administration -> Plugins -> HQ Health

HQ Health offers a lot of metrics like memory usage of the server, information about caching params and load and a complete list of all HQ Agents connected to this particular HQ Server.
If you experience connection problems between HQ Server and Agent or if a platform shows up as unavailable in HQ when it’s definetly available HQ Health is the first tool I recommend you to debug the problem.
HQ Health offers the following informations about connected Agents:

FQDN

This is the identifier of the platform within HQ Server

Address
IP-Address for communication from Server to Agent

Port

Port on Agent side for communication from Server to Agent. Default port is 2144. You’ve to allow connections from HQ Server to the Address and the Port. Check this by run telnet <Address> <Port>  is a good idea. This is an example for a proper connect:

mpluhar@biollante:/tmp$ telnet 192.168.1.114 2144
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^\]'.
GET

Connection closed by foreign host.

If you get a timeout or no connection, check your  HQ Agent configuration and your firewall and network configuration.

Version

Shows the version number of your HQ Agent. Hyperic HQ is backward compatible. So you may run Hyperic HQ Server 3.2.x with 3.1.x Agents, but I strongly encourage you to run the latest version. If you have any problems with Hyperic HQ upgrade Server and Agents to the latest version and check the version of your Agents with HQ Health.

Creation Time

Creation Time shows you the date when you made the initial setup the platform within Hyperic HQ Server

#Platforms

The number of platforms this Agent is collecting data for. For example an agentless device like an SNMP-device is a platform, too.

#Metrics

This is the number of metrics which an Agent collects. Try to balance the number of metrics within different HQ Agents and try to avoid to make a single Agent collect  thousand metrics for all SNMP devices in your network. You create a single point of failure and if the Agent plaform fails, you’re in trouble monitoring the child devices. Furthermore if the host ist not a dedicated monitoring host, you maybe downgrade the performance of other services you’re running on the host.

Time Offset

Time Offset shows the offset in ms between HQ Server and Agent. Time synchronisation on HQ Server and HQ Agents is very important to determine the availability of platforms and services correctly. If you see huge values here, you’re in trouble. Try to setup NTP-daemons on your Server and Agent hosts. Of course, you can monitor your NTP-daemon with Hyperic HQ and fire up an alarm if the offset becomes too big. Single or double digit values are okay. If you see a question mark, your HQ Agent seems to be inactive
Currently with Hyperic HQ 3.2.x it’s not possible to run HQ Agents and Server in different time zones.

Neben vielen Angaben zur Speicherauslastung, Caching und Last ist unter dem Reiter “Agents” eine Liste aller mit dem HQ Server verbundenen Agents, sowie weitere Infos verfügbar.

Diese Infos sind vor allem hilfreich wenn man Verbindungsprobleme zwischen HQ Server und Agent feststellt oder Metriken zwischen Agent und Server nicht übermittelt werden bzw. die überwachte Plattform scheinbar nicht verfügbar ist.

HQ Health zeigt unter “Agents” folgende Parameter an:

FQDN

Der Full Qualified Domain Name ist wichtig, um die Plattform innerhalb des HQ Server zu identifizieren

Adress

Gibt die IP-Adresse an, mit der die Kommunikation vom HQ Server zum Agent erfolgt.

Port

Zeigt den Port an der zur Kommunikation zwischen Server in Richtung Agent verwendet wird. Standard ist hier 2144. Dieser Port muss vom HQ Server aus auf der Agent Plattform erreichbar sein.

Version

Zeigt die Versionsnummer des HQ Agent an. Hyperic HQ ist abwärtskompatibel. Es lassen sich z.B. HQ Agents Version 3.1.1 an einem HQ Server Version 3.2 betreiben.

Creation Time

Gibt an, wann das Setup des HQ Agent der jeweiligen Plattform an den HQ Server erfolgt ist

# Platforms

Die Anzahl der Plattform für die der jeweilige Agent Metriken erfasst. Als Plattform zählen u.a. auch alle Arten von SNMP-Geräte

# Metrics

Stellt die Anzahl der Metriken dar, die vom Agent erfasst werden. Man sollte versuchen, die Last, die durch den HQ Agent erzeugt wird, zu verteilen und vermeiden das z.B. eine Plattform für alle SNMP-Geräte im Netzwerk die Metriken erfasst.

Time Offset

Time Offset stellt die Abweichung in ms von der HQ Server-Zeit dar. Eine genaue Synchronisation zwischen Agents und Servern ist notwendig, um eine korrekte Übermittlung der Metriken an den Server und zuverlässige Informationen zur Verfügbarkeit zu erhalten. Es ist derzeit nicht möglich HQ Agents und Server in unterschiedlichen Zeitzonen zu betreiben.

Die Titel Community Manager kling übrigens sehr spannend.  Man kümmert sich um die Nutzer, schreibt ein bischen Doku und löscht Angebote chinesischer Import/Export Firmen aus den Foren.