# 5 Key Observability Trends for 2022  URL:: https://infoworld.com/article/3648053/5-key-observability-trends-for-2022.html Author:: Dotan Horovits ## Highlights > Broader adoption of distributed tracing ([View Highlight](https://read.readwise.io/read/01g84ejtw50dc9q250v381ks9a)) > As more organizations migrate their workloads to cloud-native and microservices architectures, distributed tracing will become more prevalent as a means to pinpoint where failures occur and what causes poor performance. ([View Highlight](https://read.readwise.io/read/01g84ek3bfggjaxzth8ngpr3g0)) > Distributed tracing can open up a whole new world of observability into numerous processes beyond IT monitoring, in areas as diverse as developer experience, business, and [FinOps](https://bit.ly/3HGvt3l). Distributed tracing relies on instrumenting application with the mechanics of propagating context when executing requests. You can easily use the context propagation mechanism for many other processes, such as tracking resource attribution or capacity planning information per product line or per customer account. ([View Highlight](https://read.readwise.io/read/01g84ekhyb89w22ksmb521jqsa)) > Movement beyond the ‘three pillars’ of observability ([View Highlight](https://read.readwise.io/read/01g84ekqv93mebvn9z88d4hfj2)) > Discussions about observability often begin and end with what have come to be called the “three pillars of observability.” These are metrics, logs, and traces. Metrics help to detect problems and let DevOps or site reliability engineers understand what has happened. Logs, then, help to diagnose issues, providing the “why” behind the “what.” Finally, traces help engineers to pinpoint and isolate issues by indicating where they happened within distributed requests and elaborate microservice graphs. ([View Highlight](https://read.readwise.io/read/01g84ekthe9edrfefey51x4s0p)) > In the coming year, I expect we’ll be seeing more organizations embrace additional types of observability signals, including events and continuous profiling. ([View Highlight](https://read.readwise.io/read/01g84em1rqvzn2x1hyznx9ee3k)) > Extended Berkeley Packet Filter, or eBPF, is a technology that allows programs to run in the operating system’s kernel space without having to change the kernel source code or add additional modules. Currently, observability practice is largely based on manual instrumentation, requiring the addition of code at relevant points to generate telemetry data, which often presents a significant barrier, and can even prevent some organizations from implementing observability. While auto-instrumentation agents do exist, they tend to be tailored to specific programming languages and frameworks. However, eBPF allows organizations to embrace no-code instrumentation across their entire software stack, right from the OS kernel level, providing easier observability into their Kubernetes environments and offering benefits around networking and security. ([View Highlight](https://read.readwise.io/read/01g84emq8rmqbzj5afaxavj868)) > Because eBPF works across different types of traffic, it helps organizations to meet their goal of unified observability. For instance, DevOps engineers might use eBPF to collect full body trace requests, database queries, HTTP requests, or gRPC streams. They can also use eBPF to collect resource utilization metrics, including CPU usage or bytes sent, allowing the organization to calculate relevant statistics and profile their data to understand the resource consumption of various functions. Additionally, eBPF can handle encrypted traffic. ([View Highlight](https://read.readwise.io/read/01g84en01bjm98pyts8cgg93av)) > We saw this unification trend in the past year, with major vendors such as Grafana Labs, Datadog, AppDynamics, and my company Logz.io coming out of their respective specialty domains in log analytics, infrastructure monitoring, APM, or others, and expanding into a more comprehensive observability offering. We’ll see this trend accelerating in 2022, adapting to the changing observability needs and changing the competitive landscape. ([View Highlight](https://read.readwise.io/read/01g84enbshxezwsq4xs0tkknsn)) > The open source community created Kubernetes (and, essentially, the entire concept of “cloud native”). This same community is now delivering open source tools and standards to monitor these environments. New open standards like [OpenMetrics](https://openmetrics.io/) and [OpenTelemetry](https://opentelemetry.io/) will mature, becoming de facto industry standards in the process. In fact, OpenMetrics may be adopted this coming year as a formal standard by IETF, the premier internet standards organization. The rise of open source tools not only provides companies with additional options for enabling observability, but also prevents the vendor lock-in that has historically plagued some corners of the IT industry. ([View Highlight](https://read.readwise.io/read/01g84enrxq0yygd216hn2nrev1)) --- Title: 5 Key Observability Trends for 2022 Author: Dotan Horovits Tags: readwise, articles date: 2024-01-30 --- # 5 Key Observability Trends for 2022  URL:: https://infoworld.com/article/3648053/5-key-observability-trends-for-2022.html Author:: Dotan Horovits ## AI-Generated Summary In the coming year, organizations will seek to simplify, optimize, and consolidate observability through a mix of new tools and practices. ## Highlights > Broader adoption of distributed tracing ([View Highlight](https://read.readwise.io/read/01g84ejtw50dc9q250v381ks9a)) > As more organizations migrate their workloads to cloud-native and microservices architectures, distributed tracing will become more prevalent as a means to pinpoint where failures occur and what causes poor performance. ([View Highlight](https://read.readwise.io/read/01g84ek3bfggjaxzth8ngpr3g0)) > Distributed tracing can open up a whole new world of observability into numerous processes beyond IT monitoring, in areas as diverse as developer experience, business, and [FinOps](https://bit.ly/3HGvt3l). Distributed tracing relies on instrumenting application with the mechanics of propagating context when executing requests. You can easily use the context propagation mechanism for many other processes, such as tracking resource attribution or capacity planning information per product line or per customer account. ([View Highlight](https://read.readwise.io/read/01g84ekhyb89w22ksmb521jqsa)) > Movement beyond the ‘three pillars’ of observability ([View Highlight](https://read.readwise.io/read/01g84ekqv93mebvn9z88d4hfj2)) > Discussions about observability often begin and end with what have come to be called the “three pillars of observability.” These are metrics, logs, and traces. Metrics help to detect problems and let DevOps or site reliability engineers understand what has happened. Logs, then, help to diagnose issues, providing the “why” behind the “what.” Finally, traces help engineers to pinpoint and isolate issues by indicating where they happened within distributed requests and elaborate microservice graphs. ([View Highlight](https://read.readwise.io/read/01g84ekthe9edrfefey51x4s0p)) > In the coming year, I expect we’ll be seeing more organizations embrace additional types of observability signals, including events and continuous profiling. ([View Highlight](https://read.readwise.io/read/01g84em1rqvzn2x1hyznx9ee3k)) > Extended Berkeley Packet Filter, or eBPF, is a technology that allows programs to run in the operating system’s kernel space without having to change the kernel source code or add additional modules. Currently, observability practice is largely based on manual instrumentation, requiring the addition of code at relevant points to generate telemetry data, which often presents a significant barrier, and can even prevent some organizations from implementing observability. While auto-instrumentation agents do exist, they tend to be tailored to specific programming languages and frameworks. However, eBPF allows organizations to embrace no-code instrumentation across their entire software stack, right from the OS kernel level, providing easier observability into their Kubernetes environments and offering benefits around networking and security. ([View Highlight](https://read.readwise.io/read/01g84emq8rmqbzj5afaxavj868)) > Because eBPF works across different types of traffic, it helps organizations to meet their goal of unified observability. For instance, DevOps engineers might use eBPF to collect full body trace requests, database queries, HTTP requests, or gRPC streams. They can also use eBPF to collect resource utilization metrics, including CPU usage or bytes sent, allowing the organization to calculate relevant statistics and profile their data to understand the resource consumption of various functions. Additionally, eBPF can handle encrypted traffic. ([View Highlight](https://read.readwise.io/read/01g84en01bjm98pyts8cgg93av)) > We saw this unification trend in the past year, with major vendors such as Grafana Labs, Datadog, AppDynamics, and my company Logz.io coming out of their respective specialty domains in log analytics, infrastructure monitoring, APM, or others, and expanding into a more comprehensive observability offering. We’ll see this trend accelerating in 2022, adapting to the changing observability needs and changing the competitive landscape. ([View Highlight](https://read.readwise.io/read/01g84enbshxezwsq4xs0tkknsn)) > The open source community created Kubernetes (and, essentially, the entire concept of “cloud native”). This same community is now delivering open source tools and standards to monitor these environments. New open standards like [OpenMetrics](https://openmetrics.io/) and [OpenTelemetry](https://opentelemetry.io/) will mature, becoming de facto industry standards in the process. In fact, OpenMetrics may be adopted this coming year as a formal standard by IETF, the premier internet standards organization. The rise of open source tools not only provides companies with additional options for enabling observability, but also prevents the vendor lock-in that has historically plagued some corners of the IT industry. ([View Highlight](https://read.readwise.io/read/01g84enrxq0yygd216hn2nrev1))