Cacti 0.8.6k Beta 2 Available for Testing

[rony]

It's ok, I'm adding additional LDAP support.

[TheWitness]

08/11/2007 12:00:04 AM - POLLER: Poller[0] NOTE: Cron is configured to run too often! The Poller Interval is '60' seconds, with a minimum Cron period of '60' seconds, but only 122 seconds have passed since the poller last ran.

This seems to be some odd math. As 122 is well above 60, no error message should have been created.

Reinhard

Snake oil and corrected with Beta3.

Larry

[TheWitness]

Now testing on

-bug#0000925: Support for host_* variables in the legend

When adding a new Graph from Graph Management, I found a weird issue. Leaving Graph Template and Host empty and then adding a new Graph Item (goal: manually create an AGGREGATE graph for different hosts and data sources), not a single data source is selectable. Even, when selecting a Data Template, the data source dropdown only holds the "NONE" entry.

Reinhard

On this one. It was related to a change we did to correct some mixups in session naming.

Larry

[TheWitness]

Now testing on

-bug#0000925: Support for host_* variables in the legend

When adding a new Graph from Graph Management, I found a weird issue. Leaving Graph Template and Host empty and then adding a new Graph Item (goal: manually create an AGGREGATE graph for different hosts and data sources), not a single data source is selectable. Even, when selecting a Data Template, the data source dropdown only holds the "NONE" entry.

Reinhard

Reinhard,

This appears to me to be working correctly. However, I did find an issue with Data Sources that was identified via my testing to set this up.

Larry

[TheWitness]

Larry,

I'm in doubt concerning the 1 min polling feature.
Minor issues:
The name of rrd file should perhaps include "1min" to distinguish "old fashioned" files from new ones (This comes into view again when reading the whole post)
Same issue holds for Data Queries "Suggested Named"

Major concern:
The current rra definitions are "compatible" to previous versions, but with regard to rrdtool at least "not optimal" or plainly wrong. Well, the rrd file definition does not fail. But as can be seen from

Code: Select all

rra[0].cf = "AVERAGE"
rra[0].rows = 500
rra[0].pdp_per_row = 1
rra[0].xff = 5.0000000000e-01
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[0].cdp_prep[1].value = NaN
rra[0].cdp_prep[1].unknown_datapoints = 0
rra[1].cf = "AVERAGE"
rra[1].rows = 600
rra[1].pdp_per_row = 1
rra[1].xff = 5.0000000000e-01
rra[1].cdp_prep[0].value = NaN
rra[1].cdp_prep[0].unknown_datapoints = 0
rra[1].cdp_prep[1].value = NaN
rra[1].cdp_prep[1].unknown_datapoints = 0
rra[2].cf = "AVERAGE"
rra[2].rows = 700

there are now two rra's using pdp_per_row=1. So rrdtool will update 2 rra's on each single update instead of a single one. Don't ask me about the performance impact when updating or graphing.
But IMHO, the DAILY rra should define pdp_per_row=5 to aggregate 5 pdp's into a single data point.
Of course, the same logic holds when using polling intervals less than 60 secs.

To solve this, a complete set of new rra's should have been defined to aggregate the data. Please pay attention:
Now, the WEEKLY rra definition will aggregate 24 pdp's into a single new data point. Whereas "normally", this would span 24*5 min = 2h, in case of 1 min polling this only aggregates 24*1min = 24min. This will yield "strange" results.
This is deduced from theory, I did not yet make numeric examples. Unfortunately, Linuxworld has finished and you won't see Tobi for a while, I suppose

If I'm correct, users of the patch that has already been published would face the same problem.

Please comment
Reinhard

Reinhard,

We need to discuss this in more detail....

Larry

[gandalf]

We need to discuss this in more detail....

I suppose, EMail is not required for this discussion (it would be a NOGO, because "your" Mail Servers doesn't like the one of my provider any more). Find me at AIM, IRC or ICQ
Reinhard

[TheWitness]

Ok. How does your Monday look?

Larry

[gandalf]

Ok. How does your Monday look?

Larry

As I'm at least 6h ahead (CEST), sth like your afternoon sounds good. I hope to be back from work at least at 19:00 CEST; that would make 12:00/13:00 your time (what's your exact timezone?). From that time on, I will wait for 2-3h on AIM/IRC.
Reinhard

[TheWitness]

EDT -5 GMT

[rony]

Beta 3 coming after the following are finished:

1. Potential data source issue with 1 minute polling.
2. Addition of Nth Percentile variable "aggregate_current"
3. Improved LDAP support

[gandalf]

Major concern:
The current rra definitions are "compatible" to previous versions, but with regard to rrdtool at least "not optimal" or plainly wrong. Well, the rrd file definition does not fail. But as can be seen from

Code: Select all

rra[0].cf = "AVERAGE"
rra[0].rows = 500
rra[0].pdp_per_row = 1
rra[0].xff = 5.0000000000e-01
rra[0].cdp_prep[0].value = NaN
rra[0].cdp_prep[0].unknown_datapoints = 0
rra[0].cdp_prep[1].value = NaN
rra[0].cdp_prep[1].unknown_datapoints = 0
rra[1].cf = "AVERAGE"
rra[1].rows = 600
rra[1].pdp_per_row = 1
rra[1].xff = 5.0000000000e-01
rra[1].cdp_prep[0].value = NaN
rra[1].cdp_prep[0].unknown_datapoints = 0
rra[1].cdp_prep[1].value = NaN
rra[1].cdp_prep[1].unknown_datapoints = 0
rra[2].cf = "AVERAGE"
rra[2].rows = 700

Reinhard,

We need to discuss this in more detail....

Larry

Larry,
I'm quite sure that my approach is successful. No code change required. Find new rra definitions attached as image. Data Template has to be adjusted accordingly (and perhaps a better sorting to be introduced. To make it perfect, we may introduce sth. like a "RRA Group" to keep related rra definitions in one place. Currently I did so by introducing funny prefixes for the names). For safety, I will check the numbers tomorrow
Reinhard

[rony]

Beta 3 is delayed.

Be prepared for more news by the weekend.

[sizulku]

good news or bad news?

[TheWitness]

Good actually.

Larry

[BSOD2600]

It be Monday morning...