<div> </div><div>I second this too. We need ability for event brokers to easily add/modify data (without having to register it as a macro variable) and for scripted event handlers to add data too (in this case macro variables is ok) in a somewhat similar manner. I'm willing to provide a patch.</div> <div> </div><div>I'm also still planning to provide a patch that would add text STOREDDATA in addition to STATUSDATA and PERFDATA as something that plugins can return. This will be after another "|" separator making plugins that use this incompatible with earlier versions of nagios. I'm hoping to deal with it through library that would check on the version of nagios and otherwise just output this as PERFDATA variable (at least that's what my plugins would do as that's what they are doing now)</div> <div> </div><div class="gmail_quote">On Fri, Aug 3, 2012 at 8:11 AM, John P. Rouillard <<a href="mailto:rouilj@cs.umb.edu" target="_blank">rouilj@cs.umb.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> In message <<a href="mailto:501BDA9E.8070606@op5.se">501BDA9E.8070606@op5.se</a>>, Andreas Ericsson writes: >On 08/03/2012 10:27 AM, Wim Hoekman wrote: >> On 2012-08-01 10:37, Andreas Ericsson wrote: >>> This one might resolve itself in Nagios 4, when we change how checks >>> are run. I won't investigate it further until that's out anyway though. >> The release of Nagios 4 would be a great time to import the Nagios patch >> I've submitted a while ago. >> (Subject: Additional image for action_url in host and service >> definitions patch) >> >> That patch required a change to the object abi, so it was not included >> in any minor release. > > Is there a reason why we just can't make this a custom variable with > special meaning in the UI? > >I'm especially uninterested in patches that move more UI code into the >core, since that's something that really should be going away rather >than increase. One of the things that frustrated me to no end when creating the external correlation event broker (<a href="http://www.cs.umb.edu/~rouilj/sec_nagios/nagios_sec_manual.txt" target="_blank">http://www.cs.umb.edu/~rouilj/sec_nagios/nagios_sec_manual.txt</a>) was that the broker architecture provided no mechanism for the plugin to add items to the objects and provide parsers for the objects in config files. Custom variables help a little bit but introduce the need to parse the value on every event which is not acceptable. The value should be parsed once into a quickly accessible form (e.g. bitfield) and carried around with the object. Are there any plans to add something like: add_new_custom_variable_property(SERVICE_OBJECT, "_ec_active_action", \ func_parse_ec_active_action); where: void * func_parse_ec_active_action(char * property_name, char * property_value) int add_property_value(*service_object, "_ec_active_action", void * value) void * get_property(*service_object, "_ec_active_action"); to allow the brokers to register parsers for specific custom variables? I envision the parsed properties (returned as a void *) are stored in a linked list or array in the object struct and simply store a propery name and a pointer to some blob returned by the func_parse... function. The blob is opaque to nagios and only has meaning to the event brokers. This way brokers (and other plugins too) could add new data to the internal objects without having to break abi compatibility. This also neatly (IMHO) works around the issues with serializing the object to disk as the custom variable mechanism can pass the info around to only those who are looking for it. In most other applications, the overhead of parsing the custom variable's value isn't a huge issue but in the event broker loop.... -- -- rouilj John Rouillard =========================================================================== My employers don't acknowledge my existence much less my opinions. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. <a href="http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/" target="_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/</a> _______________________________________________ Nagios-devel mailing list <a href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a> <a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a> </blockquote></div>