 |
8th - 11th May | OUCE2012 | OpenNMS User Conference Europe 2012 in Fulda |
|---|---|---|---|
|
23rd - 30th June | DevJam 2012 | OpenNMS best event of the year - One week hacking and coding at the UofM in Minneapolis |
|
26th - 28th June | OUCA2012 | OpenNMS User Conference Americas 2012 in Minneapolis/th> |
Disclaimer: I wrote this post some weeks ago but never got around to finish it. Sadly the migration project is currently delayed and in hibernation mode.
I currently don't know when or if it will continue. Despite that I want to publish what I have done so far...
In the meantime jboss 7.0 and 7.1 went final, but this doesn't change much ... the next Jboss EAP is called 6 (for reasons only known by red hat marketing), will be based on a jboss 7 release (which one exactly is still to be seen) and will be available around June/July.
#########
Hey there,
i'm currently working at a software development and consulting firm and had the oppertunity to do a technical proof of concept with jboss 7 for a client.
The original development project started when jboss4 was just released as community edition some years ago and had a quite fresh technology stack back then. Currently its running JavaEE5 + Seam 1.x and BeanValidation (MyFaces) on a jboss 4 EAP
The scope of the project was to port the core application of a large applicant landscape to JavaEE6 to determn most of the technical pitfalls and do an estimation of the cost to port all the applications.
I would like to share the wtfs and duhs! we encountered in hope this might prove useful to someone.
Here is a summary of the technologie and framework changes we faced:
Frist of all we got ride of all the jboss-* dependencies and replaced them with a provided jboss-javaee6-specs-bom dependency in our root pom. This was quite easy since we didn't use many jboss specific imports.
The old deployment structure was an EAR per EJB-JAR/WAR and used a numerbing mechanism to ensure a correct deployment order relying on the famous unifed classloader. We replaced this was a single EAR module containing all the API-JARs in /lib and all the EJB-JARs and WARs in /.
The we started building find+sed expressions to replace all the annotations, imports and xml configuration that changed.
For Hibernate this was
For converting Seam-Annotations to CDI you can take a look here: http://seamframework.org/Seam3/Seam2ToSeam3MigrationNotes
For persistence.xml
For ejb-jar.xml
All the @LocalBinding got removed see http://docs.oracle.com/javaee/6/tutorial/doc/gipjf.html
After all these replacements we had an almost buildable project. Since we have used custom valves in jboss4 and a quite invasiv login implementation we hab to comment out some classes and removed the sso login-module.
I will skip the setup of the standalone jboss with a custom db-driver, because is is documented here: https://community.jboss.org/wiki/DataSourceConfigurationInAS7
Deploying is quite easy and fast in jboss 7 with the new jboss-as maven plugin. Just type maven jboss-as:deploy and watch the magic.
Not so easy is detecting the cause if the deployment fails.
Jboss 7 does a nice job validating your deployment but the error messages are not always helpful and you need some time to learn to decrypt them. In truth jboss7 probably is this fast at startup because it checks some constraints and initialises only the really necessary parts of the server and all the application. You will notice quite a delay when accessing your application for the first time. The jboss guys obviously are huge fans of lazy loading.
When deploying our application we had three major problems:
First one was a jar without an persistence.xml which contained a class with JPA annotations. The class was never used inside the jar, never the less jboss7 doesn't like that. FIXME log-msg So we moved it to the only module depending on it.
Second one was somewhat harder. The error message look like this:
"Duplicate interceptor class definition when bindingIntereptor@1d2f4 on AROUND_INVOKE." Not helpful at all. After some debugging inside jboss I found the problem. There was a class with @Interceptors(FOO.class) at the class definition and @Interceptor(FOO.class) at a method. Some spec probably forbids this, but i didn't checked this. Removing the method interceptor fixed the problem. (see https://issues.jboss.org/browse/WELD-1055)
The last one taught me another feature of jboss7. We have ejb modules configured to use hibernate cache which was ehcache back in jboss4. Jboss7 complained because the new cache provider infinispan wasn't configured properly. Removing the hibernate configuration from the persistence.xml didn't fix the problem. The reason for this is, to determine the nature and configuration of a ejb-jar and providing the correct dependencies the deployer not only looks for xml files but it also scans for annotations. So if it finds a caching related annotation it tries to start the cache and fails. Only after removing the annotation the deployment was successful.
Because all our EJBs run secure we had to replace the jboss.xml file in all the EJB-modules with a jboss-ejb3.xml. The structure and the
.xsd of this XML is somewhat crazy/fucked and not documented. On top of that jboss7 doesn't valid it (https://issues.jboss.org/browse/AS7-3570). So you end up with NPEs inside Jboss if you are missing something. Since I couldn't find a valid and deployable example I will provide one here: FIXME
Since I'm at it ... one of my co-workers helped out and provided a JAAS LoginModule. After we got the login and secure EJBs running we noticed a huge performance drop. Problems is: jboss7 doesn't cache it's authentication and calls the LoginModule on every EJB-Call. Here is the issue for that https://issues.jboss.org/browse/AS7-3498. Hopefully this will be fixed in jboss7 EAP or even the next jboss 7.1.0 release.
When we tried to call our Webservices which are inside EJB-JARs and use the jboss annotation @WebContext(context="/ws/",auth="BASIC")(org.jboss.ws:jbossws-api:1.0.0.Beta1 org.jboss.ws.api.annotation.WebContext) to add the context and authentication, we always got a 403 response. After some debugging of jboss security it turned out we were authenticated correctly, but to get access to a resource like a webservice the resource has to have at least one role. Since we don't have a web.xml in our EJB-JAR to define a role, it didn't had one. So we put @RolesAllowed at the webservice
class and vola! Sadly the tomcat/catalina-code doesn't handle this case at all so no logging there (https://issues.jboss.org/browse/AS7-3664).
to be continued, perhaps ...
My friend and workmate Markus wrote a really nice tool to create massive JMX data collection configurations for OpenNMS. The basic idea is to have something like a SNMP walk for JMX. The really really cool thing is, the tool can generate the whole jmx-datacollection-configuration.xml and creates also RRD/JRobin graphs. So if you want to monitor your Java application environment you will become a very handy tool to generate the OpenNMS configuration to gather tons of deep application metrics. AWESOME and all the fame to Markus ;) The internal name for the project was "JMX-Saugblaser" was his homage to Loriots brilliant "Vertreterbesuch". The awesome original marketing speech:
"Es saugt und bläst der Heinzelmann, wo Mutti sonst nur saugen kann."
Unfortunately our friends of the states called it Sausageblaster so it becomes quite a different but also funny name ;) Ah and btw. it's getting better, there is a Wiki-page with documentation!
So have fun a don't forget to contribute your new JMX graph configs in http://issues.opennms.org
With 1.10 it is time to renew the virtual machine. I’ve got a few requests for a 64bit virtual machine, so I’ve reinstalled the whole VM with a new Ubuntu 10.04.4 LTS 64bit. You can download the VM from the file section on Sourceforge. Unfortunately I got a request from a community member for a 32bit version. So I’ll give a short tutorial to upgrade the old one from 1.8.16 1.8.14 to 1.10. It is not a big deal.
1. Login as root with password evaluation and refnew the GPG key from the OpenNMS debian repository with:
wget -O - http://debian.opennms.org/OPENNMS-GPG-KEY | sudo apt-key add -
2. Update the aptitude repository and upgrade the Ubuntu to latest version (~290MiB)
aptitude update && aptitude dist-upgrade
yesusers.xml. If not, the preconfigured user accounts with mail configuration will be lost./usr/share/opennms/bin/install.sh -dis
aptitude install open-vm-dkms
there was blog, created to tell people working with and around open source software. It seems the author of the blog was sucked into a deep dark black hole and was never seen again, but wait …
Ok, I'm quite back from a few really cool weeks or better months of work, conferences and geek fun. The reason to switch this article to bad east german school english is a short review about our talk at FOSDEM 2012 in Brussels – so sorry for that ;) All the stuff started with Jeff Gehlbachs and Jason Aaras idea to wire Puppet – a system and configuration management tool – and OpenNMS. The two guys came up with two nice use cases to improve the maintenance workflow for configuration and network management. Jeff asked me if I was interested to jump on the train and so now we are here …
Together, we wrote a proposal for a talk in the DevRoom for System and Configuration management which were organized and managed from the Puppetlabs guys. Jeff wrote a nice abstract with two common and as we thought, useful use cases. The first one is using Puppet as a source for node information for network management. The second one vice versa, using OpenNMS as source for node information for the system and configuration management with Puppet.
We split up the work, Jeff is working longer than me in and with OpenNMS so he gave a nice overview about OpenNMS in general. He went down the path together with Jason Aaras, an OpenNMS OGP and a also a contributor in Puppet, to export node information into Puppet. I tried the other side to import node information from Puppet into OpenNMS. As integration for automatically node synchronization, we used the ReST based provisioning API from OpenNMS and the ReST API from Puppet to make it smooth as possible.
So now some experience, what happen if you throw a guy on the problem: “Hey, I want to synchronize my Puppet nodes with OpenNMS!” In both applications, Puppet and OpenNMS providing a ReST API which makes the integration quite easy. As an absolutely Puppet-n00b I started with puppetizing all my Linux machines. I installed Puppet master on a Ubuntu 10.04 LTS with aptitude which was quite easy. Beside some Debian/Ubuntu machines I had also a Fedora and Centos box running. So I had enough toys to play with. It was absolutely no problem to install the Puppet agents, the packaging in Debian/Ubuntu and also the RPMs work as suggested. After doing all the certificate-kung-fu to register my Puppet agents on the Puppet master, everything worked fine. To have a more responsible playground I shortened the polling time from my agents for the configuration packages. So now we can start simple and investigate the ReST API from Puppet with cURL. It didn't take such a long time and I would called it - I felt in the "YAML situation" (with honor to the famous "Bonnie situation").
Puppet is using YAML as document description language to provide his data. I tried to change the accept type to my favorite ones like XML, JSON and pure TEXT with no luck. It was stupid – I should change my behavior from guessing to read docs :) I started reading the docs and figured out, Puppet will provide PSON, which means JSON output. Sorry for the rant but I don't understand why it is necessary to re-implement a already common description language and rename it from JSON to PSON?! I didn't get it. Unfortunately, not all ReSTified methods produce P … JSON output :S The YAML output was quite straight forward and so I decided to went down the path and gave YAML a try.
I searched for a library to allows me to process YAML In good old Java. If you search for YAML and Java you will find four projects. Two of them are dead and the two left where snakeYAML and yamlbeans. I gave snakeYAML a try – in believee on "trusty and reliable" stack overflow references ;) Trying to parse a simple node list from YAML to a Java ArrayList failed with a strange Exception. I put my plaintext output on the snakeYAML mailing list and few hours later I got a high quality reply – it’s not a joke it is true, snakeYAML(karma++). The problem wasn’t the snakeYAML API, it is Ruby. Puppet is written in Ruby and the YAML output from Ruby isn't programming language independent. Every output starts with !ruby/ which you have to strip off. Yeah, Now I was able to parse a simple YAML array to a Java ArrayList. *phew* Sorry, I know YAML should be a good choice for all the XML haters out there but I cannot understand why Ruby provides language specific YAML documents – fail in my point of view, but nevertheless. I investigated the puppet node model and it wasn’t possible for me to find a schema to get in idea to parse it in a Java Puppet node model. So, life is a compromise and I parsed it in a HashMap to avoid duplicated properties. This is the point where the current implementation lacks :/ This is the point where we can say, ok the implementation works but it is not pretty – A horrible situation for Germans with “German engineering in mind” :)
After creating the prototype it was time to create the slides and make the talk. The room was good filled with round about 80 guys. I tried to find a way to explain on the Puppet example what is necessary if you want to integrate your system and configuration management tool into OpenNMS. So the slides have also a lot of pseudocode and I tried to explain it from the OpenNMS point of view. If some one wants to integrate Chef, he should have a very good starting point. Nigel who works for Puppetlabs came up with an very interesting question: “What is the holy grail? Do you think the System Configuration Management should be the source nodes or should it be the network management?” Yes answering with: “It depends” is a valid answer but we tried to see it from a more objective perspective. I can understand if someone choose the System and Configuration Management for the source, cause in real world the need to be able to manage servers comes sometimes first and the network management follows. What I’ve seen during my work was also it is sometimes not enough to have just one source for nodes. I guess it should be easy to find a use case where not all nodes for the network management are in Puppet. I spent some time on this thought, cause the question is really interesting in my point of view, but this is another blog entry.
We had very interesting and nice discussion after the talk and two guys helped us with very good Puppet Pro tips to make it better and to finish it up. One of them is Maarten a Java pro who works for Filterworks in the Netherlands and the other one is Brice from France who has very deep knowledge of Puppet. With Maarten we had a really nice G+ hangout a few weeks later and he was able to help us to investigated a little deeper the Puppet PSON issue.
I had a really cool time at FOSDEM 2012. Meeting people from all the Open Source projects you love on one place is so cool. Having a non-profit conference at the Universite Libre Brussel without complicated registering and entry fees it is absolutely awesome. A big thank you for the stuff and the volunteers to make such a great conference happen. With 24 tracks in parallel over two days, there is not so much time for socializing, but we were able to find some time for good coffee, belgian beer and nice people – thanks to the world wide web and video streaming :)
So mittlerweile bin ich wieder zu Hause und erholt von zwei interessanten Tagen in Nürnberg auf der OSMC 2011. Ganz besondere Grüße an dieser Stelle gehen an die anderen aussässigen Sprecher: Reinhard Scheck mit Cacti, Remo Rickli mit NeDI, Dr. Michael Schwartzkopff mit SNMPv3, Georg Kostner mit Syslog, Roland Huß mit Jolokai und Sebastian Harl mit collectd. Vielen Dank dass ihr das doch recht Icinga und Nagios lastige Programm aufgelockert habt. Von 23 Vorträgen inklusive der Begrüssung gab es 7 Vorträge die nichts mit Nagios oder einem Nagios-Fork zu tun hatten ;) Die Highlights für mich auf der Programmliste waren:
Ich hatte schon einmal das Vergnügen in Forschungsprojekten mitzuarbeiten. Dabei ging es auch um die Leistungsfähigkeit von Open-Source Monitoringanwendungen. Daher habe ich mich auf den Performance-Vergleich von Nagios, Icinga und Shinken besonders gefreut. Zudem war ich gespannt wie sich die beiden Forks Shinken und Icinga auf die Leistungsfähigkeit auswirken. Einer der Hauptkritikpunkte der beiden Forks war ja schliesslich, dass im Nagios Core nur schwer oder keine Veränderungen gemacht werden konnten. Es hat mich und vermutlich wie auch viele andere brennend interessiert ob sich die zwei Jahre fork() positiv auf Shinken und den Icinga Core ausgewirkt haben.
Beim Test der Scheduler in Nagios und Icinga waren "leider" keine Unterschiede festzustellen. Es wurde eine Simulation mit bis zu 60.000 "Checks" und zufällig schwankenden Ausführzeiten beschrieben. Der Code der Scheduler wurde in der Ausarbeitung nicht betrachtet. Nagios als auch Icinga zeigten bei der Präsentation ein ähnliches nahezu "gleiches" Verhalten. Shinken hat eine lose gekoppelte Architektur im Kern und zeigte eine wesentlich besseres Verhalten. Damit das ganze für alle drei Tools noch vergleichbar bleibt wurde der Performancevergleich dann mit Nagios + mod_gearman und Icinga + mod_gearman weitergeführt. "Gearman" ist eine eigenständiges Open Source Projekt und stellt eine API bereit um Anwendungen zu verteilen – "Nagios/Icinga-on-Steroids".
Das Ergebnis war wenig verwunderlich, Nagios/Icinga hatten das gleiche Verhalten und waren am Ende, was die Latenz-Zeiten angeht, einen Tick besser als Shinken. Vermutlich ist hier tatsächlich ein kleiner Vorteil der C-Implementierung des Nagios-Core gegenüber Python zu sehen – but who knows. Das Ergebnis, dass die Check-Latenz über der Zeit linear ansteigt würde ich mit einfachen Vermutungen bezweifeln. Die Beschreibung der Skalierbarkeit der Scheduler mit der "Check-Latenz" über der Zeit mit der "Big-O Notation" zu beschreiben halte ich persönlich für gewagt. Laut meinem Verständnis sagt mir die O-Notation in der Informatik etwas über die Effizienz von Algorithmen aus, der Code der Scheduler wurde dabei ja bewusst NICHT analysiert – ich lasse mich aber an dieser Stelle gerne eines besseren belehren. Das fork() aufwändiger ist als Thread spawn oder gar Thread Pools ist eigentlich klar – von daher war ich ein wenig enttäuscht, kritische Objektivität hätte ich mir gewünscht. Ich bin wohl zu viele Barcamps und freie Konferenzen im c4fd Umfeld gewohnt ;)
Der einzige fork() der den Kern von Nagios überarbeitet hat ist meiner Ansicht nach Shinken. Sie haben durch eine komplette Reimplementierung in Python Schwächen bei der Skalierung durch eine andere Architektur angepeilt. Das ganze wurde damit für mich eigentlich erst auf den zweiten Blick deutlich. Was den Inhalt angeht, waren vermutlich meine persönlichen Erwartungen etwas zu hoch, da ich mich mit diesem Thema schon beschäftigt habe.
Bei dem Vortrag "Monitoring at large" wurde dargestellt welche Ideen im Icinga Projekt stecken um das Thema Verteilbarkeit und Skalierbarkeit besser zu adressieren. Vorallem das Thema Queuing mit ZeroMQ scheint einiges an Potential zu verbergen. Im Thema SLA Reporting ging es letztendlich darum wie man die Daten aus einem Icinga Availability Report "parst" und in MySQL und JasperReports auswertet. Ich dachte ich kann mir da an der Stelle etwas abgucken was ich OpenNMS verwenden kann, da war aber nix für mich dabei :) Den Vortrag zu Collectd war sehr interessant und wirklich ausführlich dargestellt. Da in OpenNMS eine ähnliche Implementierung der Datacollection hat, sind die Problemdomänen hier identisch. Jörg Linge hat zudem seinen erfolgreichen "Grapher" PNP4Nagios vorgestellt. So wie ich es verstanden habe, hat der wohl bis jetzt schon so einige Remake Versuche überlebt. Kleiner Tipp, das Projekte einfach in PNP4${fork} umbenennen, dann wird es vermutlich einfacher ;)
Mit Jolokia hat sich noch ein weiteres Projekt vorgestellt, welches sich dem interessanten Thema Java Monitoring annimmt. In dem Vortrag wurde kurz vorgestellt welche Probleme mit JSR-160 und JMX im Monitoring-Umfeld auftreten können. Jolokia schafft hier Abhilfe und stellt einen "einfach" erreichbaren JMX Proxy in die JVM. Das ganze ist unabhängig von der eingesetzten Monitoring-Lösung und damit auf jeden fall einen Blick wert, für alle die sich wie ich in J-Land aufhalten.
Ansonsten kann man grob zusammengefasst sagen, dass das Thema in Richtung mehr "Checks", mehr "Services" geht und wie man das mit Steroiden wie Gearman und ZeroMQ, erreichen kann. Um die CIO`s Happy zu machen ist gerade JasperReports der "Heiße Scheiß". Kann ich ja in einer gewissen Weise auch gut verstehen :) Für mich ist auf jeden Fall Shinken, NeDi und Collectd weiter unter Beobachtung. Icinga gibt mit InGraph ziemlich Vollgas was die Web UI angeht. Das Thema Skalierbarkeit ist meines erachtens momentan mit einem haufen Ideen in der Findungsphase. Bei dem Thema SLA-Reporting bin ich wohl erstmal auf mich alleine gestellt ;) Allen in allem war es eine wirklich angenehme und entspannte Atmosphäre. Die Organisation war absolut perfekt. Man merkt, dass das NETWAYS Team gut eingespielt ist. Ich bedanke mich bei den Organisatoren für die gelungene Konferenz, den regen Erfahrungsaustausch und dass ich die Gelegenheit hatte viele Menschen mit einem Vortrag zu OpenNMS zu quälen ;)
So Long, and Thanks for All the Fish
Links zum Thema:
So bald ist es wieder soweit, Die NOP 2011 findet im N-Gebäude Hochschule Fulda statt. Die NOP ist eine freie und absolut unkommerzielle Veranstaltung. Studentinnen und Studenten sollen dazu animieren werden Themen oder Projekte vorzustellen, die Sie besonders interessieren. Auf der letzten NOP waren einige sehr coole Projekte aus den Fachbereichen der Elektrotechnik und Informatik zu bestaunen die neben dem Studium enstanden sind. Ich hab die extrem entspannte Atmosphäre genossen und werde auf jeden Fall wieder dabei sein. Die aktuellen Themen sehen momentan wie folgt aus:
An Ständen werden die folgenden Projekte vorgestellt:
Wer interesse hat, findet noch ganz viel mehr Informationen auf der offiziellen Website bei http://nop.hs-fulda.org
Ich kann es einfach nicht verstehen warum es so kompliziert ist Microsoft Windows Systeme mit freien Netzwerk Management Tools zu monitoren. Ich habe hier gerade ein Netzwerk mit knapp 50 Windows 7 Enterprise x64 Betriebssystemen vor mir. Ich habe mich aus diesem Grund mit dem Thema Windows Management Instrumentation (WMI) auseinandergesetzt. Als allererstes ist mir aufgefallen, dass WMI standardmässig remote nicht aufrufbar ist. Es hat mich einiges Registry-gefrickel, DCOM Konfigurationsgeklicke und Nerven gekostet bis ich WMI von einem entfernten Server abfragen konnte. Ich kann jedem Leidensgenossen das Troubleshooting WMI Dokument der Spiceworks Community ans Herz legen – dickes DANKE! Mit diesem Dokument hat man eine echte Chance WMI und OpenNMS konfiguriert zu bekommen.
Das ganze Thema ist in OpenNMS recht unspektakulär. In der Datei wmi-config.xml muss die Authentifizierung eingetragen werden:
<?xml version="1.0"?> <wmi-config retry="2" timeout="1500" username="${login}" domain="${workgroup}" password="${pass}"> </wmi-config>
${OPENNMS_HOME}/bin zum testen her nehmen.checkwmi -matchType all -wmiClass Win32_BIOS -wmiObject Status -op EQ -value OK -domain . ${ip} ${login} ${pass}
Checking: for Status Op: EQ Val: OK Check results: OK (1) Result for (1) Win32_BIOS\Status: OK
Den Detector habe ich für meine Provisioning Group wie folgt angelegt:
<detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-BIOS-Status"> <parameter value="Win32_BIOS" key="wmiClass"/> <parameter value="EQ" key="compOp"/> <parameter value="OK" key="compVal"/> <parameter value="Status" key="wmiObject"/> <parameter value="WMI-BIOS-Status" key="serviceName"/> </detector>
poller-configuration.xml wie folgt aus:<service name="WMI-BIOS-Status" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wmiClass" value="Win32_BIOS"/> <parameter key="wmiObject" value="Status"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="OK"/> <parameter key="service-name" value="WMI-BIOS-Status"/> </service> . <monitor service="WMI-BIOS-Status" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/>
collectd-configuration.xml für den WMI-BIOS-Status die WMI-Datacollection. Wichtig! Darauf achten, dass der status="on" gesetzt ist. WMI ist standardmäßig deaktiviert.
<service name="WMI-BIOS-Status" interval="300000" user-defined="false" status="on"> <parameter key="collection" value="default"/> <parameter key="thresholding-enabled" value="true"/> </service> . <collector service="WMI-BIOS-Status" class-name="org.opennms.netmgt.collectd.WmiCollector"/>
Nach dem beherzten Neustart von OpenNMS sollten jetzt regelmäßig die Leistungsdaten für WMI eintrudeln und hübsche RRD Graphen generieren.
Die Überwachung von Windows Diensten lässt sich jetzt ebenfalls sehr komfortabel umsetzen. Ein Monitor für die Überwachung von Microsoft SQL Server Diensten würde dann beispielsweise so aussehen:
Detector Konfiguration:
<detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-SQL-Server"> <parameter value="Select State From Win32_Service Where DisplayName='SQL Server (MSSQLSERVER)'" key="wmiWqlStr"/> <parameter value="State" key="wmiObject"/> <parameter value="EQ" key="compOp"/> <parameter value="Running" key="compVal"/> <parameter value="WMI-SQL-Server" key="serviceName"/> </detector> <detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-SQL-Server-Browser"> <parameter value="Select State From Win32_Service Where DisplayName='SQL Server-Browser'" key="wmiWqlStr"/> <parameter value="State" key="wmiObject"/> <parameter value="EQ" key="compOp"/> <parameter value="Running" key="compVal"/> <parameter value="WMI-SQL-Server-Browser" key="serviceName"/> </detector> <detector class="org.opennms.netmgt.provision.detector.wmi.WmiDetector" name="WMI-SQL-Server-VSS-Writer"> <parameter value="Select State From Win32_Service Where DisplayName='SQL Server VSS Writer'" key="wmiWqlStr"/> <parameter value="State" key="wmiObject"/> <parameter value="EQ" key="compOp"/> <parameter value="Running" key="compVal"/> <parameter value="WMI-SQL-Server-VSS-Writer" key="serviceName"/> </detector>
Die Konfiguration für die Monitore sieht in der poller-configuration.xml dann wie folgt aus:
<service name="WMI-SQL-Server" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wql" value="Select State From Win32_Service Where DisplayName='SQL Server (MSSQLSERVER)'"/> <parameter key="wmiObject" value="State"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="Running"/> <parameter key="service-name" value="WMI-SQL-Server"/> </service> <service name="WMI-SQL-Server-Browser" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wql" value="Select State From Win32_Service Where DisplayName='SQL Server-Browser'"/> <parameter key="wmiObject" value="State"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="Running"/> <parameter key="service-name" value="WMI-SQL-Server-Browser"/> </service> <service name="WMI-SQL-Server-VSS-Writer" interval="300000" user-defined="false" status="on"> <parameter key="retry" value="2"/> <parameter key="timeout" value="3000"/> <parameter key="matchType" value="all"/> <parameter key="wql" value="Select State From Win32_Service Where DisplayName='SQL Server VSS Writer'"/> <parameter key="wmiObject" value="State"/> <parameter key="compareOp" value="EQ"/> <parameter key="compareValue" value="Running"/> <parameter key="service-name" value="WMI-SQL-Server-VSS-Writer"/> </service> . <monitor service="WMI-SQL-Server" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/> <monitor service="WMI-SQL-Server-Browser" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/> <monitor service="WMI-SQL-Server-VSS-Writer" class-name="org.opennms.netmgt.poller.monitors.WmiMonitor"/>
Der Test von der Kommandozeile mit WQL kann wie folgt getestet werden:
checkwmi -matchType all -wmiWql "Select State From Win32_Service Where DisplayName='SQL Server (MSSQLSERVER)'" -wmiObject State -op EQ -value Running -domain . ${ip} ${login} ${pass}
Die Ausgabe Check results: OK (1) zeigt an dass der Monitor den Status Running zurückliefert.
Prinzipiell bin ich ja echt glücklich, dass Windows sich mit WMI und OpenNMS überwachen lässt. Der erste Pferdefuß kommt allerdings mit Exchange 2007. Dort wurden die WMI Provider nicht mehr implementiert. Alles jenseits Microsoft Exchange 2007 muss mit PowerShell administriert werden. Sorry das ist wieder einmal ein gutes Beispiel für die Kategorie – Proprietäre Managementprotokolle sind beschissen.
Vom zweiten Pferdefuß werden nur die getroffen, die in großen Windows-Umgebungen arbeiten. Die Skalierbarkeit mit WMI ist deutlich eingeschränkt. Wenn man massiv viele Dienste und Leistungsdaten mit WMI überwacht, fällt einem zuerst die große Anzahl von TCP Sessions pro Sekunde und offenen TCP Connections auf dem OpenNMS Server auf. Zusätzlich hat bei mir der Einsatz von WMI gezeigt, dass ich auf dem OpenNMS Server wesentlich mehr Netzwerktraffic sehe.
Das alles hat mich neugierig gemacht und ich habe mir den Verkehr angesehen, der auftritt wenn man den BIOS-Status mit checkwmi abfragt. Das Ergebnis spricht für sich selbst:
Der Kringel da in der Mitte ist übrigens der Request und Response auf den es eigentlich angkommt. Wer also extrem viele Windows Server hat und die Dienste über WMI monitoren will, der braucht echt viel Dampf unter der Haube. Es werden viele Ressourcen für den Verbindungsaufgbau (NTLM-Dialect-Aushandlungs-und-SMB-Session-establishment-Kung-Fu) gebraucht. Eine einzige erfolgreiche Abfrage belegt für knapp 1,6 Sekunden Ressourcen auf dem OpenNMS Server. Ich weiss ich kann mir das sparen aber so sieht das bei einem SNMP Get aus. Von der Zeit brauchen wir nicht reden:
Momentan überwache ich 1098 Dienste und sammle ~4800 Leistungsdaten per WMI ein. Der OpenNMS Server hat damit durchschnittlich 4Mbit/s ein- und ausgehend gemittelt auf 5 Minuten – Echt ein haufen Holz für so eine Spielzeugumgebung.
So long ...
Es wurde wieder einmal Zeit die Virtual Appliance von OpenNMS zu aktualisieren. Neben dem Image für VMware existiert jetzt ebenfalls ein OVA template. Damit sollte einem Einsatz in Virtual Box oder anderen offenen Virtualisierungs-Programmen nichts im Wege stehen. Das Image enthält:
Linksammlung:
Für die Jungs die AKCP Geräte im Einsatz haben, können sich über native Unterstützung der SecurityProbes freuen.
So long ...
Sorry damit ist nicht MAP08 in Doom II gemeint. Ich arbeite hauptsächlich mit Sysadmins zusammen und bekomme hin und wieder die Frage gestellt: "Was ist ein SNMP Inform?"
Ok um das ganze grundlegend zu beleuchten beginnen wir da, wo Dinge beginnen. "Es war einmal ein ..." ok, ok ich fang anders an. Wie wir alle wissen gibt es zwei Möglichkeiten rauszukriegen ob irgendetwas noch so läuft wie es läuft:
Stellen wir uns einmal vor, eine Arztpraxis kommt auf die Idee auf Polling umzustellen? Ich glaube wir wären relativ schnell genervt und wir können nur hoffen, dass die ne Telefon-Flat und eine leidensfähige Sekretärin haben :) Wir als unbescholtene, brave Bürger sind also eher Ereignis getrieben und gehen dann zum Arzt, wenn es uns schlecht geht oder wir keinen Urla ... äh ok nein lassen wir das. Polling kann also nervig sein ganz ohne gehts aber auch nicht. Wenn sich jetzt jemand zuhause die Füsse bricht und vorm Kühlschrank rumliegt, hat er ziemlich viel Glück. Schliesslich hat er was zu essen und kaltes Bier vor der Nase. Zum Arzt gehen kann er dann nicht mehr, Onkel Doc denkt alles ist super und hat die Füsse auf dem Schreibtisch – isses ja auch zumindest so lange das Bier noch reicht. Es kann also von Vorteil sein, dass ab und an mal jemand vorbeikommt, auch auf die Gefahr hin, dass man sein Bier teilen muss – das aber nur am Rande.
Wie uns also der gesunde Menschenverstand mitteilt, hört sich die erste Variante irgendwie aufwändig an. Zwischen extrem lose gekoppelten Systemen – also so lose gekoppelt dass die voneinander überhaupt nichts wissen, ist häufig ausser Polling überhaupt nichts anderes möglich. Bei Netzwerkkomponenten ist das leider häufig so. Damit sich Geräte verwalten lassen hat man sich SNMP überlegt. Der Teil der im Router steckt ist ein SNMP Agent und das was der Sysadmin bei sich installiert um seine Netzwerkgeräte zu überwachen und zu verwalten nennt man Network Management Station (NMS). Anmerkung: Die Abkürzung NMS ist ziemlich überstrapaziert. Häufig versteht man NMS auch als Netzwerk Management System.
Bei der Einführung von SNMP in den 80er Jahren wurden glücklicherweise beide Prinzipien berücksichtigt. Mit unseren tollen Monitoring und Management-Anwendungen können wir jetzt also nach belieben SNMP Agenten "pollen" oder lassen uns bei Bedarf Fehler oder Statusinformationen ereignisorientiert senden - SNMP Traps. Spitze dann ist ja alles super und wir können einpacken und heim gehen ...
... leider nein. SNMP kommuniziert verbindungslos und unbestätigt über UDP. Das bedeutet der SNMP Agent in einem Router kümmert sich also einen Dreck ob die Nachricht auch wirklich beim NMS angekommen ist. Man könnte das Prinzip auch Fire and Forget bezeichnen.
In der IP-Welt könnten wir auf die Idee kommen einen Trap doch einfach per TCP zu versenden – das ganze ist dann verbindungsorientiert und bestätigt. Die Verbindung wird über einen 3-Wege-Handshake aufgebaut, der Trap wird mit bestätigten TCP-Segementen versendet und danach wird die Verbindung abgebaut. Wenn es dem Gerät beschissen geht, dann könnte es möglich sein, dass die Verbindungsverwaltung und Bestätigungen nicht vernünftig organisiert werden kann und es kommt gar keine Kommunikation zu stande. Man braucht also was schlankeres.
Seit SNMPv2 gibt es neben den SNMP Traps – die mit einer Ladung Hoffnung versendet werden – nun SNMP Informs. SNMP Informs sind bestätigte SNMP Traps – WTF? Ein SNMP Agent sendet einen SNMP Inform (InformRequest) an eine NMS. Damit der Agent sicher weiss, dass der InformRequest fehlerfrei angekommen ist, sendet die NMS eine Bestätigung (GET-Response). Falls die NMS den SNMP Inform nicht bestätigt, weiss der SNMP Agent im Router dass er den SNMP Inform noch einmal senden muss. Das ganze läuft ebenfalls über das schlanke und overhead-arme UDP. Soweit so gut aber woher weiss der Router nun eigentlich welcher konkrete InformRequest bestätigt worden ist? Ganz einfach, das NMS bestätigt den Eingang eines SNMP Inform mit einer GET-Response Nachricht mit genau dem gleichen Inhalt an den Router zurück. Damit weiss der Router, dass genau diese Nachricht mit all ihren Inhalten erfolgreich angekommen ist oder nicht. Das NMS plappert also einfach den Inhalt des eingegangenen SNMP Informs in einer GET-Response Nachricht nach – ziemlich einfach und effizient.
Jetzt stellt sich lediglich nur noch die Frage wo ist der oder die Häken? Prinzipiell kann ich nicht sagen, SNMP Informs sind generell besser als SNMP Traps. Ein SNMP Inform hat auf jeden Fall den Vorteil, dass der Router weiss, dass die Nachricht angekommen ist und kann im Fehlerfall erneut versenden. Netzwerkfehler können also wesentlich besser ausgeglichen werden und die Kommunikation wird zuverlässiger. Die Kehrseite der Medaille – ein SNMP Inform benötigt auf einem Router mehr Ressourcen. Schliesslich muss der SNMP Inform im Speicher gehalten werden und bei Bedarf erneut gesendet werden. Der eingehende GET-Response muss verarbeitet werden und verbraucht damit mehr CPU Zeit. Der Kommunikationsaufwand ist höher, da eventuell neue SNMP Informs gesendet werden und pro SNMP Inform zusätzlich ein GET-Response erzeugt wird.
Ich hoffe damit wurde ein wenig Licht in die SNMP-Trap vs. Inform Thematik gestreut. Wem das alles nich gefällt kann ja dann noch Syslog machen aber das steht in einem anderen Blog – Mir isses egal OpenNMS kann Traps, Informs und Syslog ;)
So long ...
