On Fri, 2019-05-17 at 12:34 +0000, John Horne wrote:
Hello,
Using the Terabithia RPMs, I've been looking at adding a 'DS' override entry to our analysis.cfg file.
I have an entry for a web server as:
DS http tcp.http.https:,,weed.plymouth.ac.uk,.rrd:sec >0.0007 COLOR=yellow
The comparison value (0.0007) was set low just to see that this was working. However, I can't get it to work. The 'http' column remains green, and the text shown of the http response (on the web page) indicates that the time is above the threshold value (e.g. 'Seconds: 0.088597000').
Hello,
Okay, the problem seems to be with the commas in the filename. Within the file 'xymond/client_config.c' exists the function 'check_rrdds_thresholds'. This is used to check the DS rules, and checks the RRD filename against the one in the rule. It does this by calling the function 'namematch' (found in 'lib/matching.c').
However, 'namematch' splits up the filename into tokens based on the comma character. (Not sure why it does this, but I assume the function is used elsewhere and makes sense in those cases.) As such, the filename never matches if it contains a comma character (and mine has several of them).
A short context diff patch is attached, but I'm not sure it's the best. Basically for the 'http' test don't call 'namematch' but call 'patternmatch' instead. This is a similar function (also in matching.c), but doesn't split the filename into tokens. It is usually used for matching substrings, but will work when comparing two full filenames. It also takes care of regex rules. Using it locally the patch seems to work fine.
The patch restricts calling 'patternmatch' only if the DS column name is 'http'. As far as I can tell this is the only time it is required. So it should have no effect if DS is used elsewhere. However, others may be using DS with other column names (I'm thinking 'apache' here), but which also use a filename with commas. It may be that in those cases the bug will reappear unless the column name is also tested for 'apache'.
As always, feel free to modify, or even reject, the patch.
As an addition, I did get the reported limits (&L and &U) reported with the precision (significant digits) as used by the user in the analysis.cfg file. So, in my case, '0.0007' has a precision of 4 set. The default text output when using DS then uses this precision for all values. (It also took care of when exponentiation was used, no leading zeros etc.) This all worked well. However, the value reported for the RRD value (&V) seemed likewise restricted to 2 significant digits. I was loath to change this as it may well break things, and seemed to be similarly restricted (to 2 digits) in more than one place. This then meant that the output would generally look okay except for the reported RRD value. As such I aborted that patch.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.