What about monitoring in the past?

In the past, monitoring tools tended to be domain-specific and point solutions. This was because server and application relationships were already determined when the production system was built, so analytics from different tools could be correlated. Then, in the early 2010s, digital transformation came along.

Did the advent of digital transformation change the concept of monitoring?!

The ultimate goal of digital transformation is to transform business areas based on digital technologies, which requires IT systems to evolve at the speed of the business. IT is now driving business development. To adapt to changes in the market, organizations must continuously develop and rapidly deploy to survive.

For continuous development and rapid deployment, lightweight and fast container technology has made it possible to build systems for complex microservices. To manage many containers, Kubernetes has emerged.

Kubernetes orchestrates the containers between the infrastructure and the applications, and when you have this guy called Kubernetes in a traditional system, you can no longer analyze the physical relationship between the server and the application and the database in the same way that you used to in monitoring. So digital transformation is what brought us to Kubernetes, and digital transformation has completely changed the way we look at monitoring.

So if you are using Kubernetes, you have to change your perspective on monitoring. You need to go beyond static monitoring and monitor the system as an integrated whole. We emphasized monitoring performance data for servers, containers, applications, and databases in a single solution. The monitoring perspective that emerged is observability.

Observability started in control engineering

Observability is the ability to measure internal states with external outputs. Applied to monitoring, it can be summarized as the ability to measure internal performance states with appropriate monitoring tools. So, while monitoring is observation of a static system, we think of observability as observability of a dynamic system.

성능 메트릭스, 트랜잭션 추적, 그리고 로그를 통합하여 = Consolidate performance metrics, transaction traces, and logs

Observability needs to analyze performance with metrics, traces, and logs. In complex systems, performance analysis requires tracking transaction profiles as well as performance metrics. In a Kubernetes-based system, in addition to performance metrics and transaction traces, you need to view and analyze the various logs that the system leaves behind.

Metrics (performance metrics)

In Kubernetes, the relationship between infrastructure and applications is dynamic, so you need to monitor both infrastructure (including cloud) and app performance metrics. In addition, since containers scale in and out automatically, we need to be able to monitor performance without an operator.

In static monitoring, performance data was stored in separate solutions for each zone, providing only a minimal consolidated view. In observability, performance data for each zone should be stored in a unified solution, enabling correlation analysis and linkage tracing from a unified dashboard.

Traces (transaction linkage traces)

Real-time transaction monitoring has been proven necessary for over 20 years and is essential in Kubernetes, but we need traceability beyond that. As user requests are processed by multiple microservices, distributed tracing becomes critical and very difficult.

Why has it become difficult?

First, because containerized environments are increasingly using asynchronous technologies to lightweight applications, and it is hard to track transactions with asynchronous threads.

Second, the number of transactions to track has increased by orders of magnitude as single transactions are split into multiple transactions.

Third, more and more complex open source components are being used.

Fourth, microservices are sometimes developed in different languages, making it difficult to analyze transactions with a single trace in Kubernetes.

Logs

Logs were not a big deal in traditional systems, and even then, it was easy to find the logs left on the server with console commands, but in Kubernetes, when a container is killed, the logs disappear and become unavailable.

And with the advent of DevOps, where developers are involved in operations, the reliance on logs has increased, and the use of various open source components requires more active monitoring of logs. Logs have become more important as we need to refer to relevant logs while analyzing transaction views or container performance, so integrated log monitoring has become a must in observability.

Closing thoughts

Monitoring has evolved from a per-area point solution to a unified solution that enables observability to collect and analyze performance data from various system components from a unified view of metrics, traces, and logs.

In order to analyze the integrated collection data, which has become larger and more complex than before, you need to be able to view the data from a transaction perspective or a container perspective first, and then analyze the associated metrics or logs to interpret performance issues. If you are planning to adopt Kubernetes or have already adopted Kubernetes, I recommend an observability tool 😊😊