Need storing place for logs
Opened this issue · 5 comments
Hi, thanks for the great project!
Currently we, (@tmattio and me) have been implementing a project called ‘Dream-dashboard’ with Dream. For this project, we would like to put log function as well but for the logging display on the UI, there is no place to store the logs in Dream. Specifically, we would need a way to hook into the reporter (or create a new one) so we can store the logs somewhere.
If you (@aantron) prefer, this issue can be solved by ourselves, but it would be great if you could point out where to work on with the current limitation.
As a first question, is it possible to redirect STDERR for your use case?
(For comparison, all the deployment examples work fairly intelligently with logs being sent to STDERR, as Docker's log facility captures it, systemd usually redirects STDERR to journald, and Heroku also captures STDERR)
Hi @aantron!
We've tried that, that is a possibility, but I think it would be better if we could keep the stderr logs in the terminal (for user experience), while also being able to store them in a database, or a file.
Looking at Dream's code, it looks like we could pass an optional write callback to https://github.com/aantron/dream/blob/master/src/server/log.ml#L132, and have it print on both stderr and for instance a log file on user code.
What do you think of it? I could land a PR with an example if you'd like to see what the change would look like.
@tmattio, could you use the tee command or similar? Or will it be too annoying for your users (plus absent on Windows, I guess).
If not, I'd be very glad to look at the PR :)
Specifically, we would need a way to hook into the reporter (or create a new one) so we can store the logs somewhere.
Yes, this will resolve all kinds of logging-related requirements, but not all. My specific need at the moment is to get our apps writing out "structured" (JSON) log events with any number of custom tags as needed by each module. ISTM that this will require not just a custom reporter, but really full access to the logs library's entire API, so we can add tags to log messages.
@tmattio, @JiaeK, have either of you made any headway on these issues elsewhere?