Operations | Monitoring | ITSM | DevOps | Cloud

In my previous blog post, I discussed how transitioning from legacy monolithic applications to microservices based applications running on Kubernetes brings a range of benefits, but that it also increases the application’s attack surface. I zoomed in on creating security policies to harden the distributed microservice application, but another key challenge this transition brings is observing and monitoring the workload communication and known and unknown security gaps.

Asaf and I founded Logz.io in 2015 to provide developers with the ultimate open source log management experience. With our product, logging with the ELK Stack was simple, efficient, and automated for the first time – so customers could save engineering costs and accelerate MTTR.

Insightful proof-of-concepts with a tool can be difficult to undertake due to the demands on valuable resources: time, energy, and people. With a task as grand as observability, how could one truly test if Honeycomb and OpenTelemetry are right for their organization and meet their requirements? For this thought experiment, here’s a comprehensive description of the ideal product evaluation over the course of four weeks, given unlimited resources.

Managing over 1000 services and applications is daunting for any organization’s IT and Tech operations team. With a diverse mix of on-premises legacy systems and modern cloud stacks, the sheer volume of activity can overwhelm even the most skilled ITOps teams. The task is made more difficult by the fact that observability is fragmented. On average, organizations depend on 21 systems that produce metrics, logs, traces, and alerts for various services.

Centralized Observability may not be a buzzword but its practicality and importance can’t be denied. Let’s see why is that. As DevOps and IT teams recognize the importance of Observability, it becomes a critical component to monitor the stack and ensure data reliability. That being said, enterprises are rapidly embracing modern data stacks to harness the power of data. Therefore, a host of platforms require data observability as a tool for reliable and trustworthy data management.

In my previous articles, I discussed how to design considerations for observability solutions and how observability can augment your security implementation. In this article, I will discuss how an observability solution can provide valuable insights into your business operations through the collected data from various systems, applications, and services.

People seem to struggle with the idea that there are no repeat incidents. It is very easy and natural to see two distinct outages, with nearly identical failure modes, impacting the same components, and with no significant action items as repeat incidents. However, when we look at the responses and their variations, we can find key distinctions that shows the incidents as related, but not identical.