-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
feature request: add a log on not matched frontend rule #1762
Comments
IMHO, the place to log 404s, 503s, or any other HTTP response code generated by Traefik is the access log: right after you have observed an error code, you usually want to know what path it hit, where it came from, and other metadata. The access log is where we aggregate all of that. I'm not sure what the current state of access logging with regards to these kind of errors is though; I believe @marco-jantke is having an eye on the subject right now due to features he's been working on. |
Somewhat related to #1748. |
So the access logs are producing one log line for each request against Traefik. It contains the general information about the request and its response (path, duration, response code, body size...). It does and should probably not contain any other information, as those things are not part of an access log. Therefore in my opinion its not a suitable place to tell you about WHY a 404 or other responses where produced. Given the PR #1748 will be merged, maybe it will already be sufficient to solve your problem? At the moment it is difficult to understand why the 404 produced. It can be because there are no active servers in the backend or there is no frontend that matches your route. Afterwards, AFAIK only the case that no frontend matches your route will produce the 404 and therefore you would know about the problem. @djalal WDYT about this? Note that you have to enable access logging as described in the documentation: https://github.com/containous/traefik/blob/131d8dd765a358924ad6619b73548f6db4a9ae03/docs/toml.md#access-log-definition |
yes, @marco-jantke, this is precisely the need here : escalate this case just like "no route to host" or "connection refused" errors. PR #1748 is also helpful for 503 response code, it's the same "meta-issue" if you want. As for 404s, this issue is to differentiate between a "real" 404 from the backend itself, from the technical 404 from Traefik itself. Traefik and backends are competing for HTTP response codes, so we need an additional hint to tell "where does this 404 come from" and ultimately "why Traefik is returning a 404" |
Now I understand your problem better. You can actually understand this already from the produced access logs. Given they matched a route and were routed to a backend, they will have an entry for the frontend and backend. If the 404 was produced by Traefik, those values will either be nil in the text format or I think skipped in the JSON format. Does this help? |
Thanks for the hint, this feels like a workaround, a "warning" or "info" log would add clarity IMHO. As for access logs, it seems PR #1683 was just merged, and will make this usable. Before that, we couldn't really parse logs files in realtime to detect mis-configurations. Let's confirm that in the next release, thx ! |
Traefik 1.6 enabled fine-grained access logs, that are fully configurable. https://docs.traefik.io/configuration/logs/#access-logs I will close this ticket, since 404 requests can be easily configured to log the request details. If you have any further issues or concerns, feel free to reach out to us on slack: traefik.slack.com, or open a new ticket. Thanks! |
Do you want to request a feature or report a bug?
Feature request
What did you do?
What did you expect to see?
Traefik sends a log when requested URL matches no frontend rules.
The log level is left to your choice : INFO or WARNING.
What did you see instead?
no log, and a generic response : "404 page not found"
Output of
traefik version
: (What version of Traefik are you using?)What is your environment & configuration (arguments, toml, provider, platform, ...)?
N/A
If applicable, please paste the log output in debug mode (
--debug
switch)The text was updated successfully, but these errors were encountered: