monitors returning multiple values
Is it possible that a monitor returns multiple values which are then assigned to different "categories" in the chart? I mean, something like one monitor (script), which returns the uptime in 3 values, divided by say a ' ' (space). These values are then taken for the graph immediately. This would have the advantage that I do not have to call the function 3 times to get the values (which is no problem for uptime, I admit, but for more time/cpu/db intensive monitors it would be cool).
No, the gatherer is designed to only take one value in per monitor.
If you're monitoring load average on a linux box (what I assume you mean by 'uptime'), there are SNMP tests for those that we have a template graph you can use to set those up. It will create a graph similar to this
(you're looking for the 'Load Average' graph here the second one down).
Of course, you'll need SNMP setup to gather those values, but we've seen that it's much more efficent to do a lot of monitoring using SNMP than custom scripts.
Yep, I meant loadaverage.
What I am trying to do is to monitor my MySQL DB. I made a graph which shows the distribution of selects, inserts, updates, deletes, ddls and others. Now this requires 6 monitors, each pulling a single value where I actually could return all 6 in one "transaction". This then would be one hit against the DB instead of 6 hits.
Another impact is (although neglectable at my example, but maybe critical on others), that these monitors would not run at the same time. So it would be possible that I end up with a distribution where the sum would be say 101% (because I get data at different times and the single value could have changed over time).
So in this cases it would be great if a monitor could provide multiple results at once, like
> mysqlmon.pl -distr
< 50 10 10 10 15 5
How to implement this though, I have no idea ( Maybe it is possible that at "Add Monitor" you separate the "Graphing options" into "Graphing options return value 1", Graphing options return value 2", ... "Graphing options return value n". Then you store these values at the monitor, in a subtable called "monitor_subvalue" or something like that. Of course you also would have to add a new "section" called something like "return layout" or "return separation". This can be an easy thing, just like that someone has to give a separator (' ' space or / slash), or maybe allow regular expressions like " OK ([0-9]+) UPD ([0-9])+", or maybe C like sscanf style "%d -- %s", or all toghether ) Based on this you can make sections for the "return values", one by one (drop down menu or sections or whatever) (you are much better and much more imaginative (?) in visualisation than i am ) )
At creation of the Graphs you then can choose these subvalues where you now choose the monitor. So actually you then would have to choose the monitor and in a different pop-up the subvalue. (or however you want to visualize this)
On the other hand I am aware that you must make a call keep it simple that "everyone" can use it or make it an "expert" tool. But maybe you can combine this, although I am aware that this is ALOT of work!
This method (multiple return values) also would be perfect for SQL statements, where you get more columns in a query (or multiple rows, but I would maybe not allow that as then you can have 2 dimensions).
Like I said, its quite some work to implement this (I think), so I really would be happy if it would be there but perfectly understand you guys if you dont do it.
While I am thinking about it, another method of doing multiple values could be that you allow it to create submonitors for a monitor. These monitors then would have the same type (script/db) and use the same script, but a different section of the script return value (thus, eg. the second). This would have the advantage that mods to your current data structure would be not as drastic as with the other example, esp not for charts. Of course, every monitor has to know which section of the output it has to take, this can be done again with regexp, sscanf, ...
Unfortunately I have no idea how the gatherer works (maybe its time to look at it, i only have the rpm here), but would it be possible that if you parse/execute such a "master monitor" (doing the gathering), you store the output of the script/db and pass it as an input to the child monitors? Thus, faking script execution. Or maybe not as an input, but when they try to execute their script (which we already executed, as it is the one from the master), you just "ignore" this and pass the return values from the master script to them.
This then would leave you with a change of the monitors (make it possible to add a "child"/"dependant" monitor (aka a link to another monitor) and make it possible to parse the return values (regexp/sscanf)) and a modification of the gatherer like described above.
Still alot of work, but easier than my first approach ) And also better I think, as you can keep your proven concept. On the other hand, not as "tightly integrated" as the first approach and more of a workaround. But still acceptable, i guess.
Man, i really like this program ! )
You've been putting a lot of thought into this!
These are issues that have been plaguing us for a long time. Our primary response to this is limiting the number of script tests used. These tests have probably the highest overhead. Most of our scripts were reading values from a database, which we have dealt with with our native MySQL test type. Unfortunately, when using MySQL tests, mysql connections are created when each monitor is run, and only one useful value can be retreived per query, because a monitor can only handle one. Certainly not an efficient approach.
I have been considering a "submonitor" type of feature. It may be more logical to have "tests" be performed, with "tests" having multiple monitors. I'm not yet sure, and this probably won't be a priority for us in the near future because as inefficient as running the multiple queries or scripts is, our installations have an incredibly small percentage of these tests, making their overall cost minimal.
Sorry, but you'll have to wait for now ;)
Was afraid of that answer, but I have to appreciate that it IS alot of work!