The process of monitoring servers and applications has undergone many transformations throughout the years. When it began, the main question was whether the server was up or down. Now, monitoring helps answer questions about the internal state of an application and infer its status (also called white box monitoring). Monitoring today's complex infrastructure systems can be just as much an art as a technical skill.
Today, IT operations teams have to process large volumes of events or alarms in near real-time in order to protect service levels, stay competitive, and deliver a great experience to customers. If it takes too long for teams to spot and repair issues, an organization runs the risk of significant business service downtime, SLA penalties, and brand reputation damages. As IT landscapes continue to grow in scale and complexity, guarding against these risks becomes increasingly difficult.
When we talk about observability, we tend to focus first and foremost on the metrics, logs, and traces that you can collect from applications – such as request rates, error rates, and request duration. Infrastructure-level metrics, like CPU and memory utilization, might factor into the discussion as well. Here’s a third category of critical observability insights that teams tend to overlook: the network.
The term Site Reliability Engineer (SRE) first appeared in Google in the early 2000s. In Google’s 2016 SRE Book, Benjamin Treynor Sloss wrote that, generally speaking, “an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s).” This means that the SRE teams at Google decide how a system should run in production as well as how to make it run that way.
You’ve heard of observability, which has fast become one of the IT industry’s buzzwords du jour. But what about actionability, or the ability to translate observability into meaningful action? The latter term may not be a trending buzzword (not yet) – indeed, “actionability” perhaps sounds almost boring – but it’s just as essential as observability in managing complex, cloud-native environments.
The National Retail Federation forecasted historic holidays sales this 2021 season, as retailers grappled with high volumes of in-store and digital traffic, along with a need for full visibility into the user experience. They turned to monitoring their Point-of-Sale (POS) systems for key analytics that revealed unique, real-time details about what customers were experiencing.
What comes first – observability or AIOps? Can you achieve observability without AIOps? Do you need AIOps if you already have an observability solution in place? These are all questions that any team considering AIOps will want to answer in order to determine the real-world value that AIOps tools stand to offer.
Asking an IT engineer or SRE to define the purpose of observability is kind of like asking someone to explain the purpose of life: There are lots of different opinions out there, and no way of proving any of them right or wrong. You could argue that observability is just a buzzword that refers to what used to be called monitoring.
