Naming Conventions for Labeling SLOs

Naming things is hard. Naming conventions are a simple way to ensure everyone understands how things work. In software development, naming can make all the difference in how productive and clearly everyone understands how things work. 

With Service Level Objectives (SLOs), naming things is essential. Nobl9 offers Labels to organize Projects, Services, SLOs, and Alert Policies. Labels are flexible, and you can experiment with different uses. They appear in various places in the UI but can filter reports and the sloctl command line. 

While you could label your SLO objects in many ways, we wanted to provide some practical tips for setting a naming convention your team can follow in different situations.

What Are Labels?

Labels are key-value pairs attached to SLOs, Services, Projects, and Alert Policies in the Nobl9 platform. Labels allow users to define attributes of resources and use them to filter and group SLOs across Services and Projects in the SLO Grid view and Reports. Each label must be unique for a given SLO, but many SLOs can carry the same label.  To learn labeling basics like the requirements and how to add or remove them, check out the documentation: https://docs.nobl9.com/Features/labels/

Label Convention: Team & Organization Structure

It’s common for teams to “own” services or groups of services. One easy way to label services is to add a label for teams. For example:

team: front-end, team: platform, team: payments, team: catalog 
org: gaming-division, org: wealth-mgmt, org: consumer

You can create labels for different hierarchy levels, perhaps org or group. Team-based Labels make it easy to see which services or projects are in the organization quickly, so you can quickly take inventory or contact the right team to ask questions.

Label Convention: Geographic & Customer Segments

Suppose you’re running a service used by different user groups geographically or perhaps different customer segments (like trial vs. paid customers). In that case, you may have separate SLOs you want to label. 

geo: us, geo: eu, geo: japan, geo: tier-1
customer-type: vip, customer-type: enterprise, customer-type: basic
sku: enterprise, sku: teams, sku: trial

Label Convention: Service Dependencies & Sequence

You can describe the relationship between services using labels. These Labels are helpful when there is a clear order to the steps in a process that the services support. For example, consider a simple checkout workflow described using labels on SLOs:

• Step 1: Price Items in Cart
• Step 2: Calculate Tax
• Step 3: Collect Payment
• Step 4: Send the Receipt

Using Labels, you could describe the order of operations:

checkout-steps: price-items-step-1, 
checkout-steps: calculate-tax-step-2,
checkout-steps: collect-payment-step-3, 
checkout-steps: send-receipt-step-4

You can add dependencies to labels, for example:

depends-on: another-service, depends-on: aws, depends-on: mongodb
dependent: another-service, dependent: some-api, dependent: mobile 

Label Convention: Release Management & Versioning 

Another excellent use for Labels is defining the expected quality of a set of services, for example, explaining what is in production vs. dev or test. You can also use this to set clear expectations for experimental features or the state of progressive releases of new software.

env: dev, env: test, env: deprecated
release: canary, release: experimental, release: public
platform: v-next, platform: v-current

Label Convention: Management Reporting

Despite (or perhaps because of) Conway’s Law, our systems implementation doesn’t always closely match our business. You may need to produce consolidated reports about uptime, reliability, SLAs, etc., for management that doesn’t closely tie to the reality of how these systems work under the covers. You can use Labels to create reporting groups to simplify these reports.

reporting-group: sla-compliant, reporting-group: alpha, reporting-group: uptime, reporting-group: okr
cost-center: research-and-development, cost-center: cogs
sla: tier-1, sla: best-effort

Label Convention: Severity Level

Alert Policies can also have Labels attached to them. For example:

alert: low, alert: medium, alert: high
channel: emergency, channel: ticket, channel: fyi

Building Your Own Naming Convention

Software is constantly changing, and how you organize and label your services will need to evolve. You may want to “pave the goat paths” and see what works in practice and codify it as a set of conventions. As you learn how to make Labels better, add them to a simple internal wiki page or document that describes your SLO naming convention.

What’s great about a convention (as opposed to a policy) is that you can always make exceptions and experiment with something new. And those familiar with the patterns can provide helpful nudges toward the common vernacular. 

You want to ease the mental leap from SLOs to the running systems they represent. Building on an existing coding standard or naming conventions you already use for services or configuration in your cloud provider is an excellent place to start. Your SLOs and objects in Nobl9 should be idiomatic to your existing environment. Using business- and industry-specific terms will help less-technical users understand the SLOs, reducing the required translation.

Fire Up the Label Maker

We hope you’ll give some label ideas from this article. If you’re a Nobl9 user, look at how your team uses Labels and see what conventions you’re already using. If you’re using Labels in a novel way (or want help), drop us a line and tell us!

If you haven't tried Nobl9 yet, now is a great time to create an account for free at nobl9.com/signup. We even have a step-by-step lab that uses a free synthetic external monitoring account so that you can get started with zero configuration or data access.