Open james-callahan opened 2 years ago
Hi! This issue has been automatically marked as stale because it has not had any activity in the past 30 days.
We use a stalebot among other tools to help manage the state of issues in this project. A stalebot can be very useful in closing issues in a number of cases; the most common is closing issues or PRs where the original reporter has not responded.
Stalebots are also emotionless and cruel and can close issues which are still very relevant.
If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.
We regularly sort for closed issues which have a stale
label sorted by thumbs up.
We may also:
revivable
if we think it's a valid issue but isn't something we are likely
to prioritize in the future (the issue will still remain closed).keepalive
label to silence the stalebot if the issue is very common/popular/important.We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task, our sincere apologies if you find yourself at the mercy of the stalebot.
Please label revivable?
still valid
The basic structure of the CEF format can be parsed using the pattern
parser, like this: pattern
CEF:
Example:
{filename="/var/log/cef.log"} |= "cat=Discovery" | pattern `CEF:<v>|<vendor>|<product>|<version>|<signature>|<name>|<severity>|<extension>`
However, if you want to parse also the key value pairs of the extension it can get tricky. Even though it looks very much like logfmt
, it's not really the case. However, you can still use regular line filters, as in the example above.
However, if you want to parse also the key value pairs of the extension it can get tricky. Even though it looks very much like logfmt, it's not really the case. However, you can still use regular line filters, as in the example above.
At least with the logs coming from Cortex XDR, all the interesting things to alert on are in the extension
section. We'd like to extract them to add to alerts generated from loki ruler.
However, if you want to parse also the key value pairs of the extension it can get tricky. Even though it looks very much like logfmt, it's not really the case. However, you can still use regular line filters, as in the example above.
At least with the logs coming from Cortex XDR, all the interesting things to alert on are in the
extension
section. We'd like to extract them to add to alerts generated from loki ruler.
That's what I thought. I guess a regex guru may be able to write an expression for parsing the key value pairs, but it would be very inefficient. :(
If you don't need to parse all key value pairs of the extension field, it may be relatively easy:
{filename="/var/log/cef.log"}
|= "cat=Discovery"
| pattern `CEF:<v>|<vendor>|<product>|<version>|<signature>|<name>|<severity>|<extension>`
| label_format original=`CEF:{{.v}}|{{.vendor}}|{{.product}}|{{.version}}|{{.signature}}|{{.name}}|{{.severity}}|{{.extension}}`
| line_format `{{.extension}}`
| regexp `end=(?P<end>[^\s]+)`
| end > 1600000000000
| line_format `{{.original}}`
And since you want to alert on certain things, I assume you don't even need the last line_format
stage, because you're doing a metrics query:
sum by (shost) (
count_over_time(
{filename="/var/log/cef.log"}
|= "cat=Discovery"
| pattern `CEF:<v>|<vendor>|<product>|<version>|<signature>|<name>|<severity>|<extension>`
| line_format `{{.extension}}`
| regexp `end=(?P<end>[^\s]+)`
| regexp `shost=(?P<shost>[^\s]+)`
| end > 1600000000000
[$__interval]
)
)
Do not blame me on performance ;-)
Even that doesn't help with the un-escaping process.
Though I think it does show why a dedicated cef
parser would be useful :)
Though I think it does show why a dedicated
cef
parser would be useful :)
Agree, a dedicated parser would be more useful. If we wanna do this, we'll have some thoughts on whether integrating a parser in LogQL or in Promtail, so it can be transformed into a different format.
Hi! This issue has been automatically marked as stale because it has not had any activity in the past 30 days.
We use a stalebot among other tools to help manage the state of issues in this project. A stalebot can be very useful in closing issues in a number of cases; the most common is closing issues or PRs where the original reporter has not responded.
Stalebots are also emotionless and cruel and can close issues which are still very relevant.
If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.
We regularly sort for closed issues which have a stale
label sorted by thumbs up.
We may also:
revivable
if we think it's a valid issue but isn't something we are likely
to prioritize in the future (the issue will still remain closed).keepalive
label to silence the stalebot if the issue is very common/popular/important.We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task, our sincere apologies if you find yourself at the mercy of the stalebot.
we'll have some thoughts on whether integrating a parser in LogQL or in Promtail, so it can be transformed into a different format.
@chaudum any further thoughts on this?
Is there any progress in making a CEF parser?
I tried searching around the internet for some CEF specification, but I soft-failed... There are some vendors that kind of explain the formatting, but some actual specification/RFC would help a lot
Is your feature request related to a problem? Please describe. CEF (Common Event Format) is a logging format used by some tools. Loki and promtail should have a built in parser for it so that I can extract CEF fields as labels. CEF messages look something like:
i.e. a pipe delimited format; where the last field is a series of key/value pairs with certain escaping rules
Describe the solution you'd like
Similar to LogQL parsers
json
andlogfmt
, we should have a parsercef
Additional context
Documentation of the format
My first use-case is to parse logs from Cortex XDR which are sent as CEF payloads over syslog (see https://docs.paloaltonetworks.com/cortex/cortex-xdr/cortex-xdr-pro-admin/logs/cortex-xdr-log-notification-formats/alert-notification-format.html)