To manage the bischeck daemon from the bisconf web ui the following configuration needs to be added to the /etc/sudoers file:
nagios ALL= NOPASSWD: /etc/init.d/bischeckd restart
nagios ALL= NOPASSWD: /etc/init.d/bischeckd start
nagios ALL= NOPASSWD: /etc/init.d/bischeckd stop
nagios ALL= NOPASSWD: /etc/init.d/bischeckd pidstatus
Bisconf 0.1.0 must run on the same server as bischeck. Hopefully this may change in the future.
Bisconf, the configuration web UI, is now available for download. The release support bischeck 0.4.0. Documentation is limited but check out the readme for some installation instructions. Looking forward to your feedback.
The second release candidate of bischeck 0.4.0 is now available for download. The 0.4.0 RC2 of bischeck includes the following new features and fixes:
- [FR-197] Support for different and multiple integration with different surveillance and monitoring systems. With version 0.4.0 bischeck is not limited to send data to Nagios. It can now send the data to multiple Nagios servers and to other servers like OpenTSB. This is done by moving server formatting and protocol to server integration classes that implements the interface com.ingby.socbox.bischeck.servers.Server. The server integration is described in the xml configuration file servers.xml. This also means that that some Nagios NSCA specific properties previous configured in properties.xml has been moved to the servers.xml file in the NSCA section. The OpenTSDB server class should be regarded as beta.
- [FR-202] The implementation of running bischeck once, in a none daemon mode, is changed so the same code is used as running in daemon mode. The only difference is that the initialization of triggers are different so all service items are just ran directly and and just once.
- [FR-204] The bischeck cache will be saved when the bischeck daemon is shutdown and reloaded on bischeck startup. Keeping the cache persistent between restarts is important since 0.4.0 support time based cache retrieval. The limitations is currently that if the bischeck daemon is killed by a signal that can not be caught or the daemon crash the data will not be saved. This will be improved in future versions.
- [FR-218] The bischeck daemon can now reload the configuration without a process restart. This is support through the JMX operation “reload”. The feature will limit the need of operating system access and authorization.
- [FR-219] Bischeck can now retrieve state and performance data from a Nagios server supporting livestatus. With the service class LivestatusService a connection is set up over livestatus and with the and serviceitem class LivestatusServiceItem state and/or performance data can be retrieved from the a Nagios service. This can be useful when when creating virtual services in bischeck or used in complex thresholds.
- [FR-220] Bischeck now support one additional scheduling method where scheduling can be defined to run a service after a different service has executed. This can be useful when a service is depending on data for another service for its thresholds or execution statement.
- [FR-221] Cache retrieval is now support by using a time offset to find the nearest cache element to the time offset.
- Cache data can be retrieved as a list of elements based both on index and time.
- Support for additional mathematical functions like average, min and max calculations on list of elements.
- Bischeck can now support the usage of cached data in an execution statement of a serviceitem. This is typical useful when a serviceitem execute statement is depending on other service data. For example in a SQL query string:
select value from table1 where id = host1-web-state and createdate = ’%%yyyy-MM-dd%%’");
- Added support for other Linux distributions then Redhat based. bischeck should now install on Debian 6 and Ubuntu 10/11.
- Configuration listing. The configuration listing has been moved from the ConfigurationManager class to the DocManager class. Currently html and text listing is supported. The generated configuration data will by default placed in the bischeckdoc directory.
- A configured service can be configured not to send its data to a the configured monitoring servers like Nagios. This can be useful if the service is just to be used to create virtual services or just to be used as thresholds.
- The bischeck script now support JMX authentication. The authentication files are located in the etc directory and named jmxremote.password and jmxremote.access. Default is to that authentication is disabled by the system property
“-Dcom.sun.management.jmxremote.authenticate=false”. To enable authentication set the property to true. For more info about JMX see
Bugs fixed and important issues