Observability
Observability for Node.js services over a message queue: tracing a call through every service it touches, the failures that never throw, and carrying a request ID and the user from the edge through every downstream call.
3 articles
Request IDs and user context across Node.js services, without adding a parameter to every method
A log line in your billing service says a charge failed. Which user? Which request? Billing cannot tell you, because nobody told it. Here is how to carry a request ID, the user and the tenant from the edge of your system through every service call it causes, read them anywhere in a handler, and pass them on automatically, plus the one place where that context must never decide the answer. Every behaviour is measured.
read →Nothing threw, and the job never ran: silent failures in a Node.js message queue
A send() that resolves with a message id nobody will ever deliver. A push() that returns cleanly onto a queue redis refused to write. Neither throws, and neither can — the caller has already moved on by the time redis answers. That silence is over: here is what each of those failures now writes to the log instead, and the one upgrade note that costs you a stack trace.
read →Distributed tracing for Node.js services over a message queue
The standard objection to queue-based RPC is that you lose the trace: the caller sends, something else picks it up, and the connection between them is gone. It isn't — the trace context rides in the request metadata. Here is a measured three-process trace, and the four ways it silently comes out wrong.
read →