Usage example: Generate Alarm if CPU
Load is over 95% for 10 minutes.
but NAGIOS already does this. If, for example, you don't want to know about a problem until it's been that way for thirty minutes, try (in the service definition)
This will cause the service to be checked at five-minute intervals even after it goes SOFT ERROR, but not to go hard - and notify - until the sixth successive soft error (6 * 5mins = 30 mins).
If that's not what you wanted, can you explain how it falls short?
Edit: you note that this works for you, but that it can't cope with more complex judgement issues (eg, foo is at over 80% for more than 60% of the preceding 30 minutes).
That's true, but in my experience of deploying NAGIOS, and I've done quite a lot of it, there are very few circumstances where people really need to know something like that. They may want to know it, but when pressed, they generally don't have an engineering need. In those cases, "no" is the right answer; the monitoring tool is business-critical, and overloading it with loads of stupid I-want-a-pony tests to make some VP of Executive Laundry happy is the Wrong Thing.
On the odd occasions where they really do need something baroque, it's much better to put it in the plugin. For example, I did some work for a client to let them know how old the snapshots on any given NetApp volume were, and that was fine. Then a legitimate engineering requirement arose to check that the oldest member of the set of youngest snapshots on a given set of volumes was younger than a given limit (you may want to read that a couple of times!). I could probably have tortured NAGIOS into evaluating criteria based on the results of the multiple "snapshot age" plugins, but it was much more sensible in the long run to write a plugin that tracked and evaluated this one complex criterion on its own.
So I'd say to you: be careful that there is a good engineering need for evaluating odd criteria. In the few cases where there is, write your own plugin to track it.