[collectd] Hit counter in threshold

[Andrés J. Díaz]

Hi again

There are the patches that I talk in last post. They add a match
missing feature (which match when value is missing), a match state
(which match with specified state) and basic hit counter. Also add the
target state which set the state properly.

Example:

<Rule "missing_as_failure">
  <Match "value">
     Missing true
     Hits 2
  <Match>
   <Target "set">
     State FAILURE
    </Target>
</Rule>

This example shows how to emulate the missing threshold, but as I said
do not work very well for me.

Best regards,
  Andres

P.S.: By the way, the code is tricky and not very clean :D

2009/7/15 Andrés J. Díaz <ajdiaz at connectical.com>:
> Hi Florian!
>
> IMHO filtering is not enough flexible to replace thresholds for now,
> some motnhs ago I tried to replace all my thresholds with filtering
> rules and also developed some patches to add some functionalities to
> filtering (someday i might post the patches, i think :D) but at the
> end I decided to rollback again. The main problems that i found were:
>
> 1) There are no single method to reset a state (back to OKAY), To
> solve this problem I create a match state and a set state, so when I
> match a non-okay state and values are in range, then set state to
> OKAY, but with this solution I've a big configuration file (a rule for
> set the threshold and a rule to back to OKAY for each threshold),
>
> 2) There are no a single way to concatenate thresholds, that is if
> raise threshold A and threshold B, then do C, in this case we need to
> add a rule and jump in target to rule B which target notification.
>
> I think that the power of filtering mechanism is very interesting to
> thresholds too, but I'm not sure about how to hard will be add new
> features. IMHO is more easy to extend thresholds to add some
> functionalities (like message customization, missing interval hit
> counter and so on..) that extend filtering to support notifications,
> in other hand, thresholds are less flexible than filtering...
>
> I had the crazy idea to add a PreQueue and a PostQueue chains to
> increase the flexibility of thresholds. In a ASCII art:
>
> uc_check_threshold:
>   threshold checker  ==> filter with PreQueue ==> enqueue notification
>
> plugin_dispatch_notification:
>   dequeue notification [*]  ==> filter with PostQueue ==> dispatch
> notification in properly plugins (callbacks)
>
> Well, here is my two cents :)
>
> Best regards,
>  Andres
>
> 2009/7/11 Florian Forster <octo at verplant.org>:
>> Hi Andrés,
>>
>> On Fri, Jul 03, 2009 at 11:33:20AM +0200, Andrés J. Díaz wrote:
>>> I've attached a patch to add hit counter to thresholds, that is, each
>>> time when threhsold raised, then an internal hit counter is
>>> incremented, when the value of the counter raise a specific value
>>> setted in configuration, then the notification is generated and
>>> counter is reset.
>>
>> thank you very much for your code :) I'm currently a bit undecided in
>> which direction I want the threshold checking / monitoring stuff to go.
>> The two general direcions are:
>>
>>  1) Improve the threshold code as it currently exists.
>>  2) Favor to use the filter machanism to check values and dispatch
>>    notifications / do other stuff. The existing <Threshold /> block(s)
>>    should then be translated to appropriate filters.
>>
>> Implementing (1) is probably a lot easier, but I think that (2) may be
>> easier to extend in the future.
>>
>> What do you think?
>>
>> Regards,
>> -octo
>> --
>> Florian octo Forster
>> Hacker in training
>> GnuPG: 0x91523C3D
>> http://verplant.org/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.6 (GNU/Linux)
>>
>> iD8DBQFKWJa1Hdggu3Q05IYRAidcAKCQtSlePgyCqbxrL0MjDnoPQMJlhACeKhav
>> GSbngfICAF06cnN81PwCIJw=
>> =QZx6
>> -----END PGP SIGNATURE-----
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collectd-match_value.patch
Type: application/octet-stream
Size: 5499 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090715/4bc69150/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collectd-target_set.patch
Type: application/octet-stream
Size: 3511 bytes
Desc: not available
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090715/4bc69150/attachment-0001.obj