Weathermap 0.97 test (updated -> test4)

[jerrison]

It's also will break the editor horribly again. (How can you show that some of the items in a dialog box are subject to some arbitrary condition?)

about that: all files starting with an "if-statement could be excluded when writing the config file from the editor. Actually, when you want to use variables for i.e. icons (up, down, etc.) the editor can´t handle this, afaik.

[/quote]

[jerrison]

since there is little i can do to solve this issue internally (sadly) i found my workaround to be the inclusion of "nasty" iframe code in the "notes" field.
An info.php script will get me the DB-query results i need and i can do all the if-else i want to .

[uhtred]

Hi,

i still test the new version. Everything is working fine.

I tried the new feature for SCALE vlaues < 0, cause i need this for some optical parameters. It doesn't work with my values. I get the following error:
WARNING: [Map 5] ons-rz3-inside.conf: NewColourFromPercent: Clipped -500% to 0% for item x-1/2-rx
or
WARNING: [Map 5] ons-rz3-inside.conf: NewColourFromPercent: Clipped -2% to 0% for item x-1/2-tx

My graph values at this time are -50 and -0.2 (dBm). But i use a CDEF to divide the value by 10, cause original values are -500 and -2.


-------------------------
Here is my code:

HTMLSTYLE overlib
SCALE trunk_status -60 -39.9 0 255 0 images/ons_trunk_3.png
SCALE trunk_status -39.9 60 255 0 0 images/ons_trunk_1.png

#osc-line(tx)
NODE x-1/2-tx
POSITION 56 336
TARGET gauge:../../rra/x_5min_opt_tx_co_590.rrd:5min_opt_tx_co:-
ICON 6 9 {node:this:inscaletag}
USESCALE trunk_status in

#osc-line(rx)
NODE x-1/2-rx
POSITION 50 336
TARGET gauge:../../rra/x_5min_opt_rx_co_586.rrd:5min_opt_rx_co:-
ICON 6 9 {node:this:inscaletag}
USESCALE trunk_status in

-------------------------------

1. Is there something wrong in my conf or is it not possible to use values like my one?
2. Isn't it possible to use CDEFs? It would be great, if i could use them like in my graphs.

[Howie]

USESCALE trunk_status in

I think this should be
USESCALE trunk_status in absolute
otherwise your -ve value is treated as a percentage.

2. Isn't it possible to use CDEFs? It would be great, if i could use them like in my graphs.

For simple multiplication/division it is possible:

Code: Select all

        TARGET 0.1*gauge:../../rra/x_5min_opt_tx_co_590.rrd:5min_opt_tx_co:-

to divide by 10.

[uhtred]

thanks for fast reply howie, its working fine.

[Howie]

0.97test4 released - see the first post. Nearly there!

[widek611]

This new SQL query from setup.php takes about 14sec on SPARC system
with 8core 2,4GHz, 16GB ram, Mysql 64bit 5.1.25-rc-log (Coolstack).

Code: Select all

	[quote]// $requiredlist = db_fetch_assoc("select distinct weathermap_data.*, data_template_data.local_data_id, data_template_rrd.data_source_type_id from weathermap_data, data_template_data, data_template_rrd where weathermap_data.rrdfile=data_template_data.data_source_path and data_template_rrd.local_data_id=data_template_data.local_data_id");
	// new version works with *either* a local_data_id or rrdfile in the weathermap_data table, and returns BOTH
	$requiredlist = db_fetch_assoc("select distinct weathermap_data.id, weathermap_data.last_value, weathermap_data.last_time, weathermap_data.data_source_name, data_template_data.data_source_path, data_template_data.local_data_id, data_template_rrd.data_source_type_id from weathermap_data, data_template_data, data_template_rrd where weathermap_data.local_data_id=data_template_data.local_data_id and data_template_rrd.local_data_id=data_template_data.local_data_id;");[/quote]

When i used previous SQL everything was OK.
I used "log-slow-queries" option in MySQL.

[Howie]

re: SQL... I am away this weekend listening to loud music and drinking, but I'll take a look in a day or so. I'm pretty sure the change was to improve performance

[Howie]

This new SQL query from setup.php takes about 14sec on SPARC system
with 8core 2,4GHz, 16GB ram, Mysql 64bit 5.1.25-rc-log (Coolstack).

