suture
suture copied to clipboard
thejerf
Lack of observability during successful operation
So far I'm loving suture, but one thing that is less than ideal is the lack of observability during normal, successful operation. It would be great if events could be emitted for service start and normal service stop.
With these additional events, it should be possible to trace all important lifecycle events.
I just found #69. I understand the sentiment there, but I still think it would be valuable to have the events built-into suture for a few reasons:
- It makes event hook handling easier (e.g. no need to wrap sutureslog)
- It avoids the need to wrap each and every service and supervisor to emit the events.
- Sending the supervisor of a service in the event is not trivial from outside of suture.
I realize these may not be compelling enough reasons, but the general observability of the system is incomplete without these events.
After jousting with this a few times in my head, I continue to believe that generally anything that can be avoided being added to suture itself should be. There's all sorts of places in Go where you may need to use your own wrappers to enforce your own policies, such as middleware in net/http, and I remain comfortable with the logic in #69.
Maybe I'm missing something completely obvious, but how would we get both the supervisor name and the service name for the event?
Most events in suture are sent from the supervisor (not the service). For observability purposes, we would want BOTH the supervisor name and the service name.
Today, a service does not know about it's supervisor. The simplest option to emit an event with both pieces of information would be to send it from the supervisor when a service is started, but that logic is within the private runService method on the supervisor.
No, that's a fair point I had not noticed/considered. Thank you. I will look into adding this here at some point. (May not be during the holiday season.)