YAML guide
This document explains how Nobl9 configurations are represented in the sloctl
API, and how you can express them in .yaml format.
Overall schema
apiVersion: n9/v1alpha
kind: Agent | Annotation | AlertMethod | AlertPolicy | AlertSilence |
DataExport | Project | RoleBinding | Service | SLO |
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Optional
labels: # Map, optional
"key_1": # Label's key
- "value_1" # Label's value
spec:
...
Notes on the overall schema:
Field | Type | Description |
---|---|---|
metadata.name mandatory | string | Field following DNS RFC1123 conventions. Constraints: • Max. 63 characters. • Only lowercase alphanumeric characters or hyphens. • Must start and end with an alphanumeric character. |
metadata.project mandatory | string | Field following DNS RFC1123 conventions. Constraints: • Max. 63 characters. • Only lowercase alphanumeric characters or hyphens. • Must start and end with an alphanumeric character. |
metadata.displayName optional | string | Can contain max 63 characters. There's no additional validation. |
metadata.labels optional | map | Labels are key-value pairs that can be attached to SLOs, services, projects, and alert policies. Constraints: • Labels must be in the key: value format (key=value in sloctl ).• key can contain only lowercase alphanumeric characters, underscores, and dashes; must start with a letter and end with an alphanumeric character; maximum length 63 characters.• value can contain Unicode characters; maximum length 200 characters. |
All names must be unique in the scope of one project.
It is not possible to have two objects of the same kind with exactly the same name in a given project.
When adding labels to a YAML definition, remember to put both key
and value
in parentheses (""
), for example:
labels:
"team":
- "green"
Otherwise, sloctl
may return the following error:
Error: malformed JSON payload - pass single list of valid JSON objects.
Overview of available YAML objects
The following sections describe the types of objects that are available in Nobl9 and how to configure them.
Agent
The agent is middleware between the Nobl9 app and an external data source. It gathers metrics data and sends it to Nobl9. Agents need to be installed on the customer's server.
Refer to Sources for details about configuring the agent for each data source via sloctl
.
apiVersion: n9/v1alpha # Mandatory
kind: Agent # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Mandatory
spec:
description: string # Optional
sourceOf:
- Metrics
- Services
releaseChannel: beta # Mandatory, enum
queryDelay:
unit: Second | Minute # Mandatory, enum
value: numeric # Mandatory
datadog:
...
# historicalDataRetrieval is an optional structure related to Replay
# Use only with sources that support it
# Otherwise, sloctl will return a validation error
historicalDataRetrieval:
maxDuration:
value: 0 # Optional, numeric
unit: Minute | Hour | Day # Optional, enum
defaultDuration:
value: 0 # Optional, numeric
unit: Minute | Hour | Day # Optional, enum
Notes on fields specific to Agent
Field | Type | Description |
---|---|---|
queryDelay.unit mandatory | enum | Specifies the unit for the query delay. Possible values: Second | Minute . • Check query delay documentation for default unit of query delay for each source. |
queryDelay.value mandatory | numeric | Specifies the value for the query delay. • Must be a number less than 1440 minutes (24 hours). • Check query delay documentation for default values of query delay for each source. |
releaseChannel mandatory | string | Specifies the release channel. • Must be one of: beta | stable .• See release channels for more details. |
historicalDataRetrieval optional | n/a | Optional structure related to Replay. ❗Use only with supported sources. • If omitted, Nobl9 uses the default values of value: 0 unit: Day for maxDuration and defaultValutaion |
maxDuration.value optional | integer | Specifies the maximum duration for historical data retrieval. Must be integer ≥ 0 . See Replay documentation for values of max duration per data source. |
maxDuration.unit optional | enum | Specifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
defaultDuration.value optional | integer | Specifies the default duration for historical data retrieval. Must be integer ≥ 0 and ≤ value.maxDuration . |
defaultDuration.unit optional | enum | Specifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
If you describe infrastructure as code, you might also consider creating agents via Terraform. You can find more details in our Terraform documentation.
AlertMethod
When an alert is triggered, you can send a notification to an external tool or a REST endpoint (a web service). Alert methods can be associated with all available integrations.
- General YAML
- Working sample
apiVersion: n9/v1alpha # Mandatory
kind: AlertMethod # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
spec:
description: string # Optional
# Only one of the following is possible per one AlertMethod definition
# Refer to alert methods documentation to see detailed specifications
discord:
...
# Or
email:
...
# Or
jira:
...
# Or
msteams:
...
# Or
opsgenie:
...
# Or
pagerDuty:
...
# Or
servicenow:
...
# Or
slack:
...
# Or
webhook:
...
apiVersion: n9/v1alpha
kind: AlertMethod
metadata:
name: discord-notification
displayName: Discord notification
spec:
description: Sends message to Discord channel through webhook
discord:
# Nobl9 general Discord channel
url: <https://discord.com/api/webhooks/809803263775211571/D4-5q51DehrBpOAFND6naV8MgCQwmu1vpAwXrO8vPVflFt1bo6J0wMXzvFAttb_2CRjv>
If you describe infrastructure as code, you might also consider defining the alert methods with the same convention. You can find more details in our Terraform documentation.
AlertPolicy
Alert policies define when to trigger an alert via the configured alert method.
A Nobl9 AlertPolicy
accepts up to three conditions.
All defined conditions must be met to trigger an alert.
In Nobl9 release 1.66.2-3, the previous response from sloctl get alertpolicies
is deprecated, and will be phased out in the future.
In subsequent updates, the command will return only the metadata.name
and metadata.project
fields associated with the alert policy (instead of returning the entire block for the alertMethods
object):
apiVersion: n9/v1alpha
kind: AlertPolicy
metadata:
...
spec:
...
alertMethods:
- metadata:
name: my-alert-method
project: my-project
We'll inform you about the full phase-out in a separate announcement.
- General YAML
- Working sample
apiVersion: n9/v1alpha # Mandatory
kind: AlertPolicy # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Optional, if not defined, Nobl9 returns a default value for this field
spec:
description: string # Optional
severity: Low | Medium | High # Mandatory, enum
cooldown: "5m" # Mandatory, valid string duration, accepted units: s, m, h
conditions:
- measurement: timeToBurnBudget | timeToBurnEntireBudget | averageBurnRate | burnedBudget # Mandatory, enum
value: string or numeric # Mandatory
op: lt | gt | lte | gte # Mandatory, enum
lastsFor: "0m" # Optional, valid string duration. Default 0 (seconds | minutes | hours)
alertMethods: # You can append several alertMethods
- metadata:
name: string # Mandatory, name of the alert method
project: string # Optional, define if you want to use an AlertMethod from a different project than that defined for AlertPolicy
- metadata:
name: string # Mandatory, name of the alert method
project: string # Optional, define if you want to use an AlertMethod from a different project than that defined for AlertPolicy
apiVersion: n9/v1alpha
kind: AlertPolicy
metadata:
name: trigger-alert-policy-bad-delayed-multi
project: trigger-alert
spec:
severity: Medium
cooldown: "5m"
conditions:
- measurement: timeToBurnBudget
value: "18h"
op: lt
lastsFor: "30m"
- measurement: averageBurnRate
value: 1.9
op: gte
lastsFor: "30m"
- measurement: burnedBudget
value: 0.01
op: gte
lastsFor: "30m"
alertMethods:
- metadata:
name: webhook-global-notification
project: server-production
- metadata:
name: webhook-notification
Notes on fields specific to AlertPolicy
:
Field | Type | Description |
---|---|---|
spec.cooldown mandatory | string | Duration representing the time measured since the last time point when all conditions were satisfied. Constraints:• Default value: 5m .• Accepted units: Seconds | Minutes | Hours. Examples: 5m , 1h , 30s .• The minimum allowable value is 5m , with no upper limit.• Must adhere to a valid time string duration format, see parse duration for more details. |
conditions[n].measurement mandatory | string | Measurement options for the condition:•timeToBurnBudget When the remaining error budget will be exhausted. The expected value is a string in time duration format; for example, 72h (3 days).
timeToBurnEntireBudget When the entire error budget will be exhausted. The expected value is a string in time duration format; for example, 72h (3 days).
averageBurnRate - how fast the error budget is burning
burnedBudget how much error budget has already been burnt. This contrasts with the UI, where the error budget is expressed in terms of the remaining amount. Each option corresponds to a specific measurement value and format.
3% . |
conditions[n].lastsFor optional | string | Optional field indicating how long a given condition needs to be valid to mark the condition as true. • Default: 0 (seconds)• Accepted units: Seconds | Minutes | Hours • Examples: 5m , 1h , 30s |
conditions[n].op mandatory* | enum | * Mandatory for rawMetrics only.A mathematical inequality operator; possible values are: • lte - less than or equal to (≤ )• gte - greater than or equal to (≥ ), lt - less than (< )• gt - greater than (> ). The operator depends on the measurement type: • For timeToBurnBudget op=lt • For averageBurnRate op=gte • For burnedBudget op=gte . |
Cooldown on the spec.conditions[]
level is allowed but deprecated:
-
If you define
cooldown
on thespec.conditions[]
level, the maximum value from all conditions is saved. -
If you define
cooldown
on both thekind: AlertPolicy
andspec.conditions[]
levels, Nobl9 will return a validation error.
If you describe infrastructure as code, you can also define the alert policy with the same convention. You can find more details in our Terraform documentation.
AlertSilence
AlertSilence
allows you to turn off alerts that are attached to an SLO for a defined period of time. For more details, see Silencing alerts.
apiVersion: n9/v1alpha
kind: AlertSilence
metadata:
name: alert-silence-name
project: default
spec:
description: AlertSilence description
slo: slo-name # the name of the SLO AlertSilence will be applied to
alertPolicy:
name: alert-policy-name # the name of the AlertPolicy AlertSilence will be applied to
period: # define period for the AlertSilence
startTime: 2025-01-01T12:00:00+02:00 # define the start date-time point where the Alerts will be silenced
endTime: 2025-01-01T13:00:00+02:00 # define the start date-time point where the Alerts will be silenced
duration: 1h # Mandatory, valid string duration
Notes on fields specific to AlertSilence
Field | Type | Description |
---|---|---|
spec.alertPolicy mandatory | string | alertPolicy that AlertSilence will be applied to. spec.alertPolicy must be in the same project as AlertSilence and SLO . |
spec.period.startTime mandatory | string | Defines the date-time point where the alerts will be silenced. Must be in YYYY-MM-DDTh:mm:ssZ format (ISO8601). |
spec.period.endTime mandatory | string | Defines the date-time point where the alerts will be silenced. Must be in YYYY-MM-DDTh:mm:ssZ format (ISO8601). |
spec.period.duration mandatory | string | Defines the duration for which alerts will be silenced from the applying time. Accepted units: s | m | h . |
Annotation
The SLO annotations service lets Nobl9 users add notes to their metrics. For more details, refer to SLO annotations.
apiVersion: n9/v1alpha
kind: Annotation
metadata:
name: string # Mandatory
project: string # Mandatory, the name of the project the annoation is attached to
spec:
slo: string # Annotation's objective
description: string # Optional
objectiveName: string # Optional, must refer to existing SLO Objective
startTime: YYYY-MM-DDTh:mm:ssZ # Mandatory, defined start date-time point
endTime: YYYY-MM-DDTh:mm:ssZ # Mandatory, defined end date-time point
Notes on fields specific to Annotations
:
Field | Type | Description |
---|---|---|
metadata.name mandatory | string | A unique annotation name, required for distinguishing project annotations. |
spec.slo mandatory | string | The name of the SLO the annotation applies to. |
spec.description optional | string | A string (plain text) describing the annotation. The maximum number of characters is 1000. |
spec.startTime mandatory | string | Defines the date-time point where the annotation will be placed in the graph. The value must be in the YYYY-MM-DDTh:mm:ssZ format that complies with ISO8601. If startTime == endTime , the annotation will be placed at a single time point. |
spec.endTime mandatory | string | Defines the date-time point where the annotation will be placed in the graph. The value must be in the YYYY-MM-DDTh:mm:ssZ format that complies with ISO8601. If startTime == endTime , the annotation will be placed at a single time point. |
spec.objectiveName optional | string | Optional field allowing you to add an annotation to a particular, already existing SLO objective. If not specified, the annotation is attached to the SLO. |
DataExport
Apply the following YAML to create the configuration to export your data from Nobl9. For more details, see the Data export documentation.
DataExport
is a premium feature. Contact your Nobl9 sales representative to activate it.
- General YAML
- Working YAML
apiVersion: n9/v1alpha
kind: DataExport
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Optional
spec:
exportType: S3 | GCS # Mandatory, enum
spec:
bucketName: string # Mandatory
roleArn: string # Mandatory
Here’s a working example of YAML for exporting your data through sloctl
:
apiVersion: n9/v1alpha
kind: DataExport
metadata:
name: s3-data-export
displayName: S3 data export
project: default
spec:
exportType: S3
spec:
bucketName: examplebucket
roleArn: arn:aws:iam::123456789:role/example
Notes on fields specific to DataExport
:
Field | Type | Description |
---|---|---|
spec.exportType mandatory | enum | Define where you want to export your data to: S3 or GCS. |
spec.bucketName mandatory | string | The name of the S3 or GCS bucket. |
spec.roleArn mandatory* | string | * Mandatory for S3 and Snowflake export types. This is the Amazon Resource Name (ARN) of the role that the Nobl9 agent is assuming to upload files. |
Direct
Direct configuration gathers metrics data directly from the external source based on provided credentials. You don't need to install anything on your server side.
Check Sources for details about configuring the direct for each data source via sloctl
.
apiVersion: n9/v1alpha
kind: Direct
metadata:
name: string # Mandatory
displayName: string # Optional
project: default # Mandatory, string
spec:
description: string # Optional
sourceOf:
- Metrics
- Services
# Only one type of source configuration is allowed for Direct, for example:
appDynamics:
...
releaseChannel: beta | stable # Mandatory, enum
queryDelay:
unit: Second | Minute # Mandatory, enum
value: numeric # Mandatory, must be a number less than 1440 minutes (24 hours)
logCollectionEnabled: false # Boolean, defaults to 'false'. Set to true if you'd like your source to collect logs. It's a beta functionality available only through direct release channel. Reach out to support@nobl9.com to activate it.
# historicalDataRetrieval is an optional structure related to Replay
# Use only with sources that support it
# Otherwise, sloctl will return a validation error
historicalDataRetrieval:
maxDuration:
value: numeric # Optional
unit: Minute | Hour | Day # Optional, enum
defaultDuration:
value: numeric # Optional
unit: Minute | Hour | Day # Optional, enum
Important notes on fields specific to Direct
Field | Type | Description |
---|---|---|
queryDelay.unit mandatory | enum | Specifies the unit for the query delay. Possible values: Second | Minute . • Check query delay documentation for default unit of query delay for each source. |
queryDelay.value mandatory | numeric | Specifies the value for the query delay. • Must be a number less than 1440 minutes (24 hours). • Check query delay documentation for default values of query delay for each source. |
logCollectionEnabled optional | boolean | Defaults to false . Set to true if you'd like your source to collect event logs. Beta functionality available only through direct release channel. Reach out to support@nobl9.com to activate it. |
historicalDataRetrieval optional | n/a | Optional structure related to configuration related to Replay. ❗ Use only with supported sources. • If omitted, Nobl9 uses the default values of value: 0 and unit: Day for maxDuration and defaultValutaion |
maxDuration.value optional | integer | Specifies the maximum duration for historical data retrieval. Must be integer ≥ 0 . See Replay documentation for values of max duration per data source. |
maxDuration.unit optional | enum | Specifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
defaultDuration.value optional | integer | Specifies the default duration for historical data retrieval. Must be integer ≥ 0 and ≤ value.maxDuration . |
defaultDuration.unit optional | enum | Specifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day . |
Be cautious with the authentication details you input into the direct
YAML configuration. These details are encrypted and kept safe within Nobl9.
If you describe infrastructure as code, you might also define the alert policy with the same convention. You can find more details in our Terraform documentation.
Objective
Objectives are the thresholds for your SLOs. You can use objectives to define the tolerance levels for your metrics.
An SLO objective unique identifier allows setting the same value for different SLIs within the same SLO.
As such, Nobl9 is adding a name
identifier to each SLO objective to ensure uniqueness in error budget calculations.
For more detailed information,
check SLO objective unique identifier.
- General YAML
- Working sample
apiVersion: n9/v1alpha
kind: SLO
metadata:
...
objectives:
- displayName: string # Optional
op: lte | gte | lt | gt # Mandatory, enum. An accepted comparative method for labeling an SLI, required for rawMetric only
value: numeric # Use withrawMetric only; all objectives of the SLO must have unique values
target: numeric [0.0, 1.0) # Mandatory, budget target for given objective of the SLO
timeSliceTarget: numeric (0.0, 1.0] # Required only when budgetingMethod is set to Timeslices
countMetrics:
# countMetrics {good, total} should be defined only if rawMetric is not set
# If rawMetric is defined on the SLO level, raw data received from metric source is compared with objective value
# countMetrics good and total must contain the same source type configuration
incremental: true | false # Enum, mandatory
good: # Mandatory, query for good occurrences
total: # Mandatory, query for total occurrences
- displayName: string # Optional
value: numeric # Use with rawMetrics and countMetrics with multiple objectives; value must unique for all objectives
target: numeric # Mandatory
op: lte | gte | lt | gt # Enum, required for rawMetric only
timeSliceTarget: numeric # Required only if the budgetingMethod is set to Timeslices
...
apiVersion: n9/v1alpha
kind: SLO
metadata:
name: webapp-frontend
displayName: WebApp frontend service
project: default
spec:
description: SLO tracking the uptime for our frontend service
service: webapp-service
indicator:
metricSource:
name: prometheus-source
timeWindows:
- unit: Week
count: 1
calendar:
startTime: 2020-01-21 12:30:00
timeZone: America/New_York
isRolling: false
budgetingMethod: Occurrences
objectives:
- displayName: string
value: 0.95
target: 0.99
countMetrics:
incremental: true
good:
prometheus:
query: "sample query"
total:
prometheus:
query: "sample query"
alertPolicies:
- pagerduty-alert
Notes on the objectives[]
sequence array list:
Field | Type | Description |
---|---|---|
objectives[n].value mandatory* | numeric | * Mandatory for rawMetrics and countMetrics with multiple objectives only.The value field is used to compare values gathered from the metric source. |
objectives[n].op mandatory* | enum | * Mandatory for rawMetrics only.A mathematical inequality operator; possible values for this field are: • lte - less than or equal (≤) • gte - greater than or equal (≥ )• lt - less than (< )• gt - greater than (> ) |
objectives[n].target mandatory | numeric | The budget target for the given objective of the SLO • Accepted range: [0.0, 1.0) |
objectives[n].timeSliceTarget mandatory* | numeric | * Mandatory only when budgetingMethod is set to Timeslices . • Accepted range: (0.0, 1.0] |
objectives[n].countMetrics mandatory | metric | Represents the query used for gathering data from metric sources. countMetrics compares two time series, indicating the ratio of the count of good values to total values for the measured occurrences.❗If the countMetrics field is defined, it's not possible to set rawMetric on the SLO level. |
countMetrics.incremental mandatory | boolean | Depending on the method of counting data (check the SLO calculations guide for more details): • If set to true (incremental method), Nobl9 expects the value of a metric to be the current sum of some numerator• If set to false (non-incremental method), Nobl9 expects it to be the components of the sum |
countMetrics.good mandatory | metric | Received data is used to compare objective (threshold) values to find good values (see the note below). |
countMetrics.total mandatory | metric | Received data is used to compare objective (threshold) values to find a total number of metrics (see the note below). |
good
and total
When choosing the query for the ratio SLI (countMetrics
), keep in mind that the values resulting from that query for both good and total:
- Must be positive.
- While we recommend using integers, fractions are also acceptable.
- If using fractions, we recommend them to be larger than
1e-4
=0.0001
.
- If using fractions, we recommend them to be larger than
- Shouldn't be larger than
1e+20
.
Nobl9 uses the threshold value to identify specific objectives to enable uniqueness in error budget calculations.
Set a unique target value across all objectives within one composite SLO. Each objective of the SLO must have unique values.
If you apply an SLO using countMetrics
with multiple objectives, make sure that the value for each objective is unique:
...
objectives:
- countMetrics:
...
name: objective-1
target: 0.95
value: 1
- countMetrics:
...
name: objective-2
target: 0.91
value: 2
For more details, check Composite guide.
Project
Projects are the primary grouping of resources in Nobl9. For more details, see projects in the Nobl9 platform.
apiVersion: n9/v1alpha
kind: Project
metadata:
name: string # Mandatory
spec:
description: string # Optional
If you describe infrastructure as code, you can create a project with the same convention. You can find more details in our Terraform documentation.
RoleBinding
A single RoleBinding
object allows the definition of the relation between exactly one user and exactly one role. Refer to RoleBinding for more details about managing role bindings via sloctl
.
apiVersion: n9/v1alpha
kind: RoleBinding
metadata:
name: string # Mandatory, role name followed by username; for example, project-owner-adam
spec:
projectRef: string # Mandatory, referenced project
roleRef: string # Mandatory, referenced role
user: string # Mandatory, Okta User ID
Notes on fields specific to RoleBinding
:
Field | Type | Description |
---|---|---|
metadata.name mandatory | string | Constraints: • The name must follow conventions defined in DNS RFC 1123. Refer to YAML Guide for further details. • If you create RoleBinding manually with sloctl , you can put any valid string for the name.• The name must be unique in an organization (for the Organization roles) or a project (for the Project roles).• RoleBinding created with sloctl is edited in Nobl9 UI. If you create project-owner-adam with sloctl , this object will be available on the Settings > Access Controls tab list in the UI. Then, you can edit the project-owner-adam object on the Users list.• If you configure a role in the UI first, it will generate a UUID for the name, and you need to get the RoleBinding through sloctl . |
spec.projectRef optional | string | The project in which we want the user to assume the specified role. |
spec.roleRef mandatory | string | The role you want the user to assume. |
spec.user mandatory | string | An Okta User ID that can be retrieved from the Nobl9 UI (Settings > Access Controls). |
If you describe infrastructure as code, you can manage role bindings with the same convention. You can find more details in our Terraform documentation.
Service
A service in Nobl9 is a high-level grouping of service level objectives (SLOs). A service can represent a logical service endpoint like an API, a database, an application, or anything else you care about setting an SLO for. Every SLO in Nobl9 is tied to a service, and service can have one or more SLOs.
- General YAML
- Working YAML
apiVersion: n9/v1alpha
kind: Service
metadata:
name: string # Mandatory
displayName: string # Optional
project: default # Mandatory, string
spec:
description: string # Optional
apiVersion: n9/v1alpha
kind: Service
metadata:
name: webapp-service
displayName: WebApp Service
project: default
spec:
description: Service to connect to internal notification system
If you describe infrastructure as code, you can create a service with the same convention. You can find more details in our Terraform documentation.
SLO
An SLO is a target value or range of values for a service that is measured by a service level indicator (SLI). SLOs allow you to define the reliability of your products and services in terms of customer expectations. You can create SLOs for user journeys, internal services, or even infrastructure.
apiVersion: n9/v1alpha # Mandatory
kind: SLO # Mandatory
metadata:
name: string # Mandatory
displayName: string # Optional
project: string # Mandatory
spec:
composite: # Optional structure for a composite SLO
target: float64 # Defined target for the SLO
burnRateCondition: # If budgetingMethod is set to Timeslices, this field should be removed
value: float64 # Mandatory
op: gte # Mandatory, gte is the only value accepted; any other value will result in a validation error
budgetingMethod: Occurrences | Timeslices # Mandatory, enum
description: string # Optional, max 1050 characters
service: string # Mandatory, name of the service you defined (must be in the same project as the SLO)
indicator:
metricSource:
name: string # Mandatory, name of the data source
project: string # Optional, if not defined, it is the same project as the SLO
kind: string # Optional, defaults to "Agent" (possible values: Agent)
rawMetric: # RawMetric must be defined here once, or defined per each objective
query:
objectives: # You can define from 1 to 12 objectives per SLO
- target: numeric # Numeric, first objective defined for the composite SLO (example values)
op: lte | gte | lt | gt # Mandatory enum for rawMetric only
displayName: string # Optional
value: numeric # Mandatory
rawMetric:
query:
- target: numeric # Numeric, second objective defined for the composite SLO
op: lte | gte | lt | gt # Mandatory enum for rawMetric only
displayName: string # Optional
value: numeric
rawMetric:
query:
timeWindows:
# Exactly one of the following, depending on the type of time window:
# Rolling time window
- unit: Day | Hour | Minute # Mandatory, enum
count: numeric
isRolling: true
# or
# Calendar-aligned time window
- unit: Year | Quarter | Month | Week | Day # Mandatory, enum
count: numeric # Count of time units; for example, count: 7 and unit: Day means 7-day window
calendar:
startTime: "2020-01-21T12:30:00" # Date with time in 24h format, format without time zone
timeZone: America/New_York # Name as in IANA Time Zone Database
isRolling: false # Boolean, false or not defined
alertPolicies:
- string # The name of the alert policy associated with this SLO (must be from the same project as the SLO).
# You can define 0 to 5 alert policies per SLO.
attachments:
# You can add up to 20 links to an SLO.
- displayName: string # Optional, display name for the title of the link; max. length: 63 characters. The URL is used as a link title when the Display Name field is empty.
url: string # The URL to the service related to the SLO
- High-level specs
- Define rawMetric - method 1
- Define rawMetric - method 2
- Define timeWindows
- Define alertPolicies
Field | Type | Description |
---|---|---|
spec.composite optional | n/a | Optional structure for configuring a Composite SLO. |
spec.composite.target mandatory* | float64 | * Mandatory provided that the spec.composite field is defined. |
spec.composite.burnRateCondition optional | n/a | Optional structure. Mandatory provided the spec.budgetingMethod field is set to Occurrences . |
spec.composite.burnRateCondition.value mandatory | float64 | Must be a number in the range: (0, 1000]. |
spec.composite.burnRateCondition.op mandatory | string | The only value accepted in this field is gte . |
budgetingMethod mandatory | enum | One of Occurrences | Timeslices ):• Occurrences method uses a count ratio of good events to total events. See Occurrences to learn more• Timeslices method uses a ratio of good time slices vs. total time slices in a budgeting period. See Timeslices to learn more |
You can define rawMetric the rawMetric
for an SLO on the spec.indicator
level:
Field | Type | Description |
---|---|---|
spec.indicator.metricSource.name mandatory | string | Identifies the name of the data source. |
spec.indicator.metricSource.project mandatory | string | Optional field indicating the project of the data source. |
spec.indicator.metricSource.kind mandatory | enum | Identifies the type of data source (Agent or Direct ). |
spec.indicator.rawMetric.query mandatory | string | This field won't be returned, when using the sloctl get slos command. |
Even when a query is defined directly on the spec
level (spec.indicator.rawMetric
) Nobl9 will return MetricSpec defined on the objectives
level.
You can also define rawMetric
on the spec.objectives
level:
Field | Type | Description |
---|---|---|
spec.objectives[n].rawMetric.query | structure | Optional structure that allows the user to set metric spec per single objective.• This field represents the query used for gathering data from metric sources. Raw data is used to compare objective (threshold) values• If rawMetric is defined it is not possible to set countMetrics on the objective level. Refer to Sources for more details about metric specifications for different integrations• The query on the spec level is returned by default (for example, when using sloctl get slos command) |
-
timeWindows[]
- a list that accepts exactly one item, the rolling or calendar-aligned time window:- Rolling time windows - minimum duration is 5 minutes, maximum 31 days.
...
unit: Day | Hour | Minute
count: numeric
isRolling: true- Calendar-aligned time windows - minimum duration is one day, maximum 366 days.
...
unit: Year | Quarter | Month | Week | Day
count: numeric
calendar:
startTime: 2020-01-21 12:30:00 # date with time in a 24h format
timeZone: America/New_York # name as in IANA Time Zone Database
isRolling: false # for calendar-aligned set to false or do not set
Field | Type | Description |
---|---|---|
alertPolicies[] optional | string (list) | • A list of alert policy names that can trigger alerts for this SLO when all conditions are met • Can contain 0 to 5 items • Alert policies must be created in the same project as the SLO |
If you describe infrastructure as code, you can define your SLO with the same convention. You can find more details in our Terraform documentation.