.png)
As we saw in our general introduction, logging may seem like a mundane technical detail, but has far-reaching implications for your business. We ended by mentioning the OpenTelemetry standard as part of our discussion of the tooling landscape. In this second part, we will examine some of the best practises for distributed logging, including using that OpenTelemetry standard. Joining us once more is Ben Calus, founder and managing partner of Reaktika.
First off, Ben suggests using a correlation ID in your code so you can trace requests across multiple services. There’s no need to reinvent the wheel, however. You can do so using the OpenTelemetry standard, which is supported out of the box by a lot of frameworks like Spring or Akka.
By adding libraries, those frameworks will take care of correlation IDs without requiring any manual intervention from your developers. In other words, this provides the advantages of better logging, but does not require time and resources to be spent on development.
If there is one thing Ben could stress, it would be this one. Just like DevOps, microservices need to be implemented well if you want to reap their benefits. If they aren’t, you risk getting the worst of both worlds: all the disadvantages of microservices and a monolithic application with none of the benefits. The more components there are to consider, the more components can fail. Not only that, but the connections between all those components can fail as well. This results in an intricate web of services that is tough to debug.
You should not wait until the production phase to support your application, and that definitely includes logging. Instead of being an afterthought, it should be part of the solution from the get-go. We should not think of logging as a fire suppression system: just there in case something goes wrong. Instead, we should consider it as essential as load-bearing walls.
Logging tools actually represent potential added value for your developers throughout the entire project. Detailed logging will enable them to iterate more frequently by detecting bugs sooner. Sure, implementing and configuring a logging solution will take up some project resources. However, Ben is absolutely convinced that this will more than pay for itself down the road: the ROI can be spectacular.
Adding libraries provide the advantages of better logging, but do not require time and resources to be spent on development
Many logging tools provide a mind map-like overview of how the different components of your system work together. This means that you can use them as a documentation tool. Ben remarks this aspect is not yet fully mature and should be treated as such.However, these tools can already provide a valuable baseline for living documentation. The information that you see is guaranteed to not be outdated.
Documenting microservices often entails a plethora of parameters and variables that might change each sprint. This living map can automate a lot of that manual updating for your dedicated documenters. This eliminates the possibility of human errors and, just like developers, it allows their valuable time to be spent on innovating and critical thinking.
If you use your developers as documenters instead, it has even greater potential to avoid errors. Developers naturally prefer to spend their time developing, so this avoids hastily written documentation which may be outdated already. According to Ben, this documentation aspect is one area where logging tools will probably mature the most in the near future.
When implementing microservices and their logging, you should keep the bigger picture in mind at all times. In a sense, you need to centralise your distributed logging, regardless of whether you are working with a service-oriented or reactive architecture. The living map we mentioned above will certainly help, but it is essential to not just analyse these services on their own. Instead, you should use the strengths of distributed logging and look at your services as a whole.
We can contrastand correlate distributed logging and DevOps. Whereas DevOps will often set up certain metrics and dashboards relating to performance, logging can be used as the business equivalent. Instead of the amount of CPU power or RAM that is being used, logging can measure valuable aspects like latency, uptime, and error rates.
For instance, you could look at how many times a user ends up at an error page. How many attempts does a user need to add an item to their basket, or proceed to the payment page? Analytics like these will provide key insights for your organisation. You can visualise these metrics on a dashboard and link them toKPIs. This will turn your logging tools into a helpful overview for quick health checks and an excellent reporting tool for performance meetings.
Monolithic applications may be a thing of the past, and living documentation may be the future of logging tools, but it is just as important to look at the present. Just like microservices themselves, their logging tools need to be implemented well if they are to deliver added value. That is where our Optis consultancy services come in.
Optis already has the knowledge and expertise built on numerous projects, so you no longer need to figure out which tools and configurations are an ideal fit for your system. We don’t just implement it; we keep your system running optimally by implementing advanced monitoring. Sounds pretty great, right? Feel free to contact us if you agree, and we will discuss the possibilities.
February 20, 2022
