While implementing a distributed system, I find that I’m working across dozens of apps and services. Moreover, these services typically expose their functionality over REST APIs, protected in different ways. It would be nice if there was some way to keep track of all APIs, preferably in a neatly organised fashion…
Several challenges arise when we work on systems that are sufficiently large:
As software engineers, understanding distributed systems is essential to enhance, maintain and deliver business value. By implementing tracing, distributed systems can become easier to debug and diagnose.
This article is a guide to implementing tracing using Microsoft Azure’s Application Insights. Tracing in this article refers to writing events from related system such that an end-to-end transaction log can be reconstructed. In contrast, my previous article describes technical details behind how Application Insights makes this possible.
Distributed systems presents challenges that makes diagnosing issues harder:
As a front-end developer, I somehow find myself reviewing a lot of dot NET micro-services source code that is deployed to Microsoft Azure. Micro-services has allowed Prospa to scale its engineering department from ~15 in one Sydney office to over 50 in multiple locations. It has allowed development teams to collaborate smoothly and certainly contributed to the success of the company. However, it has also caused some surprises in production due to inconsistency: in quality amongst service components, monitoring and deployment methods.
A while ago I discovered that Azure Application insights can automatically stitch together the logs from the message consumer and message producer of Azure Service Bus messages, despite being saved in different Application Insights resources.
This has been a long standing pain point for our message based architecture. Now when we publish a message we have a sense of its outcome. Recently I showed this to a colleague. Impressed, he followed up with a predictable question: “how does it work?”
This post describes the output of hours digging through incomplete, out-of-date documentation and source code to answer this question.
Senior software engineer