Nagios Support Forum

In message ,
Andreas Ericsson writes:
>On 08/03/2012 05:15 PM, John P. Rouillard wrote:
>> In message ,
>> 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
>> (http://www.cs.umb.edu/~rouilj/sec_nagio ... manual.txt) 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.
>
>That would be pretty awesome, but "adding items to the object" is simply
>not possible. C-objects are carved in stone once the code is compiled,
>and nothing but the module will ever know or care about the extra data.

So add a field that is a pointer to a nagios maintained data store for
each object. Where each object in the datastore is a key/value (blob
pointer) pair. "adding items to the object" wasn't meant as add a new
field. More along the lines of add a new item to a linked list in the
object.

>> 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.
>>
>Well, no. You might want to add things other than flags in such variables
>and you may well have several modules at once competing for the dubious
>honor of putting extra junk into objects.

The object carries the data as a linked list, static array of
pointers.... rather than as a named item in the struct. As long as the
name for each item is unique there isn't a problem. (e.g. ec_ in my
examples). Nagios could even provide a register function to allow
modules to determine which prefixes are already registered so if Eric
Charles' plugin tries to register ec_ but my event correlation plugin
already has ec_ loaded, it gets an error message and gets to chose a
new prefix. Heck nagios could even return a prefix code that is used
by the module. There are many ways to handle the issue.

>> 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 * valu
>e)
>>
>> void * get_property(*service_object, "_ec_active_action");
>>
>> to allow the brokers to register parsers for specific custom
>> variables?
>>
>
>No, and in time for Nagios 4 I doubt we'll do that since it doesn't
>really require a major version bump to be added and I just don't have
>the time for it right now. Patches are ofcourse welcome, but please
>make sure to base them on top of latest svn from sourceforge, or the
>git repo at www.github.com/ageric/nagios

Well changing the objects to provide a location in which to store this
info does require a version bump since it changes the layout of all
the object structures. But once that is done, they are more or less
futureproof.

So maybe for nagos 4 we can get a single pointer for
broker_data. Since all pointers are the same size, def

...[email truncated]...


This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]