1. Caddy version (caddy version
):
v2.4.6
2. How I run Caddy:
I run it the usual way using Caddyfile as the adapter.
caddy run --config /my/Caddyfile
a. System environment:
Ubuntu 18. systemd.
b. Command:
caddy run --config /my/Caddyfile
c. Service/unit/compose file:
Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.
d. My complete Caddyfile or JSON config:
This is the part I use to serve my blog:
alialhajji.com {
root * /var/www/blog/public
log {
output file /var/log/caddy/blog-access.log
}
handle_errors {
rewrite * /404.html
file_server
}
encode gzip
file_server
}
3. The problem I’m having:
In Caddy v1 I could exclude certain requests from the logs based on the request path:
log /path/to/log/file.log {
except /statics /images /css /js /favicon.ico
}
Is there a way to do that in Caddy v2? I searched the docs and old discussions here but I could not find an answer.
4. Error messages and/or full log output:
5. What I already tried:
I used except
inside the log
directive but Caddy did not recognize it.
6. Links to relevant resources:
matt
(Matt Holt)
April 7, 2022, 8:56pm
2
What are you trying to accomplish by doing this, exactly?
Hello Matt.
When someones visits my blog, all the requests sent from that page are logged (css files requests, images, etc).
This is too much noise in the logs, I want to exclude these requests from the logs.
As I said, this could be done in Caddy 1 as such:
log /path/to/log/file.log {
except /statics /images /css /js /favicon.ico
}
all requests that match /statics /images /css /js /favicon.ico
are not logged into /path/to/log/file.log
matt
(Matt Holt)
April 7, 2022, 10:37pm
4
Ah right. A better way to reduce noise in the logs is to use sampling instead: JSON Config Structure - Caddy Documentation
Otherwise, simply ignore the log messages for paths you do not care about. Things are more efficient this way. See How Logging Works — Caddy Documentation
Could you confirm that there is no way to implement exempting the requests by the path from being logged as we were doing at Caddy1? I am trying to not log the api/health requests from the reverse proxy.
Not currently, no. There’s no way to configure Caddy to not emit access logs by request path.
I have a couple ideas of how we could make that possible, but it’ll take a bit of engineering effort to figure out a good way to do it (how the config surface will look, performance considerations, etc)
1 Like
I wrote up an issue for this here:
opened 05:38PM - 08 Apr 22 UTC
feature
There's demand for a way to skip certain access logs from being emitted based on… request path: https://caddy.community/t/exclude-certain-requests-from-logs-based-on-request-path/15607
I think we can implement this by introducing a new HTTP handler `skip_log` (name TBD) which embeds a request matcher (not the matcher sibling to the route, but a matcher _inside_ the handler, since we need the handler to get the match result back); when invoked, it would run the matcher and if the matcher returns true, then it would set a flag in the request's context (maybe in Vars, probably least invasive place to do it). Then later in `server.go`, in the `defer func()` that writes the access log, we can check for this skip flag to short circuit and skip emitting the log.
Feel free to subscribe to the issue to hear about progress. I’ll probably work on this soon (should be a pretty simple implementation).
2 Likes
I have an implementation here that can be tested:
caddyserver:master
← caddyserver:skip-log-handler
opened 04:56AM - 09 Apr 22 UTC
Closes #4689
Introduces a new `skip_log` HTTP handler, which takes a matcher.… If the request matches, it will be marked to skip log emission.
This is implemented by writing to a boolean flag set in the `Vars` map when the handler matches, then checking the value at the end of the request just before attempting to emit the log.
Caddyfile syntax:
```
skip_log <matcher>
```
Note that the matcher is _not_ optional, in this case it is required.
At the code level, this directive is registered as a non-handler directive, because `RegisterHandlerDirective` will eat the matcher tokens to put it on the route.
The `skip_log` directive can be used multiple times, and the first matching one will set the skip log flag. No matcher short circuiting happens in this case when using the Caddyfile, because I didn't implement logic for merging multiple `skip_log` handlers. Technically that could be done, but it's probably not worth the effort, it would only be a super mild performance benefit for probably a lot more code.
I set the handler order for `skip_log` to be right near the top, alongside the other `vars`-ish handlers. Having it early is probably ideal because I think it makes most sense to run the matchers on an unmodified request (before any `rewrite` etc).
When configuring with JSON, multiple matcher sets can be configured on the one handler, which gives a very slight performance advantage if `OR` conditions are needed for matching.
1 Like
system
(system)
Closed
May 7, 2022, 6:39pm
10
This topic was automatically closed after 30 days. New replies are no longer allowed.