Looks like Matt replied to me off-list in the hope he could avoid making me
look like an idiot. And here I thought he was going to be a few days
behind in his e-mail... Little does he know that I actually *am* an idiot.
So I will shovel his response onto the list. For those of you who are new
here, never take my word over Matt's - he's spent way more time looking at
this code than I have. :)
<quotage author="guy_who_wrote_the_monitoring_core" answertype="more_correct">
the mcast_min and mcast_max values are really just a time threshold. if a
multicast message for the value of that metric has not been sent between
mcast_min and mcast_max.. it will be sent.. regardless of its value.
the check_min and check_max are exactly what you say they are. they
define a random range in which the metric function is called. one
important thing you left out is that the value threshold is used by the
scheduling thread to determine if, based on the return value of the
function, the value should be multicast. if the value is multicast then
the mcast_min/max threshold is reset.
the check_min/max values are lower than the mcast_min/max values... since
i don't want to force multicast messages too often. to be honest.. the
only reason i even have the time threshold at all is that it is possible
that very small changes in the same direction (below the value threshold)
could go unnoticed.
here is your example...
check_min = 10 ... check_max = 20
mcast_min = 120 .. mcast_max = 150
threshold = 5
0:00 force_multicast = time_now + (a random value between 120-150)
0:00 widget_temperature_func() run and value is multicast
0:12 widget_temperatute_func() executed
if( (return value > threshold) || (time_now > force_multicast) )
{
multicast the value
force_multicast = time_now + (a value between 120-150)
}
else
do nothing
0:31 widget_temperature_func() executed
if( (return value > threshold) || (time_now > force_multicast) )
{
multicast the value
force_multicast = time_now + (a value between 120-150)
}
else
do nothing
</quotage>
Steven Wagner wrote:
All those values are in seconds.
The mcast_min/max values specify the range (randomly determined on each
round of execution) of interval between TRANSMISSIONS of the metric.
The other two values specify the range of the interval between
COLLECTING the metric (i.e., executing METRICNAME_func).
For example, you add a new metric called widget_temperature. You set
the check_min as 10 and the check_max as 30. You set the mcast_min as 5
and the mcast_max as 15.
After each execution and multicast of this metric, the monitoring core
will randomly pick a number between 10 and 30 to wait before running
widget_temperature_func() again, and a number between 5 and 15 before
sending whatever metric value that function last returned.
So on an example run:
at 0:00, the monitoring core executes widget_temperature_func() and
multicasts the result.
at 0:08, it multicasts THE SAME RESULT again.
at 0:16, it multicasts the same result a third time.
at 0:19, it runs widget_temperature_func() and stores the result.
at 0:24, it multicasts the new result.
at 0:31, it multicasts the new result again.
at 0:37, it runs widget_temperature_func() again.
at 0:40, it multicasts the third result.
etc.
If you plan on using it, don't forget to modify the gmetad reporting
interval as well. I don't know how well RRDs react to being modified
every second (or even close to it). I bet the result is a lot of
"fuuuuuuuuuun."
And I think we all know by now that when someone uses that many "u's" in
"fuuuuuuuuuun," they aren't using the common definition of the word. :)
Michael William Knop wrote:
I would like gmond (2.5.0) to monitor at a faster rate. The output from
gmond indicates that it is reporting every ten seconds (REPORTED
attribute
in HOST). I'd like to bump that up to every second.
I remember a message some weeks ago talking about mcast_min and
mcast_max in
metric.h in $GANGLIA_SOURCE/gmond. Looking at that array, it is
unclear to
me how the values interact or what units they might be in.
Could someone point me to documentation on this or give me a quick
explanation so I can play with the values safely and knowledgably?
Thanks for your time and effort.
--
Michael William Knop
"Teach them politics and war so their sons
may study medicine and mathematics in order
to give their children a right to study
painting, poetry, music, and architecture."
John Adams
----- Original Message -----
From: "Steven Wagner" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, October 07, 2002 11:25 AM
Subject: Re: [Ganglia-general] update rate
[EMAIL PROTECTED] wrote:
Orest.
Does ganglia toolkits have posibilities to slow down
database updating rate not 15 seconds but 30 (60 ) ?
If you find metrics are updating too often, you can modify the values in
$GANGLIA_SOURCE/gmond/metric.h (look for mcast_min and mcast_max).
If you're specifically worried about gmetad's writing to RRD files
all the
time, then you can modify the gmetad source in
$GANGLIA_SOURCE/gmetad/data_thread.c ... there's a value in there called
sleep_time which is defined as "a random value between 10 and 20
seconds."
We know, it should be a config value or something...
Note that lengthening the time between updates *too much* may create
gaps
in your graph output. If you care about that sort of thing. :)
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Ganglia-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Ganglia-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Ganglia-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general
