Skip to content
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

Closed
djalal opened this issue Jun 16, 2017 · 7 comments
Closed

feature request: add a log on not matched frontend rule #1762

djalal opened this issue Jun 16, 2017 · 7 comments
Labels
area/logs kind/enhancement a new or improved feature. priority/P2 need to be fixed in the future status/5-frozen-due-to-age
Milestone

Comments

@djalal
Copy link
Contributor

djalal commented Jun 16, 2017

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?)

N/A

What is your environment & configuration (arguments, toml, provider, platform, ...)?

N/A

If applicable, please paste the log output in debug mode (--debug switch)

N/A
@ldez ldez added area/logs status/0-needs-triage kind/enhancement a new or improved feature. priority/P2 need to be fixed in the future and removed status/0-needs-triage labels Jun 16, 2017
@timoreimann
Copy link
Contributor

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.

@timoreimann
Copy link
Contributor

Somewhat related to #1748.

@m3co-code
Copy link
Contributor

m3co-code commented Jun 19, 2017

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

@djalal
Copy link
Contributor Author

djalal commented Jun 19, 2017

It can be because there are no active servers in the backend or there is no frontend that matches your route

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"

@m3co-code
Copy link
Contributor

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?

@djalal
Copy link
Contributor Author

djalal commented Jun 19, 2017

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 !

@dtomcej
Copy link
Contributor

dtomcej commented Aug 1, 2018

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!

@dtomcej dtomcej closed this as completed Aug 1, 2018
@ldez ldez added this to the 1.6 milestone Aug 1, 2018
@traefik traefik locked and limited conversation to collaborators Sep 1, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/logs kind/enhancement a new or improved feature. priority/P2 need to be fixed in the future status/5-frozen-due-to-age
Projects
None yet
Development

No branches or pull requests

6 participants