check_logfile: imporve file scanning and keep track of lines matched in each file#390
check_logfile: imporve file scanning and keep track of lines matched in each file#390inqrphl wants to merge 5 commits into
Conversation
…in each file apply conditional filters to the lines early on while adding them, this was not the case before. now the count of lines being passing the filter is correct. add function to generate a detail string from files and the count of matched lines in the file. this can be added to the detailed syntax when needed. if there are no lines matched across all files, change the main output line to say "No matching lines found in files"
inqrphl
force-pushed
the
check-logfile-improve-line-count-tracking-and-output
branch
from
112f913 to
ad5c627
Compare
differentiate between empty states 1) where no files are found, due to given file paths 2) where files are found but do not contain matched lines. write different outputs for both of them, and add tests
inqrphl
force-pushed
the
check-logfile-improve-line-count-tracking-and-output
branch
from
ad5c627 to
e1d777c
Compare
|
Should still be UNKNOWN when the file does not exist at all. |
…s exist without matched lines checkdata.finalizeOutput() requires explicit filters or implicit argument filters to apply emptySyntax on output. apply empty syntax on empty state, by setting the "file" and files" argument is set as a filter.
| } | ||
|
|
||
| if !check.MatchMapCondition(check.filter, entry, false) { | ||
| log.Tracef("file: %s , line : %s, did not match the filter set in the check, not ading to check.listData", fileName, line) |
|
-> In my opinion if
-> Trailing
-> Only shows the amount of matching lines per file if nothing matches? I'm not sure how we should handle searching in multiple files, I think like this it's not really clear what it does |
FilePathPatternsCS was default initialized to "" , and when split up for commas it became an string[]{""}
This empty string then messed up some logs, and prevented returning an error for the case where no file paths were specified
additionally, add the file-line count details to the ok state syntax.
change the test files a bit, and add a test specifically checking a line that only exists on the second test log file, and how the file-line count details are added
move processing of the arguments into a separate function, to prevent linter from complaining about long CheckLogFile.Check function
|
There was actually a hidden bug - comma separated path string was default initialized to "" , and after being split it was appended to the paths as "" I wasnt checking if the user specified a different one, just blindly appending to the list No arguments ./snclient -vvv --logfile stdout run check_logfile UNKNOWN - no file defined, specify some file path patterns No dangling comma at the end if search paths dont have files ./snclient -vvv --logfile stdout run check_logfile file=./nofolder1 files=./nofolder2,./nofolder3,./nofolder4 filter="line LIKE testUser2" UNKNOWN - No files found to search lines in, search paths: './nofolder1 , ./nofolder2 , ./nofolder3 , ./nofolder4' If files were found, but did not have matching lines, I would display their counts even when they were all zeros. At least this way, it showed which files were searched for lines I toggled that file-count pairing to the default ok output as well. Is that fine? ./snclient -vvv --logfile stdout run check_logfile files=./pkg/snclient/t/test.log ./snclient -vvv --logfile stdout run check_logfile files=./pkg/snclient/t/test* filter="line LIKE testUser2" |
it uses backward slashes, so fully typing the detail prevents a match
2 participants
apply conditional filters to the lines early on while adding them, this was not the case before. now the count of lines being passing the filter is correct.
add function to generate a detail string from files and the count of matched lines in the file. this can be added to the detail-syntax when needed. this is saved in check.detail as "file_counts"
Files exist, but do not have matching lines:
No file found: