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.
- 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.
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 longestmaxDelay
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.
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
, andtimeWindows
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:
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.
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).
1As 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.
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.
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 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
.
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.