Composite SLO essentials

Reading time: 0 minute(s) (0 words)

A composite SLO can include almost any other SLO in your Nobl9 organization. Each component SLO can be based on a different data source, with its own configuration, access permissions, history, and metrics

Nobl9 composite SLOs employ the composite design pattern and use a tree structure to represent the part-whole hierarchy.

This implies specific ways to approach access control, modification, understanding component impact on the entire composite, and the other Nobl9 features. This article describes notable traits and limitations of composite, as well as their interactions with other Nobl9 features and answers potential questions about the related dependencies.

RBAC

Any project roles and permissions provided in the RBAC table below imply user access to the project containing the required SLO.

Learn more about organization and project role permissions.

Permission hierarchy

Access to a component SLO doesn't grant access to the composite that contains it.

Table: Composite SLOs RBAC summary

Action	Permission	Role
Create a composite SLO	Edit SLOs	Project owner, or Project editor, or Organization admin
View a composite SLO and its structure	View the composite SLO	Any project role, or Any organization role, except for Organization user
View component details of a composite SLO	View the composite SLO, and View the component SLO	Any project role for the composite and component, or Any organization role, except for Organization user
Add components to the composite SLO	Edit the composite SLO, and View the component SLOs	Project owner or editor for the composite, and Any project role for the components, or Organization admin

Permissions and cascading effects

A user with edit permissions for a composite SLO can remove a component even if they don't have permissions for the components they remove. Since they lack permissions to the component SLOs, this action is irreversible—they won't be able to add the component back.
Modifying budget-sensitive fields of a component SLO affects the calculations of any composite SLO that includes it. This can happen even if the user editing the component doesn't have access to the composite SLO.

Data consolidation

Composite SLOs use aggregation metrics to combine data from multiple components into a single reliability value. The calculations rely on user-defined weights.

You can select either the reliability or error budget state aggregation metric when creating a composite SLO. The calculation is a weighted mean that depends on the chosen metric.

Aggregation metric	Calculation
Reliability	Nobl9 calculates the weighted means of the components' per-minute reliability values
Error budget state	Each component is assigned a binary status (1 for budget remaining, 0 for exhausted). Nobl9 calculates the weighted mean of these statuses

These calculated per-minute reliabilities are then averaged across the entire composite SLO's time window, resulting in a composite's reliability that is visualized by the Reliability burn down chart.

Delayed data

Since a composite SLO can accommodate SLOs based on different data sources, it has a greater chance of encountering fluctuations in data point density and data delay. To address this, you configure the Max delay and When delayed component properties. These fields are obligatory when creating a composite and aim to handle delayed or sparse data points.

Relative delay

The delay of a component is counted relative to the last point in the most recent component. For example, if a composite has two components whose last points had timestamps 7 and 10 minutes ago, respectively, then the former component is delayed 3 minutes. The most recent component always has no delay. Once the delay of a component exceeds Max delay, Nobl9 applies its When delayed setting.

Use Max delay to set how long Nobl9 will wait for data from a component.

Set a value between 1m and 24h that is greater than or equal to the longest query delay among the component SLOs.

Max delay validation
These restrictions are only enforced during the initial creation of a composite SLO. They are not re-validated if you edit the maxDelay later, nor are they checked if query delays are modified within the component hierarchy.
For multi-level hierarchy composites, the Max delay of the highest-level SLO must be greater or equal to the longest Max delay among all components.
SLOs based on data sources with query delay more than one hour can't be components of a composite SLO.
You can edit the Max delay value at any time.
When all components of the composite cease reporting data, the composite pauses.

Specify how to treat data from delayed components with the When delayed parameter.

For composites with the Occurrences budgeting method, every delayed count-as-good data point restores the error budget.
We recommend setting this value to Count as good for the following SLOs:
- Experimental SLOs where data point delay is rather expected.
- SLOs with sparse metrics.

Nobl9 recommendations

We recommend setting Max delay to the highest acceptable value.

Max delay	Alerts	Composite charts	Composite budget	Explanation for composite budget
Higher	Notifications can be delayed	Older data in charts	More accurate	Higher chance that calculations are based on actual data from the delayed components
Lower	Notifications are sent faster	Fresher data in charts	Less accurate	Higher chance that calculations are based on the delayed components' When delayed settings

We advise against setting Max delay values lower than five minutes: minor delays can be caused by multiple factors like query delay configuration, data source agent unavailability, or network issues, while your composite's error budget calculations will be based on inadequately applied When delayed settings.

Editing and deleting

Generally, any modifications to components don't overwrite already collected data. Consequently, this doesn't influence any reports or charts representing data for past time ranges.

