I modified the package some weeks ago, The new version includes a check for temperature of each unit in a stack. I have uploaded the package to Check_MK Exchange site lately. It should become available after the verifitcation soon,
Those of you who are suffered by the issue with duplicated service description, which is caused by a conflict of two different named checks: one built-in in Check_MK starting from 1.2.8 and one of mine.
This special version has other service descriptions and check names. The functionality is the same as in the version 2.3.
You can download the Check_MK package at the temporary place.
Update: After Robert had reported that the new version didn’t work under 1.2.8 and 1.4 versions of Check_MK, I have figured out that the plugin didn’t work (ran into an exception) because of a change between the versions 1.2.6 and 1.2.8 of Check_MK: the global variable nagios_state_names was renamed in core_state_names. Therefore I’ve created an updated version and am waiting for a confirmation, if this new version is working.
I have just uploaded a new package onto Check_MK Exchange. The package contains 2 checks for DELL N1500, N2000 and N3000 series switches. They check CPU utilization and RAM usage using SNMP requests. The checks have been created under 1.2.6 version of Check_MK and support this version.
After a verification by Check_MK staff the package can be downloaded from Check_MK Exchange web site.
Once again I have uploaded a new version of the Fortigate Check_MK plugin to Check_MK Exchange. The new version 2.3 got a new check called fortigate-wlan-info. This check is intended to display the following information about the usage of Fortiinet Access Points (FAP), connected to the monitored Fortigate:
- Number of active FAPs
- Numer of missed FAPs or those in down state
- Numer of mobile clients connected to all FAPs
The new check has a Perf-O-Meter as well as an adjusted PNP4Nagios template.
The new vesion of the plugin can be (hopefully soon) downloaded from Check_MK Exchange.
the only change is related to the check fortigate_mem. I have changed the evaluation of the parameters in the check. Now it’s possible to set warning and critical values in WATO. The old version did’t work and raised an exception.
I have uploaded the new version to Exchange of Check_MK. It should become available shortly.
I confirm: the old check created some time ago (see this article) doesn’t work for Exchange 2013 installations. It seems to be be caused by significant changes on Powershell calls or cmdlets. I am having some troubles to get rid of the issue because I stepped away of Exchange business some time ago. A friend of mine is helping me to make the script working and I’ll hopefully publish a new version for Exchange 2013 very soon.
it’s at the time to share my experiences with the monitoring of Citrix Netscaler with Check_MK (below called CMK).
The so-called innovation release of CMK 1.2.7i contains some checks for Netscaler that are based on SNMP: Continue reading
I’ve updated the package to the version 2.2.3. Please consider updating to the new version some time. The change concerns only the check fortigate_ipsec and corrects a bug, that can cause an issue, when a IPSec tunnel doesn’t exist anymore. In this case the check can disturb the execution of other checks and make it not possible to re-execute the inventory.
The new version 2.2.3 is located as always on the check_mk exchange site.
again there has been a bug in the OID in the check fortigate_sessions. Or maybe I didn’t create the package carefully enough. Anyway there is a new version 2.2.2 and it’s located as always on the check_mk exchange site. Please consider updating as soon as possible, because the version 2.2.1 collects wrong values.
I hope you enjoy the great monitoring software Check_MK. If you have a big environment with lots of hosts and services distributed over dozen of sites (company locations) , you might have already configured your Check_MK to use the distributed monitoring in WATO. I assume that you have got a master and some slaves. The master in terms of Check_MK is the host, which you are using to configure your whole Check_MK installation and to look at all hosts and services, whilst slaves are those hosts that receive the configuration from the master and which the master gets the monitoring results from. Distributed monitoring is an extremely nice and powerful feature of Check_MK that allows you to keep your configuration at one place and that takes care on distributing the changes on the configuration to the slaves. Also it’s very easy to connect a new slave to the master site.