Application Performance Management (APM) tools have evolved along with the modernization of applications and IT infrastructures. From simply monitoring the availability and performance of legacy applications to having the ability to discover and analyze distributed systems, we found ourselves in dire need to understand systems and applications on a much deeper level.
If your job requires you to manage applications and oversee the health of all the components in your monitored systems, you may already have heard of the term observability. It's a buzzword that is often used interchangeably with monitoring. But is it really just a synonym for monitoring or there's more to it that you should know? Well then, let's cut to the chase and give you some answers.
Table of Contents
2. Three Pillars of Observability
6. Monitoring vs. Observability
7. Addressing Observability Challenges
10. End-User Experience Monitoring
What is Observability?
Observability is the ability to observe and understand the internal state of a system based on the data it generates. The concept of observability has its roots in control theory. It was first introduced by Rudolf Kálmán, a Hungarian-American engineer, as a method to determine the behavior of an entire system using only the information from its outputs.
There's no telling when it was first used in the context of IT systems but in 2013, engineers at Twitter published a blog post about Observability at Twitter. As one of the social media giants where IT professionals are engaging with each other online, word spread fast. Discussions after discussions, the three pillars of observability—metrics, logs, traces—were introduced.
Three Pillars of Observability
Working with metrics, logs, and traces allows you to debug systems and even detect issues that you can remediate to prevent causing bigger problems. Understanding these three will guide you in building observable systems.
Metrics
Metrics are measures of how your systems are performing over time. They can be fed into visualization tools to create dashboards from which you can derive information about service-level objectives (SLOs), service-level agreements (SLAs), and service-level indicators (SLIs). Examples include uptime, response time, CPU and memory utilization, etc.
Logs
Logs are system-generated events that generally contain information about what's happening in a system. It often includes a timestamp and a brief description of a system event. When troubleshooting issues, engineers look at logs to determine the specific time when the issue occurred and what resources were affected.
Traces
Traces are representations of how requests traverse the different nodes in a distributed system. It allows you to examine the end-to-end transactions between systems, helps you identify bottlenecks, and provides you with more information about the overall health of your systems.
Monitoring vs. Observability
The ability to observe the state of an application is vital to understanding the behavior of an entire system landscape. While monitoring informs you when something goes wrong and where it occurred, observability tells you why something failed. This level of visibility into systems helps organizations resolve issues faster and lower operational risks that may disrupt business operations.
Let's take a look at the table below to quickly grasp the differences between monitoring and observability.
Figure 1: Monitoring vs. Observability
From the questions above, you can deduce that monitoring allows you to gather data about the state of your systems while observability lets you interpret that data to help you understand the state of your systems. For example, "Is my system available?" only tells you whether your system is available (UP) or not (DOWN). While "How long is my system up and running?" tells you the system's uptime (or downtime) based on the data collected over a certain period of time.
Now, you may get confused with "Is my system healthy?" because, unlike the first question, this gives you more information. While performance metrics can give you a different interpretation as to whether your system is healthy or not, it is reliant on predefined thresholds. For example, a system is considered unhealthy if its memory utilization is above n% and CPU utilization is above n% over the last n days. With observability, you can further investigate why your system is unhealthy or what is causing your system to exceed the thresholds you have defined initially—say, it requires some data cleanup or worst, it's already a candidate for a hardware refresh.
The same thing is true for the third and fourth questions. Monitoring only tells you when and where an issue occurred but with observability, you will be able to pinpoint the reason why it occurred; or whether your system has recovered versus what you can possibly do to prevent the issue from reoccurring.
Addressing Observability Challenges
The progressive delivery of applications nowadays led to the transition of legacy applications to a microservices architecture where applications are distributed into different containers as a set of services with each service running on its own. With this modular approach to application deployment, there will be multiple runtime environments and possibly overlapping functions. As a result, organizations are faced with more complex scenarios and traditional APM tools may deem insufficient. This is where cloud-native APM tools are changing the game for monitoring modern applications by taking advantage of cloud computing to support their sophisticated nature.
Given the complexities of monitoring an environment that is constantly changing, it can still be difficult to achieve observability at scale even with cloud-native APM tools. Especially in the context of monitoring hybrid cloud environments, you can easily get lost without a comprehensive monitoring solution.
So, what comprehensive monitoring solution should you be looking at?
Data Observability
We have repeatedly mentioned how data plays an important role in making your systems observable. The whole purpose of observability relies greatly on the data gathered from monitoring systems and applications. Having the ability to manage the health of your data is crucial for achieving observability. However, monitoring modern applications involves managing several components and subsystems, with each subsystem producing a gigantic amount of data.
A comprehensive APM solution should be able to give you a holistic view of your entire data stack. By that, we mean having the ability to see the health of your data services in one dashboard, view traces and error logs for failed dataflow, monitor the status for both real-time RFC connections and RFC servers, identify why remote connections might be broken, monitor if the job server and repositories are enabled or disabled, and finally get notifications about failed jobs. Specifically for monitoring SAP Data Services, you need a comprehensive solution that can also monitor all the dependencies (i.e. applications, DB, and OS) for end-to-end systems such as S/4HANA, SAP SLT, and cloud endpoints.
End-to-End Orchestration
Speaking of end-to-end systems, a comprehensive solution must be able to automatically discover the relationships between the different components in your entire system landscape. This advanced discovery feature is essential in monitoring not just legacy applications but also microservices in production. Manually managing workloads of this scale is simply out of the question.
Take advantage of platforms that allow both legacy and modern applications to discover each other in the network and orchestrate complex IT operations, all the while increasing the observability of your systems. The more components your system has, the harder it would be to manage, monitor, and keep everything in check. That's why it's beneficial to implement a comprehensive monitoring solution that can help you understand what's happening across the board.
End-User Experience Monitoring
End-user experience monitoring is one of the key metrics that is often neglected by organizations when dealing with service-level agreements. When a customer complains about slowness, application support teams usually blame the network in an instant. This becomes an obstacle to achieving observability because you’re kept in a blind spot when it comes to knowing what really transcends the application layer.
Specifically for SAP customers, end-user experience monitoring allows you to have visibility into how end users are interacting with the application. This, in turn, allows support teams to further investigate what may be the possible cause of the application performance issue instead of putting the blame on the network team right away. A comprehensive solution should, therefore, have the ability to monitor end-user experience.
Key Takeaway
Observability is an integral part of understanding your systems better. It is more than gathering data about availability and performance metrics like what traditional monitoring or APM tools would do. It allows you to build a more comprehensive picture of each component in your systems that you want to measure.
In the context of monitoring systems in hybrid cloud environments, implementing a cloud-native APM solution allows organizations to take advantage of cloud computing to discover and analyze distributed systems particularly microservices in production. However, achieving observability at scale can still be difficult. A comprehensive APM solution that is designed to give you a holistic view of your entire data stack, discover and manage workloads, orchestrate complex IT operations, and monitor end-user experience, would help you get started with making your systems observable.
