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

Option to log all server requests #885

Open
dwoznicki opened this issue Sep 15, 2022 · 3 comments
Open

Option to log all server requests #885

dwoznicki opened this issue Sep 15, 2022 · 3 comments

Comments

@dwoznicki
Copy link

There have been a couple times during debugging where I've found it extremely helpful to have the Tegola tile server log all incoming requests, so I'd like to add it as a CLI option.

I'm happy to contribute this feature, but I'd like some input on the preferred implementation method. Personally, when I was looking to see if this was already implemented, I first tried starting the server with --log-level=DEBUG, and then --log-level=TRACE. So my preference would be to add log.Debug statements to request handlers, middleware, etc.

Adding a --log-all-requests flag also seems reasonable.

Any thoughts/preferences?

@iwpnd
Copy link
Member

iwpnd commented Sep 15, 2022

Hey

a log-all-requests flag is a red flag for me. If anything this is trace log level.

What's your use case for it?
I'm wondering why you think this is more useful than your browsers developer tools that even give you the option to inspect your requests header and payload.
With that regard I don't see value in logging every request additionally to the debug view tegola already provides.

@dwoznicki
Copy link
Author

dwoznicki commented Sep 15, 2022

Here are a few use cases that have come up for me.

  1. I've been recently working on setting up a server-side tile renderer so I can serve raster tiles generated from my vector tiles. During the process, I ran into a bug where some (but not all) labels were being clipped. I couldn't easily modify the rasterizer to log which vector tiles it was requesting, so it was really helpful to have Tegola log incoming requests instead.
  2. There have been a couple situations where I've ended up with unexpected tile results in the client, and I've just wanted to be sure that my traffic was indeed going to the Tegola instance I expected it was going to. In this case, refreshing the browser page and seeing the requests pop up in the server log would be a nice sanity check.
  3. Sometimes it's nice to see which tile requests have been cache hits and which have been misses. This hasn't yielded any great debugging value for me yet; it's just been a little interesting.

@gdey
Copy link
Member

gdey commented Mar 14, 2023

3. Sometimes it's nice to see which tile requests have been cache hits and which have been misses. This hasn't yielded any great debugging value for me yet; it's just been a little interesting.

Each request that Tegola returns a header that tells you if it's a Cache hit or not.
Tegola-Cache, will be MISS or HIT depending on if the Tegola Cache served it or if Tegola generated the tile before serving it. We need to update our Debugging help to expose this knowledge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants