[collectd] Hit counter in threshold

[Florian Forster]

Hi Andrés,

On Wed, Jul 15, 2009 at 11:35:06AM +0200, Andrés J. Díaz wrote:
> 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.

yeah, currently some details are missing, but ultimately that's where I
want to get to.

*The* main problem currently is that *matches* can have state, but
values can't have state. This means that to implement something like
`match if previous state was ERROR and current state is OKAY' (e. g. to
dispatch okay notifications), you'd need to create one match for each
value. This does not scale, of course.

My idea is to add `meta data' to the global cache, which should solve
precisely this problem. A match or target (or any other piece of code)
could then do something similar to this:

  if (meta_data_get_unsigned_int (md, "state", &state) == 0)
    /* do something that depends on and updates `state' */
  meta_data_set_unsigned_int (md, "state", state);

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

Doesn't this do the trick?:

  <Rule>
    <Match "value">
      Variant A
    </Match>
    <Match "value">
      Variant B
    </Match>
    # Executed if both matches are ``successful''.
    <Target "notification">
      ...
    </Target>
  </Rule>

By the way, the value_list_t that are handed around can already have
this meta data I've talked about, so we could actually do something like
this:

  <Rule>
    <Match "value">
      Threshold 1
    </Match>
    <Target "meta">
      AddInteger "threshold check" 1
    </Target>
  </Rule>
  <Rule>
    <Match "value">
      Threshold 1
    </Match>
    <Target "meta">
      AddInteger "threshold check" 2
    </Target>
  </Rule>
  <Rule>
    <Match "meta">
      IntegerEquals "threshold check" 3
    </Match>
    <Target "notification">
      ...
    </Target>
  </Rule>

This is very powerful, but maybe a bit troublesome to use. Maybe
providing a simpler interface, such as the MARK target and mark match of
iptables, will do the trick just as well.

> I had the crazy idea to add a PreQueue and a PostQueue chains to
> increase the flexibility of thresholds. In a ASCII art:

Interesting idea. What do you intend to do in those filters?

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090715/fa98c239/attachment.pgp