News for hackers. Stuff that matters.
Re:Introduction to Event-Driven Architectures with RabbitMQ by callmeal on Thursday August 29, 2019 @10:30AM (#20829798)
Not really. It's sometimes it's easier than debugging monoliths - just log the incoming message, log outgoing message. And you can narrow down the problem just as quickly as in a monolith.
Re:Introduction to Event-Driven Architectures with RabbitMQ by vemv on Thursday August 29, 2019 @10:32AM (#20829810)
Fair point, but also incomplete.

Can you debug a forest by inspecting a single tree?

Re:Introduction to Event-Driven Architectures with RabbitMQ by nonconvergent on Thursday August 29, 2019 @12:46PM (#20831184)
which is why you want more tracing and less logging. log messages are always an art and I myself am a poor artist when it come to predicting what is both necessary and useful enough to log without overall increasing the log noise.

Tracing will show you the distributed behavior, but the best log, at most, can only show you the current state of information on a single service on a single node even when you aggregate. Tracing also works hand in hand because the correlation id should associate with the relevant log message when you do decide to drill down.

Re:Introduction to Event-Driven Architectures with RabbitMQ by vardump on Thursday August 29, 2019 @11:05AM (#20830129)
Sometimes when you inspect logs from a single component it feels like trying to solve a problem with the forest by inspecting all the ants in it. Lots of mostly irrelevant small detail without any way to place it in the big picture.