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 email@example.com or sign up at nobl9.com (scroll).
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.