Add tracing's EnvFilter-like log filtering with PHILOMENA_LOG env var

[MareStare]

Before you begin

• I understand my contributions may be rejected for any reason
• I understand my contributions are for the benefit of Derpibooru and/or the Philomena software
• I understand my contributions are licensed under the GNU AGPLv3

• I understand all of the above

---

I've been debugging way too many things with the #481, and the lack of the logs has been a really big problem. I haven't found a good way to configure filtering the logs from different modules and third-party libraries dynamically with Elixir's logger, so I rolled my own solution with the PHILOMENA_LOG env var.

Also had to add more logs to some places to see what's actually happening there. For example, there was a bug in s3-proxy with uploading large files, but the error wasn't properly logged, now it is:

You can enable debug logging in the Objects module like this:

PHILOMENA_LOG-Ecto=none,Exq=none,PhilomenaMedia.Objects=debug,debug

And then see these logs:

As for the thumbnail generation logs - without them I would never know that my valkey job queue was completely full with a bunch of duplicate thumbnail generation jobs, and that I needed to clean it up manually.

On an unrelated note. I had experience with implementing a job queue at work, and we used a job fingerprint mechanism that was designed to solve this exact problem - if there is already a job in the queue with the same fingerprint, then a new one is not queued to avoid duplicate work. The fingerprint is derived from what makes the job's "identity" - i.e. its kind and parameters.

[Meow]

why not log ecto? i often resort to seeing the exact SQL executed to see where i screwed up

[MareStare]

By default - SQL logging is just extremely noisy, but anyway I can keep it on by default if you insist.

To explain my thinking for the long term:

My reason to disable it by default is that I found them extremely noisy, but anyway I can't do anything with that in the terminal. Terminal is too limited for working with logs at large.

My long-term wish is to send logs to Loki and view them in Grafana where it's easy to have a brids-eye view on the general state of the app via a dashboard like this. (this is a screenshot from my Telegram bot that uses Grafana, Loki, VictoriaMetrics):

From this view you can quickly see the general metrics, and the last panic / error / warning logs.

Then you can drill down into the gory details of the logs using the LogQL syntax, narrow it down by time and request span IDs.

Then expand the details of every log event you are interested in

This way there is no noise by default, it's convenient to view logs, and debug any request.

[MareStare]

I've rebased this branch since it's been rather old. I pushed a single commit new change a94c676 to set ecto logging level to debug. Everything else is the same

[Meow]

You seem to have refactored philomena_media/objects.ex in this PR, please pull that out to a separate PR, as a change like this isn't within the scope of a simple logging change.

[MareStare]

Moved the S3 changes to #570