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
Catch fatal errors and output as structured #103
Catch fatal errors and output as structured #103
Conversation
So … the delivery logger is probably not what we want to output as a structured log. It's a delivery type. If you do want a structured delivery log, add a new one. But … I'm not sure what structure would be added. |
fc6ccfd
to
5b6ae1d
Compare
You are right, thank you! I got a bit ahead of myself there 😅 This really has nothing to do with the Delivery type. I'm thinking how we'd automatically wrap multi-line messages, such as errors/backtraces, in JSON to be auto-imported into our logging engine (which otherwise treats each line of the backtrace as a separate event). I think such a thing would have to happen at the CLI level. I've added a change that is a bit of a strawman but kind of shows the direction I'm thinking. Having a JSON object rather than a plaintext exception might make the output look a little funny to humans (but still readable, right?) but to any system running the CLI, it would make things much easier. What do you think? |
You could maybe accomplish some of this with a new CLI argument such as |
@tpitale what do you think of the current state of this PR? If you think it's the right track I'll write some more comprehensive tests. |
- Add tests - Add crash handler to CLI - Crash handler either throws the error or outputs the selected format
@cablett 🙌 Ready to 🚢? |
Ready when you are! Cheers friend! I'll keep an eye on when you release so we can upgrade. Thank you @tpitale ! ✨ |
Hi @tpitale ! We're really appreciating the structured logging 🙌 and there's a further feature tweak I'd like to suggest.
It would be really helpful if we could somehow make all the logs structured, as log ingestion into ElasticSearch and other tools is a lot more reliable if everything is structured.
If you're concerned this could cause folks some issues, we could make it a config variable
all_structured
that defaults to off so anyone else usingmail_room
would not be affected unless they explicitly switch it on.I've made the following PR. What do you think?