Status update on Bischeck 2.0.0

You probably think there has not been enough news from the Bischeck project during the autumn, but we have not been totally lazy. In August I published a post about the future of Bischeck and some of this is now starting to be ready for release. Our goal is to get a beta version of this work out during Q1 2015.

The new version of Bischeck will be 2.0.0. The reason why we bump up the major version is that we broke some of the data structures we store in Redis, but migration will be available. So what are the new features you can expect in Bischeck 2.0.0?

Bischeck 2.0.0

State and notification

In the previous version bischeck only collected metric, evaluated threshold logic and pushed the result to Nagios or equivalent tools. With bischeck 2.0.0 we have implemented state and notification management. This resembles the Nagios way where you have the concept of hard and soft state.

State changes and notifications are stored in Redis as sorted sets, sorted by timestamp. The sets are prefixed with state/{key} and notification/{key} where the key is the host-service part of the service definition. There is also additional data structures where all host-service’s are stored based on their state. This enables quick look-ups for all host-service’s currently in a specific state, i.e get all in CRITICAL state.

Notification integration

One of the main reason for the additional data structures are that state changes and notifications can be directly integrated with external tools. In 2.0.0 we will support notification integration with Pagerduty and BigPanda.

Before 2.0.0 the only integration was provided by Server classes, i.e. NSCAServer class to integrate passive checks with Nagios. In 2.0.0 we introduce a new interface to support integration of notifications. This integration send information only when notification state changes. This means that services as PagerDuty can be used instead or as a complement to Nagios to manage notifications. Notification classes can be custom developed in the same way as Server classes.

Robustness and thread safeness

Robustness and thread safeness has been improved by using a clear data object separation, using value objects, between the ServiceJob execution and any Server and Notification classes that provide integration, i.e. to Nagios, Graphite, PagerDuty, etc. Since the internal communication between a ServiceJob and the consuming integration classes are based on an asynchronous message passing, jetlang, it is important to use an immutable object when passing the data. This will enable future optimization implemented in Server and Notification classes, like batching of data.

Feature request

Feature requests implemented in 2.0.0 are FR-258 and FR-262 (merged with FR-258) submitted by Pasquale Settanni.

From ant to maven

We have also switched the build process to use maven instead of ant.

BisAPI – rest API for Bischeck

In parallel to the development with Bischeck we started a new project called BisAPI. BisAPI will provide rest API’s to Bischeck data about collected metrics, states, notifications, etc. BisAPI runs as a separate process and connects directly to Redis. BisAPI use the open-source project spark that implement a simple and lightweight web framework. With BisAPI we hope to enable the first step for a Bischeck web UI. If anyone is interested and like front-end development please contact me and I will help you get started.

We will soon release more detailed information about the API’s, but here are some examples that will get all data related to collected metrics, state and notification for a specific key.

http://localhost:9080/v1/metric/:key

http://localhost:9080/v1/state/:key

http://localhost:9080/v1/notification/:key

The key is for metric a full host-service-serviceitem name and for state and notification the key is the host-service name.

All the above API’s can take the following query parameters:

f – filter of the field to be shown in the result, i.e. state, value, etc

q – query based selection, i.e. state==”CRITICAL”&&timestamp>1417997243271. Remember that characters like & and < must be encoded. & (%26) and < (%3C)

from – Start index for the selected result – default 0

to – The end index or offset how many to retrieve, default is 100. If using offset it should be given as +X, encoded to %2BX.

As you can see from above the response json include the following fields:

key – the key that was in the request url

count – the number of items returned in the result section

processingTime – the time in millisecoends to execute the call, not including time in the framework.

result – an array of the entities

link – an array of related links

There will be a number of additional API’s that we will provide more information about soon. Remember this is still in development and may change.

If you like to test BisAPI today you need to checkout the bischeck trunk and the bisapi unstable. As you can see from the bisapi url, BisAPI is hosted on github. The plan is to migrate bischeck to github sometime during the spring.

We hope you like the progress thats been done and the new features that will be available with Bischeck 2.0.0. Input and feedback is always welcome.

We also would like to encourage you to share your experience and use cases with Bischeck to us and the community. As an open-source project we are not “in it for the money”, what drives us if its useful and valuable for you, so please share.