Observability in 5 Minutes

In recent years, Observability has been one of the most widely used buzzwords. There are numerous viewpoints on Observability in the industry. Some perceive this as a new term for “monitoring,” Few others consider it an advancement over monitoring, whereas others view it as a replacement for monitoring. Everyone thinks that Observation is necessary for modern software applications, regardless of differing views.

According to Wikipedia, “Observability is a measure of how well internal states of a system can be inferred from its external outputs.”

At my job, Observation made a difference.

Sherlock Holmes stories always inspire me at my work as an IT professional. It inspires me all the time, i.e., either I am programming or testing or debugging. These stories excited me identifying several memory leaks by using tools like Eclipse MAT and Java Flight Recorder.

A fascinating quote by Sir Arthur Conan Doyle in these stories is, “You see, but you do not observe.Every DevOps person sees the information during instrumentation, whereas a few observe it. So what is the difference between seeing and observing? Observation encompasses not only seeing but also comprehending what you are seeing. Additionally, it connects previously known information to the visuals.

What does it mean now for a DevOps professional?

Observability elevates every DevOps professional who works on software applications to the level of Sherlock Holmes. On a more serious note, any DevOps professional can understand a system’s state via Observability, i.e., external outputs.

External outputs of software applications:

Typically, software applications emit various system metrics, such as CPU, memory, and IO. They broadcast logs containing information about application performance, user journeys, exceptions, and errors. These logs are used by DevOps personnel for response times, user behavior, troubleshooting, and debugging. The logs generated by legacy Monolith applications are simple to follow due to their small size. However, correlating the information present in logs in modern distributed microservice-based applications is nearly impossible. DevOps professionals require automated tools for distributed tracing and visualizing information related to Alerts and Notifications to overcome these challenges. Software applications produce three critical outputs: metrics, logs, and lead to trace. These are well known as the Three Pillars of Observability.

According to Observability Engineering Team’s charter at Twitter, Alarming/Visualization is perceived as the fourth. This charter appeals to me more than the usual notion.

Conclusion

Understanding what is going on inside the software is facilitated by the process of making software more observable. It can give clear and concise answers to basic questions within a brief time. Once there are problems, it helps to trace them back to their origins. Metrics, Distributed Tracing, Alerting/Visualization, and Logs help to achieve this.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Soma Kesara

Soma Kesara

These are my own personal views and are not the opinions of my employer