Skip Menu |

This queue is for tickets about the jmx4perl CPAN distribution.

Report information
The Basics
Id: 67815
Status: resolved
Priority: 0/
Queue: jmx4perl

People
Owner: roland [...] cpan.org
Requestors: work [...] paul.dubuc.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.90
Fixed in: (no value)



Subject: check_jmx4perl memory_pool_base check give CRITICAL stats when WARNING threshold exceeded
With the following MultiCheck definitions, the memory_pool_base check for PS Old Gen returns critical when only the warning threshold is exceeded. Example: CRITICAL - 1 of 24 failed: , [15] CRITICAL memory_pool_base: PS Old Gen : 97.78% used (1.30 GB / 1.33 GB) Since the critical threshold is 99, and the warning threshold is 95, this error should be a WARNING, not CRITICAL <MultiCheck neomon_bss> MultiCheck = neomon_jms_queues_bss MultiCheck = neomon_common </MultiCheck> # Common checks for all servers <MultiCheck neomon_common> MultiCheck = neomon_memory MultiCheck = neomon_threads MultiCheck = neomon_connection_pools </Multicheck> # Memory checks for all servers <MultiCheck neomon_memory> Check = memory_heap(98,95) MultiCheck = neomon_memory_pools_parallel MultiCheck = memory_gc_count_parallel MultiCheck = memory_gc_time_parallel </MultiCheck> <MultiCheck neomon_memory_pools_parallel> Check = memory_pool_base("PS Eden Space",100,100) Check = memory_pool_base("PS Survivor Space",100,100) Check = memory_pool_base("PS Old Gen",99,95) Check = memory_pool_base("PS Perm Gen") </MultiCheck> # Thread checks for all servers <MultiCheck neomon_threads> Check = thread_inc(~:60,~:30) Check = thread_count Check = thread_deadlock </MultiCheck> <MultiCheck neomon_connection_pools> Check = jboss_cpool_available("DefaultDS") </MultiCheck> Perl version: 5.10.0 SuSE 11.1 uname -a Linux mrldev312 2.6.32.24-0.2-default #1 SMP 2010-10-29 16:39:49 +0200 x86_64 x86_64 x86_64 GNU/Linux
There is oviously some flaw in resolving MutliChecks. I will investigate this issue
(hopefully) this weekend and provide a fix for 0.9.1
I found the issue, which was cause by an faulty variable replacement when resolving
check definitions (i.e. in this case both the critical and waring level where set to 
the warning level provided, hence the critical threshold fired).

Thanks for spotting this, this sort of problems occurs when using checks with parent 
definitions which are shifting the placeholders ($0,$1) --> ($1,$2) etc.

The issue has been fixed and pushed to master on github. It will be included in 0.91

 Fixed in 0.91