Florian,<br><br>For my own use case, the simplest solution may be to simply allow for an ExcludeRegex in addition to the (Include)Regex, with Exclude taking priority. Of course, I am only looking for log entries that trip the exception test, I am not trying to pull out any matching groups etc, or any of the more complicated use cases or counter types. But an exclude regex would be the path of least resistance for my use case (which I have to imagine cannot be such a rare use case :^)<br>
<br>-B<br><br><div class="gmail_quote">On Sun, Jun 21, 2009 at 2:10 AM, Florian Forster <span dir="ltr"><<a href="mailto:octo@verplant.org">octo@verplant.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Brian,<br>
<div class="im"><br>
On Sat, Jun 20, 2009 at 10:51:28AM -0700, Brian Long wrote:<br>
> Does collectd support negative lookahead or lookbehind in regex's for<br>
> the tail plugin?<br>
<br>
</div>the `tail' plugin and all other parts of collectd which use regular<br>
expressions use the extended POSIX regular expressions (sometimes also<br>
called “modern REs”). The syntax and features are described in the<br>
regex(7) manual page.<br>
<div class="im"><br>
> Lookbehind failure from logs:<br>
> Compiling the regular expression "(?<!IncompatibleRemoteService)Exception"<br>
> failed.<br>
<br>
</div>Just so we're sure to talk about the same thing: You want to count all<br>
lines matching `Exception' except those that also match<br>
`IncompatibleRemoteServiceException'.<br>
<div class="im"><br>
> Lookahead failure from logs:<br>
> Compiling the regular expression "Exception(?!.*This application is<br>
> out of date)" failed.<br>
<br>
</div>This is: All lines matching `Exception' except those also matching<br>
`Exception.*This application is out of date'.<br>
<br>
Neither syntax is included in the POSIX regexen and therefore not<br>
supported by the `tail' plugin or collectd in general.<br>
<br>
(Of course both cases are *theoretically* possible with the POSIX<br>
regular expressions, the theoretical reason being: “Regular languages<br>
are closed under complement and difference”. Unfortunately such insights<br>
are not helpful ;)<br>
<br>
We have thought about using the PCRE library for the tail plugin, but<br>
ultimately decided against it. If we use the library there, we should<br>
use it everywhere. We would therefore have a hard dependency on the<br>
library (something we definitely don't want) or we'd have differing<br>
behavior depending whether the daemon was built with or without the<br>
library. So in favor of consistent behavior all around we decided not to<br>
use PCRE.<br>
<br>
Maybe the following is a possibility to stay consistent and provide the<br>
features offered by PCRE at the same time: Introduce a configuration<br>
option, `RegexFlavor' that can be set to either `POSIX' or `PCRE'. If<br>
set to `PCRE', collectd (or the `tail' plugin) tries to load the `PCRE'<br>
library at runtime and uses it. This option could either be a global one<br>
(for all of collectd) or within the <Match /> blocks (then other plugins<br>
using those blocks, for example the `curl' plugin, would benefit as<br>
well). Any ideas?<br>
<br>
Regards,<br>
-octo<br>
<font color="#888888">--<br>
Florian octo Forster<br>
Hacker in training<br>
GnuPG: 0x91523C3D<br>
<a href="http://verplant.org/" target="_blank">http://verplant.org/</a><br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.6 (GNU/Linux)<br>
<br>
iD8DBQFKPfkMHdggu3Q05IYRAp35AJ0RSQHN5AukIcpNoF5n/++p3qPpAgCgn69A<br>
2Ttv1SVA/Vft+GvKeadNVsc=<br>
=gsV9<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br>