SYS-CON MEDIA Authors: Zakia Bouachraoui, Elizabeth White, Pat Romanski, Liz McMillan, Yeshim Deniz

Blog Feed Post

Focus on Detection:Prometheus, and the case for time series analysis

Detection, in the Incident Lifecycle, is the observation of a metric, at certain intervals, and the comparison of that observation against an expected value. Monitoring systems then trigger notifications and alerts based on the observation of those metrics.

For many teams, on-call is primarily about detection. Monitor everything and make sure we don’t miss out! In organizations with legacy monitoring configurations, getting better at Detection is tough. Environments are configured with broadly applied, arbitrarily set thresholds. Sometimes this is due to limitations in the monitoring solution, or the complexity of implementing different thresholds for different measurements. Sometimes it’s a simple reflection that Detection was not an area of focus before. Whatever the reason, the impact on on-call teams is measurable: too many false alerts, too many interruptions, and acute alert fatigue.

Teams that measure high on the Incident Management Assessment are focusing on time series analysis in their monitoring and detection systems. Prometheus, as one popular example of a solution using a time series database, is seeing wide adoption in both new projects and within existing environments.

Getting your head around time series can seem daunting. For individuals with years between themselves and their last statistics class, understanding the myriad of options is a barrier. While advanced functionality in these systems requires some thinking, there are plenty of easy use cases to explore in making the case for this type of Detection.

Cleaning up the disk: a stable of system administration for 60 years

I have no data to support this assertion, but I suspect if I bucketed all the alerts I’ve received in my career by type, disk utilization would be the winner in a landslide. It’s the easiest system metric to understand, but can have wide reaching consequences if in an unhappy state. It’s hard to imagine an environment where volume utilization is not monitored by default on every host. While “disk full” seems like a simple discussion, unboxing it reveals the complexity that every team faces when considering detection methods.

If we can all agree that full disks are bad, we can still have a lively debate on which precursors to FULL we may want to detect and alert on. At what threshold should a team member become involved? The number of TB free? GB? MB? A percentage of total disk? What if this host is part of a fleet of servers, and losing it is not significant?

A standard approach here is to send a WARNING level alert at 85% used (15% free) and a CRITICAL at 90% used. The thinking being that with only 10% of the volume free, someone should do something! Why? If it took us 3 years to eat up that 90%, is there any reason to believe we’ll chew through the remaining terabyte in the next 10 minutes?

The reference system

Let’s map this discussion to a basic system we can all imagine: 4 core, 4GB RAM, and two volumes, 2GB and 10GB (operating system and application, respectively). For this example it doesn’t really matter if this is a container, a physical host, or a cloud instance. I’m using Prometheus and the Node Exporter to gather and expose metrics, with Grafana on top for the visualizations.

The trickle

One would expect volume utilization on the OS volume to be relatively steady state. Other than logs, little change is introduced here. Depending on the application, the 10GB volume may also be pretty flat, or it may get a lot of use. Here we’ll consider a steady, if small, increase of utilization on that volume. As you can see below, the volume is just creeping its way up to full.

https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-19-... 300w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-19-... 768w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-19-... 510w" sizes="(max-width: 994px) 100vw, 994px" />

The standard approach would send a WARNING out right here–we’ve hit that generic 85% utilization threshold. What should someone actually do about it though?

Predictive analytics

Using time series data, we can start to apply something approximating prediction to our detection efforts. Using the same data above, we can compute the time to disk full, given the current rate of change with the deriv function in Prometheus:

(node_filesystem_size – node_filesystem_free) / deriv(node_filesystem_free[3d]) > 0

https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-19-... 300w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-19-... 768w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-19-... 510w" sizes="(max-width: 970px) 100vw, 970px" />

At the current rate of consumption we have 24 weeks to action this condition. Probably OK to not fire an alert just yet. This isn’t even informational; no real change is detected in the state of the system.

The flood

Let’s consider a different scenario– – the same volume, but with far more available space. Starting with about 25% utilization, we see this volume has a relatively steady rate of consumption

https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-21-... 300w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-21-... 510w" sizes="(max-width: 595px) 100vw, 595px" />

Until, something changes:

https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-21-... 300w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-21-... 510w" sizes="(max-width: 587px) 100vw, 587px" />

Given the historical data, it is very unexpected for this volume to see that kind of spike in utilization. If we focus on rate of change over time, we see the full story:

https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-21-... 300w, https://victorops.com/wp-content/uploads/2017/06/Screen-Shot-2017-06-21-... 510w" sizes="(max-width: 601px) 100vw, 601px" />

The standard threshold of 85% utilization will not be triggered… and so a team remains blind to the fact that the rate of change just exceeded historical expectations.

Is that actionable? Perhaps, perhaps not, but it is certainly more significant than the trickle scenario, which is firing alerts, interrupting teams, with no real situation requiring investigation.

All the data

This is a simple example focusing on a single detectable metric. How does this kind of approach scale to all the actual metrics your team may wish to track? Really, really well as it turns out. The default behavior of Prometheus exporters is to expose everything – and I really mean everything – for gathering by the prometheus collector. Out of the box the Prometheus Node Exporter is tracking ~620 discrete measurements on my test linux instance.

This is where these systems really differentiate themselves from the previous generation of detection systems: they default to gathering all the metrics, and alerting on none of them. This is in stark contrast to the default behavior of, say, Nagios: gather few measurements, store none, and alert on all.

Actionable Intelligence

