Debugging microservices – A trace visualization worth a thousand words

Written by

A trace visualization worth a thousand words

Subscribe to our Blog

Get the Latest News and Content

How one visualization in Helios led to a discussion that got everyone on the same page

One of our core values at Helios is to eat our own dog food (or for those of you who want to keep it classy, “drink our own champagne”). While this is a known best practice among many product development teams, it’s even more important when working on tools meant to be used on an ongoing basis by developers. At Helios, we developers use our own tool for the visualization of  different microservices and their interactions, to debug and troubleshoot specific flows while working on sprint tasks, and of course, to generate end-to-end tests. Using Helios to generate integration tests on main product flows is often included as part of our definition of done (DoD) in a sprint task.

This practice of using our own product to develop our own product means we get to be very active and involved in shaping what the product does. It also means that we ourselves are users, constantly exploring the product and learning from each other to ensure we’re building a product that actually solves the pain of working on distributed applications. And while we are very intentional about dogfooding and continuous feedback, sometimes we spontaneously find new ways to use the product. 


Discussion taking place during the sprint demo at the Helios office in Tel Aviv

Case in point: Earlier this week, like every week, we held our sprint demo. When we got to the section about “data ingestion” – usually a time where we speak briefly on changes and improvements to the internal architecture – I began discussing the work I did on storing interactions. This means, in a nutshell, that from now on we’ll be storing interactions between services in a database. Until that point, interactions weren’t something we stored persistently, rather we relied solely on the original OpenTelemetry spans stored in Elasticsearch to infer interactions. Now that we can do that, we’ll be able to more easily run calculations, provide metrics, etc. because we won’t have to do it on the fly anymore. In the future, this will enable more functionality and better performance.

Instead of summarizing this work in a couple of plain, non-eloquent sentences like I’d normally do on a slide like the one below, I shared a link to a specific trace visualization I created in Helios. 


The slide used to highlight the work done on data ingestion during the sprint demo

I used the visualization to demo and explain to the team what this new interactions table is all about, in which service it can be found, what types of actions can be performed on it and why – all this directly from the visualization page. I preferred sharing the visualization because I thought it’d be the best and most interesting way to demonstrate the new feature. 


The trace visualization in Helios (used on the Helios production app) showing the new entity


And indeed, I got good responses from my teammates: using the product was a great way to intuitively understand the new feature and get all of us on the same page. Rather than summing up an internal improvement and just moving on to the next thing, sharing the visualization led to a deep, engaging discussion with the entire team. It also made me realize that Helios can be a great platform in use cases such as design reviews and onboarding where we need to explain what is happening in our system to new hires or audiences in a way they can easily understand. 

Most importantly though, we all got excited that we used the product to show something new in the product. We witnessed in real-time we built something that adds value in organic ways, in ways that cannot be pre-staged during any design or discovery process, in ways that improve the day-to-day life of developers. It was a real win to see how we ourselves gained value from this usage. This is what excites me so much about our journey and being part of the team here at Helios – and it’s only the beginning!

Learn more about trace visualization with Helios here.

Subscribe to our Blog

Get the Latest News and Content

About Helios

Helios is a developer platform that helps you increase dev velocity when building cloud-native applications. With Helios, dev teams can easily and quickly perform tasks such as getting a full view of their API inventory, reproducing failures, and automatically generating tests, from local to production environments. Helios accelerates R&D work, streamlining activities from troubleshooting and testing to design and collaboration.

The Author

Related Content

Golang blog (1)
Golang Distributed Tracing - OpenTelemetry Based Observability
OpenTelemetry (OTel in short) is an open-source observability framework that provides a standard set of vendor-agonistic SDKs, APIs, and tools to connect...
Read More
Distributed tracing visualization - Get advanced visibility into your app flows using Jaeger tracing
Jaeger distributed tracing: Advanced visibility into your app flows
Helios’ OpenTelemetry trace visualization tool provides visibility like never before into how data flows through your entire application, across any environment....
Read More
Testing Microservices - Trace Based Integration Testing Example
Microservices architectures require a new type of testing. Here’s why traditional testing types fail and which new automated testing solutions can help.
Read More