analysis.cfg, part 2 🔗 link

One more...I have some file tests that are testing for file ages and I want them to go yellow at one threshold, red later...I have rules similar to the following:


        FILE %/localvolume/customer/.*/schedule/.*.xml$ yellow TYPE=FILE MTIME<2700
        FILE %/localvolume/customer/.*/schedule/.*.xml$ red TYPE=FILE MTIME<3600

is there a more succinct way to put that in like:

        FILE %/localvolume/customer/.*/schedule/.*.xml$ yellow TYPE=FILE MTIME<2700 red TYPE=FILE MTIME<3600?

I can't see anything helpful in the man pages or analysis.cfg file itself...the entire FILE section is confusing and somewhat contradictory.  It would be nice if all the tests were consistent with regards to color...for example:

        LOG filename match-pattern [COLOR=color] [IGNORE=ignore-pattern] [TEXT=displaytext]
vs
        FILE filename [color] [things to check] [TRACK]

Note there is no "color=" component for FILE (and others).  I think this was actually causing a false positive with some of the tests that were set up to use "COLOR=YELLOW", for example (these went straight to red since that is the default non-green state).

Also, is there really a need for

DIR directory [color] [SIZE<maxsize] [SIZE>minsize] [TRACK]

since I'm pretty sure

FILE /path red TYPE=dir  [SIZE<maxsize] [SIZE>minsize] [TRACK]

is equivalent.

thanks

=G=

On Mon, January 4, 2016 6:02 pm, Galen Johnson wrote:

FILE/DIR/PROC indeed have a different, positional, layout. I think a
sensible strategy going forward might be to allow for tag= based matches
throughout, and deprecating prior syntaxes over time. The parsing of it
all is a little tricky due to the use of qualifiers in the code (once one
is seen, the "per-type" rule processing ends), but the FILE/DIR checks
should be easy.

At the moment, directory data coming back only includes the size and it
has a different format from the FILE responses, so it historically had a
different format. It's also worth removing confusion about whether other
checks would be useful for directory items (since they wouldn't).

That being said, there's an opportunity for improvement here, along with
refactoring out some of the parsing code. Additionally, we can have
logfetch begin returning more metadata about 'dir:' items rather than just
size itself.

Both of these should be possible.


Regards,
-jc