Historical data for the composite, including calculations and charts, remains unaffected after editing this composite SLO or its components, including running Replay.
All further calculations, reports, and charts will be based on the changed configuration.
Modifications in the SLO objective's target, value, and time window restart the composite's error budget calculations.
To address this, change the objective's name along with the required property. It resets the charts and starts new calculations.
After deleting an SLO, it's removed from all composites that include it as a component.
Again; all further calculations, reports, and charts will be based on the updated composite configuration.
- When a component you deleted was the only component of a composite, it remains a composite, although empty.
- Since no component reports data for this composite, the whole composite won't report data, and no error budget will be calculated for it any further.

Composite hierarchy and component weight

Requirement:

Each composite must have exactly one objective.

Allowed actions:

You can create a composite without components.
It will report no data until components are added.

A component can be a part of many composites at a time.

You can reuse a component at different hierarchy levels within the same composite.

A composite can be used as a component of another composite

Restrictions:

A component can't be used more than once at the same hierarchy level.

A composite can't be a component of its descendants.
Circular hierarchy dependencies aren't allowed.

With composite SLOs, you set the component weight. Weight refers to a coefficient of the component's contribution to the entire composite reliability.
Set the weight for your composite's components according to the following requirements:

Weight is mandatory and must be a positive real number.
Due to its proportional nature, scaling this weight (e.g., 1:2, 3:6, or 8:16) has no impact. Only the relative weighting matters.
To keep the component contribution to your composite SLO calculations equal, set the same weight for all of them.

For example

My composite SLO holds three components. The table visualizes the difference between its component contributions:

Component name	Weight	Contribution (normalized weight¹)
My component 1	3	25%
My component 2	4	33.3%
My component 3	5	41.7%

Should their weights be the same, each of them would contribute 33.3%.
A component can burn a fraction of the composite's error budget that is no more than a ratio between the component normalized weight and composite's total error budget (1–target).

¹A normalized weight is the component weight in percent. It shows how much this component weighs proportionally to other components in a composite.

A single component can burn an entire composite's budget

It can occur when the composite target exceeds the component's normalized weight.
Let's take My component 1 (with its weight of 25%), and the composite SLO's target is set to 90%. Then, My component 1 is capable of burning up to 250% of the composite SLO's error budget.

The component weight scales its impact on the entire composite.

Component impact

A component impact on the composite refers to a portion of the composite's error budget burned by the given component.
The impact is considered within the composite SLO's time window.

for example

Let's consider the composite contains two components.

#	Errors per component	Weight	Impact on a composite error budget
1	Component 1: 0 errors Component 2: any number of errors	Any	Component 1: no impact Component 2: 100% impact
2	No errors	Any	Both: no impact
3	Equal	Equal	Both: 50%
4	Component 3: 1 error Component 4: 3 errors	Equal	Component 3: 25% Component 4: 75%

After a component is removed, its impact is still considered until the end of the time window.

Composites and error budget adjustment

When you adjust the budget for the components of your composite, SLOs with a configured adjustment period stop reporting data to their parent composite at the start of their adjustment period. The adjustment period is treated according to your When delayed settings.

The composite stops reporting results if:

The component with the adjusted error budget is the only component of your composite.
All components have adjusted error budgets with adjustments happen at the same time.
Error budget adjustment is applied to the composite itself.
The composite error budget isn't calculated until the adjustment period ends in at least one of its components.
During this time, the entire adjustment period is treated according to your When delayed settings.

The composite keeps reporting results if it receives data from at least one of its components.

Composites and Replay

Currently, you can't replay a composite SLO, but only its components.

Read more about Replay impact on composite SLOs.

Composites and sparse metrics

Sparse metrics reported by components of your composite can impact its overall error budget. The impact depends on the component's Max delay settings and the existence of components with dense metrics.

Dense-metric components	Sparse metric lag vs. Max delay	Result
Yes	Lag<Max delay	Sparse-metric component's data is considered in calculations as usual.
Yes	Lag>Max delay	Sparse-metric component's data is considered in calculations as usual. Time between the last sparse point and the next data point, excluding the Max delay gap, is considered to according your When delayed settings. Subsequent data, including the Max delay gap, is considered based on the next data point.
No	Lag>Max delay OR Lag<Max delay	The composite will pause until next sparse point arrives.

Composites and objective unique identifier grace period

You reference the required SLO by its name in the component hierarchy to include an SLO as a component of your composite. However, the name field is generated automatically for SLOs initially created without explicitly set names. Later you can update their names once with sloctl.

warning

When you add such an SLO as a component for your composite and later update the name, this component will be detached from your composite. So, its data won't be considered in calculations after you've updated the name.

To secure your composite's data integrity, we recommend explicitly setting names for all SLOs you intend to use as components for your composites before adding them to your composite hierarchy.