Closed sopel closed 11 years ago
Presumably this is a known issue, but due to a subsequent error I'm filing it explicitly - there are frequent unaccounted grok parser failures tagged with ["multiline","_grokparsefailure"], e.g. for:
["multiline","_grokparsefailure"]
2013-08-14T06:07:11.228Z 502624186,LEVEL1,New/Accepted/ITP,07:07:10.609,93.5982,100,2
@dpb587 - given your latest status posting, you seem to be aware of this issue, am I on the wrong track here entirely?
Other than that, this rings a bell regarding the multiline filter (see #78 for its origin), which is currently defined as any line that doesn't start with ERROR|WARN|INFO|DEBUG (see https://github.com/cityindex/logsearch-on-aws/commit/e0dd33796416fbb02e1e82c3dc88fd5734ecfb37).
Maybe LEVEL1 just needs to be accounted for as well, @mrdavidlaing?
I'm going to stop sending these logs until the custom filter #110 has been developed for them.
Ah, I missed that previous discussion, thanks.
Closed as Duplicate of #110.
Presumably this is a known issue, but due to a subsequent error I'm filing it explicitly - there are frequent unaccounted grok parser failures tagged with
["multiline","_grokparsefailure"]
, e.g. for:@dpb587 - given your latest status posting, you seem to be aware of this issue, am I on the wrong track here entirely?
Other than that, this rings a bell regarding the multiline filter (see #78 for its origin), which is currently defined as any line that doesn't start with ERROR|WARN|INFO|DEBUG (see https://github.com/cityindex/logsearch-on-aws/commit/e0dd33796416fbb02e1e82c3dc88fd5734ecfb37).
Maybe LEVEL1 just needs to be accounted for as well, @mrdavidlaing?