{"id":17533,"date":"2021-10-29T10:21:17","date_gmt":"2021-10-29T14:21:17","guid":{"rendered":"https:\/\/www.eginnovations.com\/blog\/?p=17533"},"modified":"2024-04-08T03:18:52","modified_gmt":"2024-04-08T07:18:52","slug":"kubernetes-observability-challenges-resources","status":"publish","type":"post","link":"https:\/\/www.eginnovations.com\/blog\/kubernetes-observability-challenges-resources\/","title":{"rendered":"Observability and Kubernetes Monitoring"},"content":{"rendered":"
\n

<\/span>Observability: Something Old, Something New<\/span><\/h2>\n

Heaven knows we all could use some luck these days, and observability may be just the thing we need. But observability isn\u2019t luck, and it isn\u2019t really new either. A few people even know that observability<\/a> is an aspect of control theory, which dates back to the 1800s! In this blog post, I\u2019ll cover some of the history of observability vs. traditional monitoring paradigms, and particularly, how they apply to the new world of microservices and containerization technologies, such as Docker and Kubernetes (K8s).<\/p>\n

<\/span>Observability vs. Monitoring<\/span><\/h3>\n

Monitoring tells you when something is wrong while observability enables you to understand why. Monitoring is a subset of and a key facilitator for observability. You can only monitor a system that is observable.<\/p>\n

Observability is a measure of how well you can understand your system\u2019s internal states from its external outputs. Observability uses instrumentation to provide insights that assist monitoring.<\/p>\n

Ismail Egilmez<\/a> at Thundra wrote an excellent blog post last year<\/a> covering some of the differences between monitoring and observability in which he highlighted how the very architecture of modern application architectures and deployments means monitoring alone is insufficient. He said:<\/p>\n

\u201cModern distributed applications cannot be effectively monitored by legacy methods, which are based on handling predictable failures. With microservices architecture now the de facto standard for web applications, effective debugging and diagnostics require that the system be observable \u2014 that is, its internal state can be inferred by observing its output.\u201d<\/em><\/p>\n

<\/span>Something Old<\/span><\/h3>\n

<\/span>Internal\/External Monitoring<\/span><\/h4>\n

When eG Innovations introduced eG Enterprise in 2000, we explained what we called \u2018selective, external monitoring\u2019 and \u2018precise, internal monitoring\u2019.<\/p>\n

At the time, vendors that monitored things like response time (i.e., end user perspective) often had no capability to monitor anything else. So, you could tell that \u2018the system was slow\u2019 but could not find out WHY<\/em>.<\/p>\n

eG Innovations\u2019 application of both external and internal performance monitoring used (and still uses) a combination of both approaches to enable proactive monitoring and optimization of digital ecosystems.<\/p>\n

\"Old<\/p>\n

So, this \u2018old\u2019 approach is still in use today and is quite valid from an observability perspective.<\/p>\n

<\/span>Control Theory and Performance Monitoring<\/span><\/h4>\n

We did a webinar as part of a \u2018shift-left\u2019 series back in 2018 titled, \u201cEnd-to-End Monitoring for ITSM and DevOps<\/a>\u201d and it had a section on monitoring, observability, and DevOps.<\/p>\n

In it, we described how monitoring and control loops can be simple…<\/p>\n

\"Monitoring<\/p>\n

… Or complex!<\/p>\n

\"Complex<\/p>\n

The fact is digital business services have end-to-end and top-to-bottom dependencies.<\/p>\n

\"End<\/p>\n

Deviations from normal behavior can ripple across these dependencies, and this is inclusive of applications and infrastructure regardless of the deployment model.<\/p>\n

When monitoring is fragmented across different toolsets operating at infrastructure, application, and business transaction levels the result is not typically what I would call a very \u2018observable\u2019 system.<\/p>\n

These layers are interdependent, and any user who asks, \u2018why is my application slow<\/em>?\u2019 is likely to agree unless you can isolate (or prevent him or her from having to call in the first place<\/em>!).<\/p>\n

As an ITIL Expert, of course I used ITIL to illustrate my points in the webinar. In that example, Service Strategy defines the architecture and standards, and Service Design defines norms (along with monitoring and control mechanisms).<\/p>\n

Disclaimer: For the ITIL evangelists among you, ITIL v4 has just been released and I\u2019ve not had an opportunity to review it at the time of writing this blog post.<\/em>
\n\"ITIL
\nWhat\u2019s interesting today is that back then I mentioned that \u201cMonitoring and control loops are within an organizational context; design must bridge strategy and operations<\/em>.\u201d<\/p>\n

\n

<\/span>The Three Pillars of Observability<\/span><\/h3>\n

Logs, metrics, and traces are often known as \u201cthe three pillars of observability\u201d. Some have, however, extended this to four signal sources under the mnemonic MELT (Metrics, Events, Logs, Traces). Many traditional IT tools focus primarily on metrics, the measures that indicate an issue whereas it is often error logs and traces that source and identify the root cause of the issue.<\/p>\n

Of course, collecting this data alone is insufficient and modern observability platforms, such as eG Enterprise use technologies such as Machine Learning and Statistical Correlation Analysis within an AIOps<\/a> (Artificial Intelligence for IT Operations) engine. Root cause analysis and diagnosis via such technologies is key to modern products achieving observability. Key features to evaluate in AIOps platforms are listed here<\/a>.<\/p>\n<\/div>\n

<\/span>Something New<\/span><\/h3>\n

<\/span>Converged Application Performance Monitoring (APM)\/Infrastructure Performance Monitoring (IPM)<\/span><\/h4>\n

What\u2019s \u2018new\u2019 is the rapid migration to cloud-native architectures, which leverage containers (i.e., Docker<\/a>, Kubernetes<\/a>, etc.), DevOps principles, and CI\/CD pipelines. Indeed, the recent acceleration in uptake of K8s technologies has been fueled by a wealth of enterprise offerings, such as Amazon EKS, VMware Tanzu, and Microsoft\u2019s Azure Kubernetes Service (AKS).<\/p>\n

Whether it is internal systems or customer-facing web applications, the digital user experience drives business today. No single factor is more important. But when there is a performance slowdown, this is where the agreement ends, and the challenges begin. Without a truly unified and holistic view<\/a> of all factors\u2014across applications and the infrastructure\u2014that affect the user experience, you are effectively flying blind.<\/p>\n

But while enterprise operating models are changing, and applications controlled by technologies like Kubernetes have many similar characteristics of other N-tier ecosystems–the differences lie in the dynamicity of each tier with microservices being increasingly adopted and the short lifespan of a container making it necessary to track application tiers as a whole rather than individual containers. These differences pose interesting challenges for monitoring tools.<\/p>\n

<\/span>Docker<\/span><\/h3>\n

Whether you are using Docker for modern app development, microservices, CI\/CD, digital transformation, DevOps, or edge computing, eG Enterprise provides unified performance visibility into Docker containers<\/a> and the application servers<\/a>, applications<\/a>, and databases<\/a> running on them:<\/p>\n