Continuous delivery seems to be the latest craze in the IT business and, naturally, SAP is riding the wave.
While following this process, I faced one mildly annoying caveat: if – during deployment – servers/services needed to be restarted, and if those servers/services were being monitored by some monitoring tool, lots of alerts would be continuously fired and lots of people would continuously receive emails, resulting in continuous frantic phone calls.
In this article I’d like to give you a brief walk-through on how I prevent this situation from recurring all the time. It would be noteworthy at this point, that the monitoring tool in question is vFabric™ Hyperic® (version 4.5.2, to be exact). But even if you’re not using this, the article may serve as an inspiration since other monitoring tools offer similar interfaces as the one I used.
To achieve what I set out to do, I wrote a small “tool” in Java which makes use of the Web Services API which Hyperic® offers. This allows for accessing and updating Hyperic® “inventory” (e.g. servers, services, alerts etc.). The so-called “HQApi Java API”, a set of Java APIs can be downloaded from the Administration tab of the main UI. Anybody interested in the documentation will find it here.
For the actual build automation and deployment, we use Atlassian Bamboo®. The build plan (slightly simplified) looks like this:
The first and last step are where the magic is performed 🙂
The tool is written in Java, so obviously a Java Runtime Environment is required. In our case, this was a given since it is called from a remote build agent, which already requires Java. The aforementioned HQApi Java API also needs to be installed. Ensure that the path to the hqapi’s lib folder and and all the JARs bundled therein as well as the conf folder (which contains a log4j.properties) are on the CLASSPATH environment variable, along with a JAR containing the tool.
Additionally, a user and password for the Hyperic® server are needed, whereby the user needs to have administrator’s privileges.
When all the requirements have been met, you should be able to call tool. Appending the switch –help will display the possible options.
To avoid specifying the connection parameters (host, port, user and password) each time you run the command, you might consider putting these parameters in a file client.properties. For such a file, the following locations are taken into consideration (in the given order):
- the hqapi’s conf folder
- $HOME/.hq/ of the user making the call
Sample content of such a file:
However, the switches –action and –id (the ID of the alert which is to be activated/deactivated), are required. When in doubt, the latter can be found in the Hyperic® user interface:
So, the complete call to disable an alert would be:
java -Dhqapi.logDir=/tmp -cp $CLASSPATH tools.hyperic.ToggleAlert –id=10631 –action=disable
Wrapping it all up (quite literally, actually…)
Since in my case it was necessary to disable/enable multiple alerts, I chose to put all the steps (setting up the CLASSPATH environment variable, looping over a list of alert IDs) into two bash scripts. This simplifies the definition of the task in the build plan:
So, there you have it.
One final remark: find attached the source code as *.txt (which was zipped during upload; file types *.java/*.jar are unfortunately not allowed). Modify to your heart’s content 🙂