Delivering the Right Data for Better SLOs with Nobl9 & New Relic

UPDATE: Nobl9 is now GA. Try it today

Originally published at New Relic on November 2nd, 2020

User experience is everything. Nobl9 is building a service level objective (SLO) platform to connect an organization’s monitoring data to user experiences and business goals. And now, Nobl9 supports New Relic as a monitoring metrics source.

SLOs are the best tool to help organizations create and manage clear expectations for service reliability.

SLOs are a small set of service KPIs and goals that help DevOps teams identify what matters to users—and the business. SLOs are powerful: they can help you optimize your cloud spend, strike the right balance between new feature releases and retirement of technical debt, and increase the overall velocity of software releases without sacrificing reliability. 

That said, for SLOs to deliver these benefits, a necessary precursor is accurate, timely, and relevant data. A great source of that data can be your metrics and system log data. New Relic, of course, delivers precisely that. For this reason, we wanted to integrate with New Relic’s APIs so that users of the Nobl9 platform can easily use metrics data to develop and manage their SLOs. 

SLOs are the best tool to help organizations create and manage clear expectations for service reliability. And, good SLOs tie directly to end-user expectations for availability and performance.

“Service level objectives are a really important part of measuring and running reliable services. Nobl9 is now able to collect metrics directly from New Relic and connect these data points with business rules about reliability goals for software services,” said Raj Ramanujam, VP of Alliances and Channels at New Relic.

So, what’s the status? We’ve completed the service integration, and it’s now available to Nobl9 beta users. It will become GA along with the Nobl9 platform in early 2021.

Improving SLOs and GitOps workflows

You might ask, “Why would you move SLOs outside your monitoring system itself?” One reason is that you might have more than one monitoring tool and therefore need to coordinate or analyze SLOs across the group.

Or maybe  you want to add SLOs to your CI/CD pipeline or GitOps workflow, and need a software configuration asset or artifact to add to source control. Nobl9 offers a bit of YAML code to give you a way to create and manage these in a simple file format.

Finally, think about your business stakeholders: They might need to see SLO data in their own reports. Bringing the SLO definition outside of monitoring allows you to include this subset of key service information in other tools and processes.

Here’s an example:

apiVersion: n9/v1alpha
kind: SLO
metadata:
 name: sample-slo
 namespace: default
spec:
 budgetingMethod: Occurrences
 description: An SLO based on metrics from New Relic
 indicator:
   metricSource: nobl9-new-relic
   rawMetric:
     nrql: 'SELECT percentile(duration, 99) FROM Transaction where appName = ''my_service'' TIMESERIES AUTO '
 sloSet: sample-config
 thresholds:
 - budgetTarget: 0.999
   displayName: Good
   value: 0.100
 - budgetTarget: 0.9995
   displayName: Laggy
   value: 0.250

With this, you can use any New Relic query to gather SLIs and apply them in Nobl9 to define your new SLOs. Keep in mind that SLOs can combine metrics from multiple sources, for example, New Relic and Prometheus.

You can apply an SLO from a YAML file in Nobl9 with:

sloctl apply -f sample-slo-New-Relic.yaml

And if you’d like to get a peek at our Beta release (Codename Helium), drop us a line at hello@nobl9.com or sign up at nobl9.com (scroll).