Bischeck 1.0.0 will include a number of new features and enhancements. The plan is to get a release candidate out in the end of the summer. Thanks to all the people that used Bischeck and given feedback and provided feature requests.

The new features listed below are what we have in scope, but it may change or be moved to future releases.

• The default historical cache will be implemented with the Redis data store.  This will improve the number data items that can be stored without affecting heap space, improve data persistent and will enable a simple access for other tools to access the data through the Redis API. It also support network access so the Redis process can run on a remote server. The current cache implementation will still be support. 
• Configuration templates. Templates can be used for services and serviceitems so the configuration can be used in multiple locations of the bischeck.xml. This will decrease the configuration burden. With templates we also introduce a number of macros for host, service and serviceitem names to be used in the templates but also in normal configuration. In the below service template example the $$HOSTNAME$$ macro in the execstatement will be replaced with the name tag from the host section from the context where the template is used.

   XML | 
   
   copy code |
  ?
  
  01
  02
   <servicetemplate templatename="sshport"> 
  03
    <name>sshport</name>
  04
    <desc>ssh port service</desc>
  05
    <schedule>1S</schedule>
  06
    <url>shell://localhost</url>
  07
    <serviceitem>
  08
      <name>response</name>
  09
      <desc>Response time for tcp check</desc>
  10
      <execstatement>{"check":"/usr/lib/nagios/plugins/check_tcp &minus;H $$HOSTNAME$$ &minus;p 22","label":"time"}</execstatement>
  11
      <thresholdclass>Twenty4HourThreshold</thresholdclass>
  12
      <serviceitemclass>CheckCommandServiceItem</serviceitemclass>
  13
    </serviceitem>
  14
  </servicetemplate>

   

• Automatic aggregation of collected data. This is done by an optional configuration on each serviceitem in the bischeck.xml. It will be possible to define that the data should be aggregated on hour, day, week and/or year interval. The aggregated data will be accessible in the same way as any other data from the cache, but with the exception that it will have a postfix to indicate the aggregation interval and aggregation method, like host-service-serviceitem/H/avg. This example aggregate on hour level with the aggregation method average. The mathematical function to aggregate that initially will be supported are average, max and min. Max and min is not really an aggregation since it will only extract the max or min value in the interval defined.
• Prediction and forecast functions. These functions provide prediction calculation based on the “ordinary least square” method. The functions can be used in any places where mathematical functions can be used in Bischeck. The format is:
  

  ols("host","service","serviceitem","AVG","D","10","-30D")

  
  This means that the function will calculate the forecast value for host-service-serviceitem in 10 days based on the data from now and 30 days back in time. It will use an average calculation for all the the data on the day interval. Other methods then average are MAX and MIN. Interval resolutions other then day (D) are hour and week.

  The function olss() will calculate the current slope of the trend and can be used to understand how fast or slow something change.

• Cache purging. It will be possible to define how much data will save in the cache on the granularity of a serviceitem. Default will be no purging or the value set by the property. The purging will also be possible through the redis api.
• Server integration with the cloud service Librato Metrics.
• New cache query directive END, that the define the last item in the cache. This work for index and time query like host-service-serviceitem[10:END] and host-service-serviceitem[-1H:END] 
• In the previous version the ServiceJob thread executed the whole flow from collection, caching, threshold calculation and server integration. With version 1.0.0 the server integration is done by a separate thread pool. The communication between the ServiceJob and the server integration threads are implemented as asynchronous message supporting full concurrency. The implementation is done with jetlang. This should improve throughput especially when the server integration is slow. In the future we are also looking at provide a batch interface so the integration against a server are only done based on time interval and/or when a certain number of data exists. 
• Logback will replace log4j. More logging options then log4j and better JMX support.
• Internal Bischeck surveillance to monitor and report the internal state of what goes on inside Bischeck. This information can be sent to the server, like Nagios, as any other data. 
• Mathematical function that follow the JEP structure can now be developed and put in the customlib directory for automatically class loading.
• Release note will be separated from the manuals.

If you have any questions or feedback in the features please send us a email at bischeck@ingby.com or create your own feature requests at gforge.ingby.com.