Write endpoint access to access log
xxtesaxx opened this issue · comments
I noticed that whenever one of the smallrye endpoints is called, it's not written to Quarkus access log and I was wondering if I'm missing something. Is it somehow possible to see those calls in the access log?
Hi @xxtesaxx, we only log failed health checks, but we can add logging for all if requested.
That would be great. But would it be possible to enable request logging in the access log? We already see failed health checks in the normal log file. I'm interested in seeing them in the access log so that our monitoring can make use of status codes and response time. Maybe this could be configurable via the properties like "quarkus.smallrye-health.access-log.enabled=true"
@xxtesaxx sorry, but what you mean by access log? Is it something specific to Quarkus? Isn't logging configured separately?
As far as I'm concerned, access logs are nothing Quarkus specific (https://www.techtarget.com/searchsecurity/definition/access-log). In our company we also have Apache and Tomcat servers running, which also write access logs. Basically every http request which comes in gets logged. You can define patterns on what to log, like the source IP address, the response size and time and even custom headers.
In Quarkus, when access logging is enabled (https://quarkus.io/guides/http-reference#configuring-http-access-logs) all requests get automatically logged - except for the smallrye endpoints. I'm not sure why smallrye is implemented this way but what I noticed is that if I, for example, define a ContainerRequestFilter, it is never fired when accessing the liveness or readyness endpoints.
My best guess would be, that quarkus has its own internal ContainerRequestFilter to write the access log. But since ContainerRequestFilters are not working for smallrye endpoints, accessing them won't show up in the logs. Can you tell me why its not possible to filter smallrye requests?
Access logs are very helpful for monitoring. For example we can see usage spiks and run alertings based on patterns (e. g. if we see a lot of HTTP 400 call on a /login endpoint, we might be under attack).
@xxtesaxx thanks for explaining the access log to me. So I tried it with the current Quarkus version 2.10.2 and I believe it works:
- Generated plain app and added smallrye-health extension.
- Added
quarkus.http.access-log.enabled=trueto config. - Run the app:
$ quarkus dev
...
__ ____ __ _____ ___ __ ____ ______
--/ __ \/ / / / _ | / _ \/ //_/ / / / __/
-/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2022-07-14 09:01:43,173 INFO [io.quarkus] (Quarkus Main Thread) quarkus-access-log 1.0.0-SNAPSHOT on JVM (powered by Quarkus 2.10.2.Final) started in 5.126s. Listening on: http://localhost:8080
2022-07-14 09:01:43,200 INFO [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
2022-07-14 09:01:43,202 INFO [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, resteasy-reactive, smallrye-context-propagation, smallrye-health, vertx]
2022-07-14 09:01:46,353 INFO [io.qua.htt.access-log] (executor-thread-0) 127.0.0.1 - - 14/Jul/2022:09:01:46 +0200 "GET /hello HTTP/1.1" 200 28
2022-07-14 09:01:50,199 INFO [io.qua.htt.access-log] (vert.x-worker-thread-0) 127.0.0.1 - - 14/Jul/2022:09:01:50 +0200 "GET /q/health HTTP/1.1" 200 46
2022-07-14 09:01:53,983 INFO [io.qua.htt.access-log] (vert.x-worker-thread-0) 127.0.0.1 - - 14/Jul/2022:09:01:53 +0200 "GET /q/health/live HTTP/1.1" 200 46
2022-07-14 09:01:56,604 INFO [io.qua.htt.access-log] (vert.x-worker-thread-0) 127.0.0.1 - - 14/Jul/2022:09:01:56 +0200 "GET /q/health/ready HTTP/1.1" 200 46
2022-07-14 09:01:59,386 INFO [io.qua.htt.access-log] (vert.x-worker-thread-0) 127.0.0.1 - - 14/Jul/2022:09:01:59 +0200 "GET /q/health/started HTTP/1.1" 200 46
2022-07-14 09:02:04,321 INFO [io.qua.htt.access-log] (vert.x-worker-thread-0) 127.0.0.1 - - 14/Jul/2022:09:02:04 +0200 "GET /q/health/group HTTP/1.1" 200 46
Are you expecting something different?
You are right. Out of the box it's indeed working. I did some testing and it seems that the issue only arises when you use an alternative root path. Heres a sample config you can use in your plain app, which should help reproduce the issue:
quarkus.http.root-path=/test
quarkus.http.non-application-root-path=/
quarkus.health.extensions.enabled=true
quarkus.smallrye-health.root-path=/test/q
quarkus.smallrye-health.liveness-path=live
quarkus.smallrye-health.readiness-path=ready
Then you can simply curl http://localhost:8080/test/q/ready and it should show you the response without showing up in the access logs:
ok, thanks. I see now. We will fix this in Quarkus.
Thats awesome, thank you very much. :)
Closing as it should be fixed now in Quarkus. Reopen please if that's not the case.
Hi there, I wanted to give you some feedback on this, since we now have the time to upgrade our dependencies. It looks like the requests are now properly logged. However, there is an unwanted side effect. Maybe its a configuration issue. With the above mentioned config, when making calls to normal endpoints (not smallrye endpoints), the request is logged twice now:
thanks, yes, that is a bug, I will work on it.
Thank you, looking forward to the fix. :)
Hi @xxtesaxx, the fix is merged in Quarkus so please let me know if you still see the issue in your app after the next release. Thanks for the report again!