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.
• Access to a composite SLO doesn't grant access to the components it includes.

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 from the hierarchy even if they don't have permissions to view 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 maxDelay and whenDelayed 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 maxDelay, Nobl9 applies its whenDelayed setting.

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

• Set the value 1m–1h.
• Set it to greater or equal to the longest query delay among component SLOs.
• For multi-level hierarchy composites, the maxDelay of the highest-level SLO must be greater or equal to the longest maxDelay 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 maxDelay 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 whenDelayed parameter.

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

Nobl9 recommendations

We recommend setting maxDelay to the highest acceptable value.

maxDelay	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' whenDelayed settings

We advise against setting maxDelay 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 whenDelayed 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 timeWindows restart the composite's error budget calculations. When you revert these properties to their previous values, the error budget calculations continue instead of restarting.
  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 without components.
  • 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 weight1)
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 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 selected 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 against the composite at the start of their adjustment period. The adjustment period is treated according to your whenDelayed 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 whenDelayed 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 maxDelay settings and the existence of components with dense metrics.

Dense-metric components	Sparse metric lag vs. maxDelay	Result
Yes	Lag<maxDelay	Sparse-metric component's data is considered in calculations as usual.
Yes	Lag>maxDelay	Sparse-metric component's data is considered in calculations as usual. Time between the last sparse point and the next data point, excluding the maxDelay gap, is considered to according your whenDelayed settings. Subsequent data, excluding the maxDelay gap, is considered based on the next data point.
No	Lag>maxDelay OR Lag<maxDelay	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 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.

Useful links

Check out these related guides and references:

Access management overviewAccess managementBudget adjustmentsNobl9 featuresQuery delayNobl9 featuresReplayReplay guideSparse metrics and metric accuracySLO calculationsError budgetGlossaryComposite guideComposite SLOs