After a little longer than expected, we finally have RC1 of version 1.0.0 available. This is not a production ready version and should only be used for testing. We hope to get feedback and bug reports from all of you who take the time to test.

RC1 does not support upgrade from 0.4.3, but should run with your current configuration files. And if you like to use the existing cached data from your bischeck 0.4.3 you need to migrate it to redis cache as explained below.

Install Bischeck 1.0.0 RC1

Download bischeck 1.0.0_RC1 from gforge.ingby.com. The installation is according previous versions. 

# tar xzvf bischeck-x.y.z.tgz 
# cd bischeck-x.y.z
# chmod 755 install 
# ./install -u #Get usage
# ./install    #Install default
# service bischeckd start    #Redhat/Centos
# /etc/init.d/bischeck start #Debian/Ubuntu

Install redis

First you need to have a redis installation on the server or on your network. We recommend that you install it locally to secure the best performance, but again it’s up to the load and usage pattern.

You can install redis from http://redis.io/download. The current stable version is 2.6.16. Redis may also be supported through your favorite repository, but that’s up to you.

Redis supports many configuration options for replication, persistence, high-availability etc. More information can be found at redis.io.

Connect with redis

Bischeck uses the redis client https://github.com/xetorthio/jedis which is packaged with the Bischeck distribution. Connecting to redis is controlled with the following properties that are defined in the property.xml file.

• cache.provider.redis.server – the ip or name of where the redis service resides, default is localhost.
• cache.provider.redis.port – the socket port where the redis server listens, default is 6379.
• cache.provider.redis.db – default is 0.
• cache.provider.redis.auth – the password to the redis database, default is null.
• cache.provider.redis.timeout – the timeout in milliseconds, default is 2000.

There is also an additional property that can be used with the new redis-based cache and that is cache.provider.redis.fastCacheSize. This parameter defines the number of cache items that for each service definition (host-service-serviceitem) should be held in parallel with the redis cache in the bischeck heap space. If Bischeck finds the data in the fast cache on a read, access to redis is not needed. Data is always written to redis. Running redis on the same server as bischeck does not show any big advantages with fast cache related to response time. Default is 0. 

Migration of 0.4.3 cache data to redis

To migrate the existing Bischeck cache data you must first stop your current bischeck process so the cache data is written to file, default file is /var/tmp/lastStatusCacheDump, and then copy the file to the server where you run bischeck 1.0.0 RC1. The data will be loaded into the redis cache according to what is specified in the properties.xml 

To migrate the data into redis simply run:

$ bin/bischeck migration.MoveCache2Redis -f lastStatusCacheDump

For more options run:

$ bin/bischeck migration.MoveCache2Redis -u

New configuration options

When installing Bischeck 1.0.0 RC1 you will get a set of example configuration files that should work out-of-the-box as an example. The configuration files include examples of most of the new features, such as:

• Service and serviceitem templates in the bischeck.xml
• The servicedefgroup and servicedef template in the 24thresholds.xml
• The use of macros $$HOSTNAME$$, $$SERVICENAME$$, $$SERVICEITEMNAME$$, $$HOSTALIAS$$, $$SERVICEALIAS$$ and $$SERVICEITEMALIAS$$ that can be used every where in the bischeck.xml and 24thresholds.xml.
• The new cache definition that is part of the serviceitem section in the bischeck.xml. The cache directive has two part, aggregation and purge. 

The purge part defines when items in the cache should be deleted. This can be specified as a max count or as “items older than a specified time interval”, like 7 days. 

The aggregation specification will automatically create aggregations from the related host-service-serviceitem. The idea behind aggregations is to use them in threshold calculations, but can be used anywhere a cache expression is allowed. The aggregation will automatically be done on hour, day, week and month level. You can specify different aggregation methods like average, max and min. You can also specify if the data in the aggregation should include weekends or not. Lets say we have a servicedef as host0-rand-number. When we define aggregation with an average method and include weekends we will automatically for the hourly average get a servicedef with the naming host0-rand/H/avg/weekend-number. 

Please review the example files to see more about the options.

The only thing you need to change in the included bischeck.xml is the path to the check_tcp to get the example working.

All your existing configuration files should still work.

Cache query changes

Added support to specify the oldest item in the cache by defining END. This works both on index and time interval, like host-service-serviceitem[1:END] and host-service-serviceitem[-15M:END]

Bisconf

Bisconf is currently not supported due to all the changes in the configuration files.

Important changes in bischeck 1.0.0

• Log4j has been replaced by logback. This means that any log4j custom configuration you have done must be moved to the logback configuration file located at resources/logback.xml.
• The return of data using time interval quires like host-service-serviceitem[-1H:-10H] has change. If  the end time, -10H, is higher then the number of existing items in the cache the oldest item is used. Previous version returned null if no data was found at -10H. If this breaks the logic for anyone, please send me feedback and we will implement a compatibility property. 
• The Java interface has changed for Service and ServiceItem. If you have developed your own code depending on this please check the new interface and fix your code. Questions – send me a email.
• All configuration related classes has moved to the package com.ingby.socbox.bischeck.configuration. That means if you like to run ConfigurationManager to verify the configuration files you have to change the parameter to the bischeck script like$ bin/bischeck configuration.ConfigurationManager -v

Until next time

I hope that this is all you need to get started. Next post will be more of the new prediction functions and the data and naming structure in redis. 

Please share your experience and the bugs you hopefully will have difficulty to find. If you have any question please send a email to bischeck@ingby.com or create a bug report.

Thanks to all that has been contributing with ideas and feature requests.