19:36:33 <TheSnide> #startmeeting 19:36:33 <MeetBot> Meeting started Wed Apr 29 19:36:33 2015 UTC. The chair is TheSnide. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:36:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:36:52 <TheSnide> hi all :) 19:37:02 <chteuchteu> Hi ;) 19:37:21 <TheSnide> so, nothing much on my side, so i'll let others talk 19:37:49 <chteuchteu> For me it's (as it has been in the last few weeks), some misc enhancements on UI 19:38:25 <chteuchteu> I've spotted some issues (and opened ones on GitHub): I don't necessarily have the competences to fix those yet, so that's why they still may be open 19:38:35 <m-r-b> <penk@freenode> hihi. 19:39:10 <chteuchteu> As always, please don't hesitate to pull the changes and give your opinion on changes :) 19:40:25 <m-r-b> <penk@freenode> i was invited in because i'd like to contribute fixes to some plugins that are... crunchy and difficult to configure. specifically i'm working on the tomcat one. i was able to get it running but only after much coding / debugging / hacking / working. i assume just fork plugins/ in github, mod, and pull request, but is there a doc describing 'best practices' for error conditions? 19:40:49 <TheSnide> errors for plugins ? 19:41:00 <m-r-b> <penk@freenode> ie, if the plugin is getting an auth error getting status from tomcat, how should that be reported? right now, i was getting name.value 0 19:41:01 <m-r-b> <penk@freenode> and nothing else 19:41:04 <m-r-b> <penk@freenode> er 19:41:05 <m-r-b> <penk@freenode> name.value U 19:41:08 <chteuchteu> BTW, I volunteer to test this tomcat plugin once it will be stable :) What does it monitor? 19:41:12 <TheSnide> i'd say a really good intro would be to write some plugin doc :) 19:41:24 <m-r-b> <penk@freenode> i'm okay with that, but i didn't want to step on previous work. 19:41:36 <TheSnide> about the tomcat one, i really like to have a generic jmx one in core. 19:41:43 <m-r-b> <penk@freenode> cht: it's just modifying the existing tomcat plugins for jvm, accesses, etc. it's really easy to break / misconfigure it :( 19:41:50 <TheSnide> much more than a tomcat specific one. 19:41:59 <be0rn> A plugin with problems should report a) when executed by munin-node-configure and b) in munin-node.log 19:42:03 <m-r-b> <penk@freenode> a JMX plugin would be tasty. 19:42:22 <m-r-b> <penk@freenode> be0rn: nothing on stderr or stdout when run with munin-run ? 19:42:25 * TheSnide has some design specs for a jmx pluing in his head 19:42:44 <be0rn> STDERR with munin-run would be very useful 19:42:46 <m-r-b> <penk@freenode> thesnide: would be happy to work with you on them. right now i just want to clean up / debug the existing one to get my fingers int he pie. 19:42:49 <TheSnide> errors should go to stdout, prefixed via # 19:42:55 <be0rn> ...or that 19:43:00 <m-r-b> <penk@freenode> see,here's where things go wonky :) 19:43:10 <TheSnide> and then exit != 0 19:43:17 <m-r-b> <penk@freenode> so, do we have aplugin guideline doc or should i draft one? 19:43:22 <be0rn> Listen to TheSnide, he's at the helm 19:43:25 <chteuchteu> I think there's one 19:43:30 <m-r-b> <penk@freenode> thesnide: GUIDE US LEADER DESLOK. 19:43:35 <chteuchteu> I know I read something about this this week 19:44:25 <TheSnide> http://guide.munin-monitoring.org/en/latest/plugin/writing.html 19:44:32 <chteuchteu> http://munin-monitoring.org/wiki/HowToWritePlugins 19:44:38 <m-r-b> <penk@freenode> heh 19:44:43 <chteuchteu> For my link, Ctrl+F Error handling 19:45:13 <m-r-b> <penk@freenode> mmm, shoudln't these be merged? 19:45:46 <TheSnide> yup, wiki pages should move/migrate to the guide, which is rst+git 19:46:04 <m-r-b> <penk@freenode> those two pages do not match on how errors should be handled :( 19:46:17 <TheSnide> there's also some adjustements to be made. 19:46:17 <m-r-b> <penk@freenode> oh hmm. maybe they're not. 19:46:27 <m-r-b> <penk@freenode> If the munin plugin emits errors, they will be visible in /var/log/munin/munin-node.log 19:46:40 <TheSnide> ... as the wiki page are quite old, and some time did pass with some feedback from the field 19:46:41 <m-r-b> <penk@freenode> if that's run via the cron, yes, that would be the case. but if munin-run runs it, it'll come on stderr. 19:46:55 <m-r-b> <penk@freenode> i'd be happy to modify the guide page. 19:47:16 <m-r-b> <penk@freenode> since that should be canonical, yes? 19:47:23 <TheSnide> #action penk will maintain the plugin guide pages 19:47:32 <TheSnide> looks like you just volunteered :DD 19:47:37 <m-r-b> <penk@freenode> i'm good with that. 19:47:49 <m-r-b> <penk@freenode> am i blessed with Powers? my github name is 'shevett' 19:48:03 <chteuchteu> (you can't go back now, TheSnide #actioned it ;P) 19:48:04 <TheSnide> penk, just use the PR mechanism. it's very easi 19:48:10 <TheSnide> y 19:48:15 <m-r-b> <penk@freenode> okie dokey. 19:48:30 <m-r-b> <penk@freenode> ahh i see. 19:48:33 <TheSnide> and some nice things might come after a while :D 19:48:45 <m-r-b> <penk@freenode> doc/plugin/writing.rst 19:48:59 <m-r-b> <penk@freenode> i'll do that. i'll also submit changes to make the tomcat plugins adhere to what i'm writring, and put a pull request in for that too. 19:49:04 <TheSnide> yup, to know which file, just use the "edit on github" link 19:49:10 <TheSnide> yup 19:50:44 <TheSnide> if you're not used to RST, just look at the existing files, or some docs is also at http://sphinx-doc.org 19:50:53 <m-r-b> <penk@freenode> nah, its cool. i'll figure it out. 19:51:29 <m-r-b> <penk@freenode> the short version is 'If you're writing a plugin, errors / config issues / etc should go to stderr. when run as munin-run you'lkl see them as the console during debugging. if an error is thrown while run via cron, it'll show in munin-node.log." 19:51:32 <m-r-b> <penk@freenode> that's pretty straightforward. 19:51:40 <TheSnide> yup. 19:52:04 <TheSnide> and don't forget to exit != 0 19:52:24 <m-r-b> <penk@freenode> yepyep. 19:53:06 <TheSnide> then, coupled with some plugin automatic documentation, and autoconfig makes it nice to use plugins 19:53:28 <TheSnide> specially, the "header" part with documents the env vars to use 19:53:37 <m-r-b> <penk@freenode> yep. the probelm is the tomcat plugins have absolutely zero error handling. if -anything- is wrong, it just puts out a U. 19:54:06 <TheSnide> well, that's also a strategy. 19:54:13 <m-r-b> <penk@freenode> a poor one :) 19:54:18 <TheSnide> just makes it quite hard to debug 19:55:06 * TheSnide will write some rfc for his ideal generic jmx plugin 19:55:17 <TheSnide> #action TheSnide will write some rfc for his ideal generic jmx plugin 19:55:49 <TheSnide> i think it'll be a java-based one. 19:56:32 <m-r-b> <penk@freenode> mmm. 19:56:39 <m-r-b> <penk@freenode> not sure if a java based plugin makes the most sense. 19:56:46 <m-r-b> <penk@freenode> startup/teardown of the JVM for each query is clunky. 19:57:56 <chteuchteu> +1 20:06:49 <m-r-b> <penk@freenode> got quiet :) #meetingover? 20:21:03 <chteuchteu> #meetingover 20:21:06 <chteuchteu> (I tried) 20:28:38 <TheSnide> got disco, sorry 20:29:11 <TheSnide> startup/teardown of the JVM can be limited to 1, thanks to multigraph and dirtyconfig 20:29:45 <TheSnide> also, i don't want to rewrite a JMX parser in something else than a JVM. 20:31:10 <TheSnide> #endmeeting