{"id":230,"date":"2024-01-19T19:34:19","date_gmt":"2024-01-19T19:34:19","guid":{"rendered":"https:\/\/devperfops.smcwpsites.com\/?p=230"},"modified":"2024-01-19T19:34:26","modified_gmt":"2024-01-19T19:34:26","slug":"opentelemetry-and-kafka-better-observability-of-your-tests","status":"publish","type":"post","link":"https:\/\/devperfops.smcwpsites.com\/opentelemetry-and-kafka-better-observability-of-your-tests\/","title":{"rendered":"OpenTelemetry and Kafka – better observability of your tests"},"content":{"rendered":"\n

Author’s notes: The code produced in this tutorial represents my journey of learning Golang by developing a complete, though basic, application. If you think it can be improved – let me know. <\/p>\n\n\n\n

If you’ve read my previous article, you’re likely familiar with how to instrument your JMeter tests using OpenTelemetry. That’s awesome! Can we get even more of them telemetries? Well, hold on to your socks! <\/p>\n\n\n\n

The problem of problems<\/strong><\/p>\n\n\n\n

Some time ago, I asked my performance community how they run and measure their Kafka and MQ flows. The answers did not surprise me really but the state of understanding these protocols, did. According to the comments under my post, most of you prefer to create a set of producers and consumers, whose sole purpose is to generate the load and perform some basic assertions. What about the latency? “We measure that in the application”<\/p>\n\n\n\n

Well according to this<\/a> article (highly and shamelessly recommended), here’s a picture of what you can actually measure from your application*<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

*unless you’re sneaking in some timestamps and measurements inside your payload\/headers<\/p>\n\n\n\n

What are you actually missing<\/strong><\/p>\n\n\n\n

The mentioned approach of consumers-producers only has a few significant flaws:<\/p>\n\n\n\n