Code: Select all

	[quote]// $requiredlist = db_fetch_assoc("select distinct weathermap_data.*, data_template_data.local_data_id, data_template_rrd.data_source_type_id from weathermap_data, data_template_data, data_template_rrd where weathermap_data.rrdfile=data_template_data.data_source_path and data_template_rrd.local_data_id=data_template_data.local_data_id");
	// new version works with *either* a local_data_id or rrdfile in the weathermap_data table, and returns BOTH
	$requiredlist = db_fetch_assoc("select distinct weathermap_data.id, weathermap_data.last_value, weathermap_data.last_time, weathermap_data.data_source_name, data_template_data.data_source_path, data_template_data.local_data_id, data_template_rrd.data_source_type_id from weathermap_data, data_template_data, data_template_rrd where weathermap_data.local_data_id=data_template_data.local_data_id and data_template_rrd.local_data_id=data_template_data.local_data_id;");[/quote]

When i used previous SQL everything was OK.
I used "log-slow-queries" option in MySQL.

Could you please check in weathermap_data and see if you have any entries with local_data_id==0? If so, please truncate weathermap_data, and wait a few poller cycles for it to repopulate. I have a note that the database update script in setup.php should have done this for you, but it's possible it didn't, I guess. Also, could you let me know how many rows there are in weathermap_data?

In fact the new query does less than the old one (which allowed for using either local_data_id or a filename to find data). The new one works on local_data_id only.

[DLNoah]

I redid some of my cacti host templates and weathermap dashboard maps so that I could stop having weathermap do direct SNMP polling and get to all dsstats for my weathermap data gathering. Below is my datasource & runtime comparison for anyone that wants the scale-testing information:

Old runtimes (0.96a): 5 maps, 126 cactihost: calls, 143 snmp: calls, 829 dsstats: calls, 20-30s Weathermap runtime
New runtimes (0.97test4): 6 maps, 126 cactihost: calls, 962 dsstats: calls, 8-10s Weathermap runtime.

I had adjusted the SNMP timeout to be 500ms, 1 retry in 0.96a, but generally no hosts were timing out for the runtimes quoted. Once hosts started timing out, the runtimes ballooned to 45s+

[Howie]

I had adjusted the SNMP timeout to be 500ms, 1 retry in 0.96a, but generally no hosts were timing out for the runtimes quoted. Once hosts started timing out, the runtimes ballooned to 45s+

This should improve in some cases with 0.97 - it has the option to just give up on a host after 'n' queries fail. So if you have a downed switch, you won't have to wait for 48*timeout... with 126 hosts, I guess it may not have helped you so much though.

It would be quite nice for weathermap to collect these kinds of usage stats, wouldn't it? I did start on that a while ago, to try and figure out which features people use, too.

[DLNoah]

Well, the primary reason I switched from using the SNMP target to the DSStats target is that I wanted to put the Frequency (which is what I was polling with WM via SNMP) on the graph templates I was graphing. So I figured having the added bonus of speeding the WM execution time by having everything called via DSStats was gravy (which it definately appears to have helped).

[widek611]

This new SQL query from setup.php takes about 14sec on SPARC system
with 8core 2,4GHz, 16GB ram, Mysql 64bit 5.1.25-rc-log (Coolstack).

Code: Select all

	[quote]// $requiredlist = db_fetch_assoc("select distinct weathermap_data.*, data_template_data.local_data_id, data_template_rrd.data_source_type_id from weathermap_data, data_template_data, data_template_rrd where weathermap_data.rrdfile=data_template_data.data_source_path and data_template_rrd.local_data_id=data_template_data.local_data_id");
	// new version works with *either* a local_data_id or rrdfile in the weathermap_data table, and returns BOTH
	$requiredlist = db_fetch_assoc("select distinct weathermap_data.id, weathermap_data.last_value, weathermap_data.last_time, weathermap_data.data_source_name, data_template_data.data_source_path, data_template_data.local_data_id, data_template_rrd.data_source_type_id from weathermap_data, data_template_data, data_template_rrd where weathermap_data.local_data_id=data_template_data.local_data_id and data_template_rrd.local_data_id=data_template_data.local_data_id;");[/quote]

When i used previous SQL everything was OK.
I used "log-slow-queries" option in MySQL.

Could you please check in weathermap_data and see if you have any entries with local_data_id==0? If so, please truncate weathermap_data, and wait a few poller cycles for it to repopulate. I have a note that the database update script in setup.php should have done this for you, but it's possible it didn't, I guess. Also, could you let me know how many rows there are in weathermap_data?

In fact the new query does less than the old one (which allowed for using either local_data_id or a filename to find data). The new one works on local_data_id only.

OK. It works perfect.
Thanks very much.

[egarnel]

Howie,

Are there any plans to allow for setting map order underneath the tab settings?
Thanks,

Eric

[Howie]

You have been able to change the map order since version 0.8... it works the same way - click the little arrows.