Skip to main content

SLOs

⛭ Copy SLOs​

You can use sloctl to retrieve the SLO definition and copy/paste it in your YAML configuration.

Read more in sloctl user guide.

⛭ Restore deleted SLOs​

Deletion is permanent. The SLO is removed from Nobl9 and must be re-created.

⛭ An SLO displays odd data​

You may see irrelevant historical data for your SLO if you have deleted an SLO and created a new one using the same project, name, and objectives. The newly created SLO is measured from scratch, but until the data for the new SLO is collected, the service health dashboard shows the status of the deleted SLO.

⛭ Dashboard sort and filtering​

You can sort the dashboard by project in ascending and descending order. You can also filter the dashboard results using labels.

⛭ Project-specific dashboards​

Although individual project dashboards aren't available, you can create project-focused views by filtering existing dashboard with labels.

The matched results feature dedicated link for sharing and bookmarking.

⛭ Multiple-project agent​

An agent can only be associated with one project when it’s created. However, when you create an SLO, you can use the agent from any project.

Read more about Nobl9 agent.

⛭ Common client credentials for multiple agents​

Client IDs and secrets must be unique for each agent.

⛭ Historical metrics retrieval​

Yes, you can retrieve your historical metrics while creating a new SLO with activated Replay.

⛭ Update SLOs​

Our objects are managed in a declarative manner, similar to Kubernetes. As such, making changes to certain specifications creates a new SLO-type object.

If you update an SLO using the sloctl binary and try to change the project with the sloctl apply command, the SLO is duplicated in the new project.

You can use sloctl to move SLOs to another service as long as they belong to the same project.

⛭ Moving SLOs between projects​

You can't move your existing SLOs between projects without losing your SLO's historical data.

Read more about editing SLOs.

⛭ Editing SLOs​

Updating the following settings of an SLO:

  • Target
  • Error budget calculation method
  • Time window

results in losing historical metrics data. Any changes in the above settings reset the error budget of your SLO and remove the budget history.

Read more about editing SLOs.

⛭ SLO sample queries​

Find sample queries in Sources.
Select the required data source from the list on the left and go to Creating SLOs in the UI.

⛭ An SLO fails to receive data​

First, try to restart your agent. If this doesn’t work, contact Nobl9 support.

⛭ Limit SLOs per project, team, or user​

To set limits on SLOs, assign user roles with specific permissions regulating access to them.

Read more about role-based access control.

⛭ Sharing SLOs​

To share an SLO, do the following:

  1. Go to Service Level Objectives.
  2. Click the required SLO to open its details.
  3. Copy a deep link (a URL) to the SLO in the address bar and share it as you need.

⛭ Error budget units of measurement​

In Nobl9, error budgets are measured in percentages. Additionally, we display them as time units to make them easier to comprehend.

Compare:

  • We can sustain another 15 minutes of complete downtime this month, and
  • 33% of a 0.1% error allowance over 28 days remaining.

⛭ Burn rate measurement​

Nobl9 measures burn rates in a standard way:

  • A 1x burn rate means you will burn through (but not exceed) your error budget during your defined time window
  • A burn rate below 1x over an entire time window means you will have an error budget remaining at the end
  • A burn rate above 1x over an entire time window means you will exceed your error budget

⛭ SLO shows a negative error budget burn rate​

If your SLO shows a negative error budget, check if your query is correct or contact Nobl9 Support.

⛭ Error budget is more than 100%​

If your error budget is above 100%, check if your query is correct or contact Nobl9 Support.

⛭ Alert policy removal from an SLO​

Run alert_policies = [] to remove an alert policy from the SLO.

⛭ An SLI chart shows different values for the same time at different time scales​

This can happen when the sum aggregation is set for a non-incremental ratio SLI.
For this SLI type, Nobl9 adds every next data point to the previous point, and the SLI chart displays the sum of these time series.

Zooming in the chart narrows down the timespan for the displayed data, so it covers fewer data, reducing the values you see.

In contrast, when you zoom the chart out, the timespan widens (and captures more data), so the displayed values grow.

Learn more about:

⛭ Querying for data​

By default, Nobl9 queries the data source every minute for the last minute of data. However, the time depends on the data source and query configuration.

Read more about your required data source.

⛭ Reliability increases after a bad event with a high burn rate​

This behavior is natural for rolling time windows. As the time window moves forward, data points expire and appear on a first-in, first-out basis. Once the time window advances enough for the bad event to fall out and be replaced with good ones, the reliability improves.
An old error may expire exactly as soon as a new error arrives. In this case, reliability change depends on the weight of these two errors:

→ The old error = the new error: reliability doesn't change

↘ The old error < the new error: reliability decreases

↗ The old error > the new error: reliability increases

Another scenario explaining why this happens is an SLO with the Occurrences budgeting method with any time window type. This method considers the total number of data points arrived during the period. The more data points come, the less a single data point weighs. Therefore, the good points can eventually outweigh the bad ones even when some bad points are still being registered. As a result, reliability improves.

Check Nobl9 features that will help you troubleshoot:

Event logs Metrics health notifier Query checker Nobl9 agent logging

Last updated on
On this page