[collectd] Hit counter in threshold

[Andrés J. Díaz]

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-----
>
>