[munin-users] Field names need to track internal names

[DoubleHP <dou...@do...>]

After creating
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849948
I was said that that bug could be handled at Munin level. After deep
thinking, yes it could. But not specifically at the sensor plugin level.

In fact, there are other cases where some plugin have dynamic content. I
have half a dozen home made plugins which add or remove fields several
times a day; this implies, I have also a home made mechanism to make those
plugins reload the node, to let the config update.

In the case of sensors, after updating sensors Debian package, it hapened
that the ouput of sensor command returned lines a different way than
before. The exact output of sensors can also be altered by kernel changes,
and reboots. This ends-up in having order of probes change with time.

>From munin point of view, this means ... internal name temp1 can, some day
point to CPU probe, and an other day, to external probe. If, in the case
of fans, two fans get inverted (CPU and chassis), and the warning and
critical values had been overwritten by admin in munin.conf on server,
then, warn/crit values get inverted (these kinds of fan may have very
different RPM; and I usually use strict numbers to detect early failure of
fans) (put your finger in the fan of my PSU, system will really shutdown
VERY FAST).

There are other cases where some plugins with simple code may shuffle
internal name ... vs real world use of the field. Ex, some wifi plugin is
listing known ESSIDs around my phone. To avoid issues, my home made plugin
needs to set-up a SQL database (on long term, this is giving me a list of
frequent names, and encryption people use in my town; I check those stats
over years).

I am not sure how and where this should be done, but munin needs to
provide a way to associate hardly the internal names to the real use of a
value. Without forcing concerned plugins to use SQL.

***

I am digging into how loggrep and proc plugins do things; the issue may be
the design of sensor plugin, which uses the schem like

Field	Internal name	Type	Warn	Crit	Info
Core 0	temp2	gauge	105.0 	105.0 	
Core 1	temp3	gauge	105.0 	105.0 	
SYSTIN	temp6	gauge	65 	75 	
CPUTIN	temp7	gauge	75.0 	80.0 	

while loggrep does this:
Field	Internal name	Type	Warn	Crit	Info
cron	cron	derive	 	 	
kernel	kernel	derive	 	 	 	 	
exim	exim	derive	 	 	

sensor uses numbers which is the order of the output of command, while
other plugins use NAMES for internal names.

-- 
 >o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/
If computing were an exact science, IT engineers would'nt have work \_o<

"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)