Is there any good way to select a Grok pattern (which might not yet exist) based on a field?
The reason for that question is that a Cisco ASA throws quite a few different log messages. You can easily extract the tag of the type, looking like “ASA-3-123456”, and Cisco provides explanation and the format for each of the patterns. Each pattern does require it’s own grok pattern, which in turn will require their own rule to be used. That can easily blow up a stage with 70 rules, if you only handle the common messages.
I figure you could manipulate a string to just take the last number of the Cisco-tag and create “CISCOFW[number]” as the pattern name, but this will cause a processing error if the pattern for that specific type of log does not exsist.
Is there any feature that would help there, or is there any reason this would not be a good feature?
Do I understand correctly when I say, you would provide a set of grok patterns for those Cisco messages,
and if you have a matching Grok Pattern use it, otherwise disregard the extraction and continue on?
If yes, file a feature request at github.com and we will see what we can do.
And btw. @jan does talk about working with Cisco in his blog: https://jalogisch.de/2018/working-with-cisco-asa-nexus-on-graylog/
After some thoughts we came up that you should already able to do just that with pipeline rules.
With regex you should be able to extract your substring. And the result you should be able to pass to grok.
If the grok pattern is not found you will get an error message in your graylog server.
Let me know if that worked for you.
Best wishes,
Konrad
That’s what i also figured, but as you said, that’ll throw errors. I’m not sure about performance issues if it keeps running into errors, and the rule collects errors, even though it’s running as intended. Seems to be more like a workaround than the “correct” way for it.
It would also be nice to be able to mark if a grok pattern hit the message, to be able to filter for the ones that still need a grok pattern made or corrected, works for existing patterns, as you can just check the matches property, but i figure there is no such return on an error of no grok pattern.
I had the idea of checking if a grok pattern exists before hand with a new function called grok_pattern_exists which you can pass a pattern name and it returns true or false depending on existence. But I would guess that it has the same performance limitations then the throwing an error.
But it would be clearer and with that you could do the marking that you mentioned. If you think that would help, please open a feature request and I will see what I can do about it.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.