graphing ratios based on 2 DS ?

Post general support questions here that do not specifically fall into the Linux or Windows categories.

Moderators: Developers, Moderators

Post Reply
PP-S3
Posts: 9
Joined: Mon Aug 02, 2004 12:32 pm

graphing ratios based on 2 DS ?

Post by PP-S3 »

hi,
i'm interested in graphing ratios with data coming from 2 DS using the same DIM.
unfortunately, i haven't found so far...

of course i could modify the script and create one which does the ratio and so create a nez DIM and a new DS, but then, nothing is really generic anymore if i must create a new DIM for each ratio, isn't it ?

so is it, that i didn't find ?
or
should it be a feature request ?

precise example would be monitoring key_cache usage in MySQL, or see the proportion of slow queries amongs total queries (still in mysql...)

any help or entry appreciated ;-)
melchandra
Cacti User
Posts: 311
Joined: Tue Jun 29, 2004 12:52 pm
Location: Indiana

Post by melchandra »

you could do it with a CDEF. Basically you graph the (from your example) slow and total queries on the same graph. Then you set up this:

slow / (total_all_data_sources - slow) which translates to the following:

Code: Select all

cdef=CURRENT_DATA_SOURCE,ALL_DATA_SOURCES_NODUPS,CURRENT_DATA_SOURCE,-,/
Since the "ALL_DATA_SOURCES_NODUPS" is equal to slow + total, taking ((slow + total) - slow) = total. So then slow / total = ratio.
Dave
PP-S3
Posts: 9
Joined: Mon Aug 02, 2004 12:32 pm

Post by PP-S3 »

ah !
interesting !
so the all_data_sources_nodups sums up data from all data sources *defined in the graph* only ?

because in cacti i have of course other data sources...
ok i'll have a look at this see if i can figure out how to do it from your start.
if i can't, i'll post further.

thanks !

PP
PP-S3
Posts: 9
Joined: Mon Aug 02, 2004 12:32 pm

Post by PP-S3 »

well...
my CDEF is the following (it compares sizes not queries...) :

Code: Select all

cdef=(CURRENT_DATA_SOURCE,1024,*),ALL_DATA_SOURCES_NODUPS,(CURRENT_DATA_SOURCE,1024,*),-,/
and my graph is defined with first item : the total (represent as a line with no color)
2nd item : the number of blocks (thus the *1024) defined with an area and using my custom CDEF definition.....

so far, no graph !!
i yet have to check that the new data i needed is gathered correctly (it should) but if there is something else i missed ?
melchandra
Cacti User
Posts: 311
Joined: Tue Jun 29, 2004 12:52 pm
Location: Indiana

Post by melchandra »

looks good except for 1 thing which I'm not sure if it will make a differance. You are not multiplying your ALL_DATA_SOURCE_NO_DUPS by 1024 like the other things, so that might screw up the calculation. Check the debug output from the graph, and the graph source. If you can't find anything, post both here and I or somebody else can look through it and perhaps spot a problem. A further check would be to verify that cmd.php is actually getting data from the device and updating the rrd files.
Dave
PP-S3
Posts: 9
Joined: Mon Aug 02, 2004 12:32 pm

Post by PP-S3 »

i checked cmd.php output, there was a problem which i corrected, but still no graph

the 2 DS debug outputs look good but the graph debug output shows nothing....
i just have an empty image placeholder + "RRDtool says : " and that's all, no text after that....

what i lack is a CDEF debugger :wink:
i'll try and post something more precise so that you can help me after my lunch (lunch time here ! :D )
PP-S3
Posts: 9
Joined: Mon Aug 02, 2004 12:32 pm

Post by PP-S3 »

so, back now and here is the remainder.

I forgot to explain th *1024 thing...
actually i am graphing (willing to...) the key_cache usage of MySQL.

so on the one hand i get key_cache_size in bytes (fixed value)
and on the other hand i get key_used_blocks..... which i have to multiply by the block_size (in my case fixed to 1024 bytes...) (changing value)

Now with the debug outputs....
here is what i get for my 2 DSs (which i changed 2 minutes ago because they seemed inappropriate) :

Code: Select all

 [i]First DS[/i]
/usr/local/bin/rrdtool create \
/home/www/cacti/rra/localhost_mysql_key_blocks_12.rrd \
--step 300  \
DS:mysql_key_blocks:COUNTER:600:0:U \
RRA:AVERAGE:0.5:1:600 \
RRA:AVERAGE:0.5:6:700 \
RRA:AVERAGE:0.5:24:775 \
RRA:AVERAGE:0.5:288:797 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
RRA:MAX:0.5:288:797 \

Code: Select all

[i] Second DS[/i]
Data Source Debug

/usr/local/bin/rrdtool create \
/home/www/cacti/rra/localhost_mysql_key_buf_size_11.rrd \
--step 300  \
DS:mysql_key_buf_size:GAUGE:600:0:U \
RRA:AVERAGE:0.5:1:600 \
RRA:AVERAGE:0.5:6:700 \
RRA:AVERAGE:0.5:24:775 \
RRA:AVERAGE:0.5:288:797 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
RRA:MAX:0.5:288:797 \
Attachments
definition of item #2 with th CDEF used (cdef is already quoted in the post)
definition of item #2 with th CDEF used (cdef is already quoted in the post)
item2_def.JPG (69.48 KiB) Viewed 1902 times
graph definition (with 2 items)
graph definition (with 2 items)
graph_def.JPG (70.75 KiB) Viewed 1905 times
melchandra
Cacti User
Posts: 311
Joined: Tue Jun 29, 2004 12:52 pm
Location: Indiana

Post by melchandra »

What I said about the 1024 stuff.... if your two stats come is as 2 and 100 (so we should get 2%)

then the cdef does this: 2 / (102 - 2) = 2%

but you are multiplying the individual data sources by 1024, and not the ALL_DS_NO_DUPS, so the cdef now does this (2*1024) / (102 - (2*1024)) = 2048 / 102 - 2048 = 2048 / -1946 = /.9 something. So perhaps that is why it isn't working, you are dividing by a negative number?

What I would try to do, is graph both items as "AREA". No special CDEF or anything. Verify that Cacti can get the data and is updating the rrd files and stuff. Once that is complete, then you can start messing with the CDEF, and if changing the CDEF makes the graph not work anymore, than you know there is a problem with the CDEF.
Dave
PP-S3
Posts: 9
Joined: Mon Aug 02, 2004 12:32 pm

Post by PP-S3 »

well....
once again you're right !! :wink:
looks like one of the values is not correct.....
perhaps one of the DS type chosen is wrong ??

anyway... my blocks*1024 is widely > to cache_size...

and actually cache_size is rather low wrt to what it should be...

i'll see what i can do about it,
thanks again

PP
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest