On 08/06/2012 05:12 PM, John P. Rouillard wrote:
> 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.
>
Why on earth would you prefer O(n) complexity over O(1)? Do you realize
that you're requesting something that's both slower and more complex than
what I proposed?
>>> 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.
>
Not really, no, because user documentation has to work too or users
won't be able to use Eric Charles' module and yours at the same time.
>>> 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 of
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]