search

dan-online / autopulse

💫 automated scanning tool that bridges media organizers such as Sonarr and Radarr with media servers such as Plex and Jellyfin
https://autopulse.dancodes.online
MIT License
127 stars 5 forks source link

feat: Improved Logging #15

Closed JonathanLew1s closed 1 month ago

JonathanLew1s commented 2 months ago

Description

I'd appreciate increased detail in the logs and a log file written to persistent storage. I know the intent is not to rebase autoscan, however the logging is another thing that autoscan implemented well.

I tail -f the autoscan logs on a byobu terminal on my media server host. It gives me a quick point of reference that the stack is working, if autoscan is showing entries then the other components before are working and processing.

image

Autopulse log file is not mapped outside the docker host, need to use docker logs and is not as verbose in the event of the media file inside the trigger.

image

I'd suggest having a location within the container file structure that contains all persistent data and map that folder rather than individual file mapping in the compose, write a log file with log rotation to that folder. At some point improve the content of the log output to better track the events. Low prio.

Additional Information

No response

dan-online commented 2 months ago

Hey @JonathanLew1s I've changed the logging a bit to be somewhat more verbose (also you can change the log_level in the options if you'd like) but I agree a log file with rotation is needed along with some standardization of logs.

What do you like most about the autoscan logs? Is it the consistent log on each scan of the stats or the layout of how it is logged?

JonathanLew1s commented 2 months ago

@dan-online and hint on how to enable it? see it in the default toml config but could not replicate that into my own config with any changed output.

Autoscan the logs have value, it's not just a list of trigger events. It shows the trigger, what it contained, progression of the trigger through the process, general count of processed and outstanding. Whilst I do not always use it is one place to quickly look if things flow.

dan-online commented 2 months ago

@JonathanLew1s Yea I need to get around to a full documentation, though in the meantime I'll add more information in that default.toml. As for enabling it, setting log_level to something such as debug will give you a lot more information:

[app]
log_level = "debug"

or in yaml for another example

app:
  log_level: debug