[9.x] Make it easier to support Papertrail on Vapor out of the box #5780
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to make it easier to log to Papertrail from Vapor with the stock
logging.php
configuration. This PR discusses two approaches. The patch relates to the first and lighter approach.With the way Vapor automatically sets up things like queues and caches, it's surprisingly difficult to get Papertrail working. After finally finding examples of getting Papertrail working with Vapor and finally getting it working myself, I wanted to see how easy I could make it to set up for other projects. Bonus points for getting Papertrail to work out of the box on Vapor with only having to set
PAPERTRAIL_URL
andPAPERTRAIL_PORT
.For Vapor specifically, there are some additional steps that need to be taken on the Papertrail side, so some additional docs specific to Vapor may still need to be written. In short, it comes down to:
I'd be happy to write these docs (or at least suggest copy) if that helps. I'd actually be happy to help contribute docs to Vapor for setting up Papertrail even if nothing ultimately comes of this PR. :)
The first approach is to add a
LOG_PAPERTRAIL_HANDLER
environment variable that can be set to override the defaultSyslogUdpHandler
used by thepapertrail
channel.This patch allows someone to specify the following environment variable to send logs to Papertrail even from Laravel Vapor by just using the existing
PAPERTRAIL_URL
andPAPERTRAIL_PORT
variables already used to configureSyslogUdpHandler
.This is accomplished by ensuring
LOG_PAPERTRAIL_HANDLER
is used if it is set and falling back toSyslogUdpHandler
if it is not. Additionally,handler_with
has a new entry that is a string built from the existingPAPERTRAIL_URL
andPAPERTRAIL_PORT
variables that represent theconnectionString
used bySocketHandler
.In theory, Vapor could automatically set
LOG_PAPERTRAIL_HANDLER=Monolog\Handler\SocketHandler
for projects so it is automatically configuring a supported handler out of the box.To be clear, people can do this themselves. It's just not super obvious how to go about doing it.
The second approach is to take this to a slightly higher level. Rather than juggling monolog handler definitions, we could create a Papertrail specific handler that decorates either
SyslogUdpHandler
orSocketHandler
depending on an additional setting.This would be a bit more work and even though I like this approach better (seems nicer, friendly, and cleaner) I didn't want to spend time on it before I knew it had a chance of getting accepted.
Off the top of my head, I'd expect the new default Papertrail logging configuration to look something like this:
In this case, Vapor could automatically set
LOG_PAPERTRAIL_PROTOCOL=tcp
and things would just work on new Vapor projects out of the box.Also, I'm not sure we'd need to allow people to override
LOG_PAPERTRAIL_HANDLER
in this case. Totally happy to not include that in a patch if we want to try going in this direction.