Composite SLOs 2.0 essentials

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 to the 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

• To create a composite, users need the permission to edit SLOs.
• To view the composite along with its structure, users need the View permission to the composite SLO. However, to access component details, users need the View permission to the required component.
• Access to a component SLO doesn't grant access to the composite that contains it.
• To add components to the composite, users need at least the View permission to the SLOs they intend to add.

The minimum-necessary permissions implications

• Having access to the entire composite, users can remove components from it, even when they don't have access to the components they remove.
  Since they lack access to the component SLOs, users won't be able to add such components back.
• Users can modify components of a composite if they have the editor's permission to these components.
  Even when they have no access to the parent composite, their changes can impact the composite.

Legacy composite SLOs

Generally, composite SLOs 2.0 are not compatible with legacy composite SLOs.

• Legacy composite SLOs cannot be components of a composite SLO 2.0.
• A ratio (countMetric) and threshold (rawMetric) SLO cannot be converted into a composite and vice versa—a composite into a ratio or threshold SLO.
  However, a composite can include a ratio or threshold SLO as a component.

Delayed data

Since a composite SLO 2.0 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.

tip

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 2.0.
• 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 value that is acceptable for you.

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

Composite SLOs 2.0 hierarchy key points:

• Set exactly one objective per composite.
• You can create a composite without children.
  Until you add components to this composite, it will report no data.

A component do's and dont's:

A component can be a part of many composites.

A component can be another composite.

A component can be reused at different hierarchy levels within the same composite.

A component can't be included in the same composite level more than once.

A component, which itself is a composite, can't be a child of its descendants.
In other words, cycles in the hierarchy aren't allowed.

In composite SLOs 2.0 you have the option to 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 composite's error budget that is no more than a ratio between the component weight and composite's total error budget (1–target).

¹As you can see, component weight has a percent representation. Component weight in percent is called a normalized weight. 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.
• Your composite error budget isn't calculated until the adjustment period ends in at least one of its components. 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 operation with composite SLOs 2.0

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

For a more in-depth look, consult additional resources:

Role-based access control in Nobl9RBAC referencesBudget adjustmentsNobl9 featuresQuery delayNobl9 featuresReplayReplay guideSparse metrics and metric accuracySLO calculationsError budgetGlossaryComposite guideComposite SLOs