Prometheus, and other time series database systems, bring a new kind of insight to the Detection phase of the Incident Lifecycle. They empower teams with more observable data than ever before, without hampering a team’s ability to dig in and understand any one of those metrics. With advanced grouping features, teams can understand these metrics as they relate to different classes of system or application. 

Using time series analysis, a team can completely rewrite the way Detection works in their practice. Bringing better fidelity to the measurements, and more reliably actionable alerting when necessary. This can materially change the game for anyone trying to reduce MTTR and get more sleep.

____________

VictorOps integrates with Prometheus. Check out the integration guide to get started..

 

 

The post Focus on Detection:
Prometheus, and the case for time series analysis
appeared first on VictorOps.

Read the original blog entry...

More Stories By VictorOps Blog

VictorOps is making on-call suck less with the only collaborative alert management platform on the market.

With easy on-call scheduling management, a real-time incident timeline that gives you contextual relevance around your alerts and powerful reporting features that make post-mortems more effective, VictorOps helps your IT/DevOps team solve problems faster.

Latest Stories
Kubernetes as a Container Platform is becoming a de facto for every enterprise. In my interactions with enterprises adopting container platform, I come across common questions: - How does application security work on this platform? What all do I need to secure? - How do I implement security in pipelines? - What about vulnerabilities discovered at a later point in time? - What are newer technologies like Istio Service Mesh bring to table?In this session, I will be addressing these commonly asked ...
Today most companies are adopting or evaluating container technology - Docker in particular - to speed up application deployment, drive down cost, ease management and make application delivery more flexible overall. As with most new architectures, this dream takes significant work to become a reality. Even when you do get your application componentized enough and packaged properly, there are still challenges for DevOps teams to making the shift to continuous delivery and achieving that reducti...
Signs of a shift in the usage of public clouds are everywhere Previously, as organizations outgrew old IT methods, the natural answer was to try the public cloud approach; however, the public platform alone is not a complete solutionThe move to hybrid, custom, and multi-cloud will become more and more prevalent At the heart of this technology trend exists a custom solution to meet the needs and concerns of these organizations, including compliance, security, and cost issues Blending Ser...
The KCSP program is a pre-qualified tier of vetted service providers that offer Kubernetes support, consulting, professional services and training for organizations embarking on their Kubernetes journey. The KCSP program ensures that enterprises get the support they're looking for to roll out new applications more quickly and more efficiently than before, while feeling secure that there's a trusted and vetted partner that's available to support their production and operational needs.
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, discussed why containers should be paired with new architectural practices such as microservices rathe...
Between the mockups and specs produced by analysts, and resulting applications built by developers, there exists a gulf where projects fail, costs spiral, and applications disappoint. Methodologies like Agile attempt to address this with intensified communication, with partial success but many limitations. In his session at @DevOpsSummit at 19th Cloud Expo, Charles Kendrick, CTO at Isomorphic Software, presented a revolutionary model enabled by new technologies. Learn how business and develop...
When a company wants to develop an application, it must worry about many aspects: selecting the infrastructure, building the technical stack, defining the storage strategy, configuring networks, setting up monitoring and logging, and on top of that, the company needs to worry about high availability, flexibility, scalability, data processing, machine learning, etc. Going to the cloud infrastructure can help you solving these problems to a level, but what if we have a better way to do things. ...
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many (23 percent) are employing the AWS Lambda serverless computing framework. It's clear: serverless is here to stay. The adoption does come with some needed changes, within both application development and operations. Th...
With the rise of Docker, Kubernetes, and other container technologies, the growth of microservices has skyrocketed among dev teams looking to innovate on a faster release cycle. This has enabled teams to finally realize their DevOps goals to ship and iterate quickly in a continuous delivery model. Why containers are growing in popularity is no surprise — they’re extremely easy to spin up or down, but come with an unforeseen issue. However, without the right foresight, DevOps and IT teams may lo...
xMatters helps enterprises prevent, manage and resolve IT incidents. xMatters industry-leading Service Availability platform prevents IT issues from becoming big business problems. Large enterprises, small workgroups, and innovative DevOps teams rely on its proactive issue resolution service to maintain operational visibility and control in today's highly-fragmented IT environment. xMatters provides toolchain integrations to hundreds of IT management, security and DevOps tools. xMatters is the ...
When you're operating multiple services in production, building out forensics tools such as monitoring and observability becomes essential. Unfortunately, it is a real challenge balancing priorities between building new features and tools to help pinpoint root causes. Linkerd provides many of the tools you need to tame the chaos of operating microservices in a cloud native world. Because Linkerd is a transparent proxy that runs alongside your application, there are no code changes required. I...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
"There is a huge interest in Kubernetes. People are now starting to use Kubernetes and implement it," stated Sebastian Scheele, co-founder of Loodse, in this SYS-CON.tv interview at DevOps at 19th Cloud Expo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Kubernetes was originally built by Google, leveraging years of experience with managing container workloads, and is now a Cloud Native Compute Foundation (CNCF) project. Kubernetes has been widely adopted by the community, supported on all major public and private cloud providers, and is gaining rapid adoption in enterprises. However, Kubernetes may seem intimidating and complex ...
The use of containers by developers -- and now increasingly IT operators -- has grown from infatuation to deep and abiding love. But as with any long-term affair, the honeymoon soon leads to needing to live well together ... and maybe even getting some relationship help along the way. And so it goes with container orchestration and automation solutions, which are rapidly emerging as the means to maintain the bliss between rapid container adoption and broad container use among multiple cloud host...