Skip to Content

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.

Starting out

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:

Screen Shot 2012-12-09 at 19.49.46 .png

The first and last step are where the magic is performed ๐Ÿ™‚

Prerequisites

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.

Usage

When all the requirements have been met, you should be able to call tool. Appending the switch –help will display the possible options.

Screen Shot 2012-12-09 at 20.48.11 .png

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:

host=hyperic.our.domain

port=7443

secure=true

user=hypericadmin

password=password4hypericadmin

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:

/wp-content/uploads/2012/12/hyperic_164221.png

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:

Screen Shot 2012-12-10 at 8.48.51 .png

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 ๐Ÿ™‚

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply