-
Notifications
You must be signed in to change notification settings - Fork 3.7k
LogQL: Common Log Format Support for Server Logs #2783
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This issue has been automatically marked as stale because it has not had any activity in the past 30 days. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
As someone who's currently searching for a regex to do this for loki, I do feel this should be built in. |
Same here, I think this should be a built-in :-) |
FWIW - a Go(lang) RE2 for the Common Log Format is:
and with extracted request line:
|
This is a reasonable request, but not one we intend to prioritize highly. |
Is there planned support for custom named parsers? This would allow users to use custom regexp without having to copy and paste it into each query. |
I'm working on this |
Satisfied by the new Pattern Parser: https://grafana.com/docs/loki/next/logql/#pattern |
@dannykopping Did the pattern parser get released? The link no longer references it, and it was listed as beta looking at the link in the way back machine Edit: Looks like it was released, found the correct link for details to be https://grafana.com/docs/loki/latest/logql/log_queries/#pattern |
Is your feature request related to a problem? Please describe.
Most servers such as Apache HTTP Server and Nginx use the Common Log Format. This format is not easy to parse with regular expression.
Describe the solution you'd like
It would be nice to have a
cmn_log_fmt
orserver_log
parser along sidelogfmt
andjson
to extract all values from a server log.Describe alternatives you've considered
As mentioned in the problem statement regular expression can parse the server log. An alternative solution would be re-usability of parsers.
The text was updated successfully, but these errors were encountered: