Delivering the Right Data for Better SLOs with Nobl9

This is a guest post by Kit Merker, who heads business development for Nobl9, a platform for measuring and improving reliability through service level objectives (SLOs).

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 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).