Skip to main content

YAML guide

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

This document explains how Nobl9 configurations are represented in the sloctl API, and how you can express them in .yaml format.

Overall schema​

High-level YAML schema for Nobl9
apiVersion: n9/v1alpha
kind: Agent | Annotation | AlertMethod | AlertPolicy | AlertSilence | BudgetAdjustment |
DataExport | Project | Report | 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
  annotations:
    key: value # String, optional
spec:
  ...

Notes on the overall schema:

FieldTypeDescription
metadata.name
mandatory
stringField 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
stringField 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
stringCan contain max 63 characters. There's no additional validation.
metadata.labels
optional
mapLabels are key-value pairs that can be attached to SLOs, services, projects, and alert policies. Labels are used to select Nobl9 objects and find collections of Nobl9 objects.

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.
metadata.annotations
optional
stringMetadata annotations are non-identifiable key-value pairs that can be attached to SLOs, services, projects, and alert policies. Metadata annotations are used for descriptive purposes only.

Constraints:
• Metadata annotations must be in the key: value format.
• 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 1050 characters.

See metadata annotations for more details.
uniqueness of names

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.

adding labels

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 kinds​

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.

General sample for kind: Agent
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: stable  # 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

FieldTypeDescription
queryDelay.unit
mandatory
enumSpecifies 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
numericSpecifies the value for the query delay.
• Must be a number less than 1440 minutes (24 hours).
• Check query delay documentation for default unit of query delay for each source.
releaseChannel
mandatory
enumSpecifies the release channel. Accepted values: beta | stable.
Replay-related fields
historicalDataRetrieval
optional
n/aOptional 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 defaultDuration.
maxDuration.value
optional
numericSpecifies 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
enumSpecifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day.
defaultDuration.value
optional
numericSpecifies the default duration for historical data retrieval. Must be integer ≥ 0 and ≤ maxDuration.
defaultDuration.unit
optional
enumSpecifies 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 sample for kind: AlertMethods
apiVersion: n9/v1alpha  # Mandatory
kind: AlertMethod  # Mandatory
metadata:
  name: string # Mandatory
  displayName: string # Optional
  project: 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:
    ...

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.

caution

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 sample for kind: AlertPolicy
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
  labels: # A map of labels you want to attach to the AlertPolicy
      "key_1": # Label's key
        - "value_1" # Label's value
        - "value_2" # Label's value
      "key_2": # Label's key
        - "value_1" # Label's value
        - "value_2" # Label's value
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 | budgetDrop  # Mandatory, enum
      value: string or numeric  # Mandatory
      op: lt | gt | lte | gte  # Optional, enum. Only the burnedBudget condition accepts all operators. If omitted, Nobl9 will use the default value. See Table below for default values for all conditions.
      # Only one of the below paramaters are allowed per one condition
      alertingWindow: "0m" # Optional, valid string duration. Default 0 (seconds | minutes | hours). Not allowed for the burnedBudget condition
      # Or
      lastsFor: "0m"  # Optional, valid string duration. Default 0 (seconds | minutes | hours)
  alertMethods:  # You can attach 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

Notes on fields specific to AlertPolicy:

FieldTypeDescription
metadata.annotations
optional
stringMetadata annotations 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 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 1050 characters.

See metadata annotations for more details.
spec.cooldown
mandatory
stringDuration 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
stringMeasurement 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).

    Example in human-readable format: The remaining error budget will be exhausted in 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).

    Example in human-readable format: The entire error budget will be exhausted in 3 days.
• averageBurnRate - how fast the error budget is burning

    Example in human-readable format: Error budget burn rate is 1.1x.

• 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.

    Example in human-readable format: Error budget is above 97%.

    The same example in the UI is represented as Error budget remaining 3%.

    • budgetDrop – the relative drop in the error budget, measured in %
conditions[n].lastsFor
optional
stringOptional 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].alertingWindow
optional
string
conditions[n].op
optional
enumA 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 default value of the operator depends on the measurement type:
• For timeToBurnBudget op=lt
• For timeToBurnEntireBudget op=lte
• For averageBurnRate op=gte
• For burnedBudget op=gte.
• For budgetDrop op=gte
caution

Cooldown on the spec.conditions[] level is allowed but deprecated:

  • If you define cooldown on the spec.conditions[] level, the maximum value from all conditions is saved.

  • If you define cooldown on both the kind: AlertPolicy and spec.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.

General YAML for kind: AlertSilence
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

FieldTypeDescription
spec.alertPolicy
mandatory
stringalertPolicy that AlertSilence will be applied to. spec.alertPolicy must be in the same project as AlertSilence and SLO.
spec.period.startTime
mandatory
stringDefines the date-time point where the alerts will be silenced. Must be in YYYY-MM-DDThh:mm:ssZ format (ISO8601).
spec.period.endTime
mandatory
stringDefines the date-time point where the alerts will be silenced. Must be in YYYY-MM-DDThh:mm:ssZ format (ISO8601).
spec.period.duration
mandatory
stringDefines 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.

General YAML for kind: Annotation
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-DDThh:mm:ssZ # Mandatory, defined start date-time point
  endTime:  YYYY-MM-DDThh:mm:ssZ # Mandatory, defined end date-time point

Notes on fields specific to Annotations:

FieldTypeDescription
metadata.name
mandatory
stringA unique annotation name, required for distinguishing project annotations.
spec.slo
mandatory
stringThe name of the SLO the annotation applies to.
spec.description
optional
stringA string (plain text) describing the annotation. The maximum number of characters is 1000.
spec.startTime
mandatory
stringDefines the date-time point where the annotation will be placed in the graph. The value must be in the YYYY-MM-DDThh:mm:ssZ format that complies with ISO8601. If startTime == endTime, the annotation will be placed at a single time point.
spec.endTime
mandatory
stringDefines the date-time point where the annotation will be placed in the graph. The value must be in the YYYY-MM-DDThh:mm:ssZ format that complies with ISO8601. If startTime == endTime, the annotation will be placed at a single time point.
spec.objectiveName
optional
stringOptional field allowing you to add an annotation to a particular, already existing SLO objective. If not specified, the annotation is attached to the SLO.

BudgetAdjustment​

Budget adjustment allows you to define future periods where planned maintenance, releases, and similar activities won't affect your budget in specific SLOs.

General YAML sample for kind: BudgetAdjustment
apiVersion: n9/v1alpha
kind: BudgetAdjustment
metadata:
  name: string # Mandatory
  displayName: string # Optional
spec:
  description: string # Optional
  firstEventStart: YYYY-MM-DDThh:mm:ssZ # Mandatory, defined start date-time point
  duration: 1h
  rrule: FREQ=DAILY;INTERVAL=1
  filters:
    slos:
      - name: string # Mandatory
        project: string # Mandatory

FieldTypeDescription
spec.firstEventStart
mandatory
stringScheduled start time for the first adjustment event. The expected value must be a string representing the date and time in the RFC3339 format.
spec.duration
mandatory
stringThe duration of the budget adjustment event.
Constraints:
• The expected value for this field is a string formatted as a time duration
• The duration must be at least 1 minute
• The duration must be defined with a precision of 1 second
• Example: 1h10m30s
spec.rrule
mandatory
stringThe iCalendar recurrence rule for the budget adjustment event.Constraints:
• The expected value is a string in the iCal RRULE format.
• Example: FREQ=MONTHLY;BYMONTHDAY=1
• Use RRULE calculator to create the desired recurrence rule.
spec.filters.slos[]
mandatory
stringA list of SLOs that will be attached to the budget adjustment event.

DataExport​

Apply the following YAML to create the configuration to export your data from Nobl9. For more details, see the Data export documentation.

note

DataExport is a premium feature. Contact your Nobl9 sales representative to activate it.

General YAML for kind: DataExport
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

Notes on fields specific to DataExport:

FieldTypeDescription
spec.exportType
mandatory
enumDefine where you want to export your data to: S3 or GCS.
spec.bucketName
mandatory
stringThe 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.

General YAML for kind: Direct
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: stable | beta # 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. Available for data sources connected using the direct method only. Reach out to support@nobl9.com to activate it. Not available for Splunk Observability.
  # 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

FieldTypeDescription
queryDelay.unit
mandatory
enumSpecifies 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
numericSpecifies the value for the query delay.
• Must be a number less than 1440 minutes (24 hours).
• Check query delay documentation for default unit of query delay for each source.
logCollectionEnabled
optional
booleanOptional. Defaults to false. Set to true if you'd like your direct to collect event logs. Contact us to activate it.
releaseChannel
mandatory
enumSpecifies the release channel. Accepted values: beta | stable.
Replay-related fields
historicalDataRetrieval
optional
n/aOptional 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 defaultDuration.
maxDuration.value
optional
numericSpecifies 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
enumSpecifies the unit for the maximum duration of historical data retrieval. Accepted values: Minute | Hour | Day.
defaultDuration.value
optional
numericSpecifies the default duration for historical data retrieval. Must be integer ≥ 0 and ≤ maxDuration.
defaultDuration.unit
optional
enumSpecifies the unit for the default duration of historical data retrieval. Accepted values: Minute | Hour | Day.
note

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.

SLO objective Unique Identifier

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 for spec.objectives
apiVersion: n9/v1alpha
kind: SLO
metadata:
  ...
objectives:
  - displayName: string # Optional
    target: numeric [0.0, 1.0)  # Mandatory, budget target for given objective of the SLO
    value: numeric  # Mandatory. Must be unique for each SLO objective. rawMetrics: the measurement for comparison against the target using the specified operator. countMetrics: legacy field, used as an objective unique identifier only
    op: lte | gte | lt | gt  # Mandatory, enum. An accepted comparative method for labeling an SLI, required for rawMetric only
    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
    target: numeric # Mandatory, budget target for given objective of the SLO
    value: numeric # Mandatory. Must be unique for each SLO objective. rawMetrics: the measurement for comparison against the target using the specified operator. countMetrics: legacy field, used as an objective unique identifier only
    op: lte | gte | lt | gt # Enum, required for rawMetric only
    timeSliceTarget: numeric # Required only if the budgetingMethod is set to Timeslices
...

Notes on the objectives[] sequence array list:

FieldTypeDescription
objectives[n].value
mandatory*
numeric* Mandatory. Must be unique for each SLO objective. In rawMetrics, it's the measurement for comparison against the target using the specified operator. In countMetrics is a legacy field, used as an objective unique identifier only.
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
numericThe 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
metricRepresents 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
booleanDepending 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
metricReceived data is used to compare objective (threshold) values to find good values (see the note below).
countMetrics.total
mandatory
metricReceived data is used to compare objective (threshold) values to find a total number of metrics (see the note below).
sli values for 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.
  • Shouldn't be larger than 1e+20.
threshold values

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.

General example for kind: Project
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.

Report​

kind: Report allows you to define System Health Review.

General YAML sample for kind: Report
apiVersion: n9/v1alpha
kind: Report
metadata:
  name: string # Mandatory
  displayName: string # Optional
spec:
  errorBudgetStatus: {} # Must remain empty
  shared: true # Optional, boolean. Set to true if you want other Nobl9 users to see your report
  filters: # You must specify at least one method of filtering by projects | services | slos
    projects: # A list of projects you want filter your report by
      - string # Mandatory, the name identifier of the project
    services: # A list of services you want filter your report by
      - name: service_name # String, the name identifier of the service
        displayName: ""
        project: project_name # String, the project where the service resides in
    slos: # A list of slos you want filter your report by
      - name: slo_name # String, the name identifier of the SLO
        displayName: ""
        project: project_name # String, the project where SLO resides in
        service: service_name # String, the service where SLO resides in
    labels: # A map of labels you want to filter your report by
      "key_1": # Label's key
        - "value_1" # Label's value
        - "value_2" # Label's value
      "key_2": # Label's key
        - "value_1" # Label's value
        - "value_2" # Label's value

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.

General example for kind: RoleBinding
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:

FieldTypeDescription
metadata.name
mandatory
stringConstraints:
• 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
stringThe project in which we want the user to assume the specified role.
spec.roleRef
mandatory
stringThe role you want the user to assume.
spec.user
mandatory
stringAn 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 example for kind: Service
apiVersion: n9/v1alpha
kind: Service
metadata:
  name: string # Mandatory
  displayName: string # Optional
  project: default # Mandatory, string
spec:
  description: string # Optional

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.

General YAML for kind: SLO
apiVersion: n9/v1alpha  # Mandatory
kind: SLO  # Mandatory
metadata:
  name: string # Mandatory
  displayName: string # Optional
  project: string # Mandatory
spec:
  composite:  # Deprecated. Optional structure for a legacy composite SLO. See the Composite YAML sample for the recommended composite version
    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
      value: numeric # Mandatory. Must be unique for each SLO objective. rawMetrics: the measurement for comparison against the target using the specified operator. countMetrics: legacy field, used as an objective unique identifier only
      displayName: string # Optional
      rawMetric:
        query:
    - target: numeric  # Numeric, second objective defined for the composite SLO
      op: lte | gte | lt | gt  # Mandatory enum for rawMetric only
      value: numeric # Mandatory. Must be unique for each SLO objective. rawMetrics: the measurement for comparison against the target using the specified operator. countMetrics: legacy field, used as an objective unique identifier only
      displayName: string # Optional
      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 up to 20 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

  anomalyConfig:
  # Optional, no data anomaly alerting
  noData:
    # You can add up to five alert methods per SLO
    alertMethods:
    - name: slack-notification
      project: default
    # 5m-31d. Default: 15m
    alertAfter: 15m

FieldTypeDescription
spec.composite
optional
n/aOptional 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/aOptional structure. Mandatory provided the spec.budgetingMethod field is set to Occurrences.
spec.composite.burnRateCondition.value
mandatory
float64Must be a number in the range: (0, 1000].
spec.composite.burnRateCondition.op
mandatory
stringThe only value accepted in this field is gte.
budgetingMethod
mandatory
enumOne 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

Composite​

General YAML for kind: SLO (composites)
- apiVersion: n9/v1alpha
  kind: SLO
  metadata:
    # String, mandatory. The identifier of your composite
    name: my-composite
    # String, optional
    displayName: My composite
    # String, mandatory. The identifier of the project that will hold your composite
    project: my-project
    labels: # A map of labels you want to attach to your composite
      "key_1": # Label's key
        - "value_1" # Label's value
        - "value_2" # Label's value
      "key_2": # Label's key
        - "value_1" # Label's value
        - "value_2" # Label's value
  spec:
    # String, optional
    description: My composite SLO
    # Optional. The array of alert policy name identifiers
    alertPolicies:
      - my-alert-policy-1
      - my-alert-policy-2
    # Optional. The array of key-value pairs
    # Optional. Links you need to attach to your composite
    attachments:
      # String, optional
      - displayName: My attachment
        url: https://my-url.com
    # Enum: Occurrences | Timeslices, mandatory
    budgetingMethod: Occurrences
    objectives:
      # String, optional
      - displayName: My composite objective
        # String, mandatory. The identifier of your composite objective
        name: my-composite-objective
        # Number, mandatory. The target for your composite objective
        target: 0.7
        composite:
          # 1m–1h, mandatory. The maximum time your composite will wait for data from delayed components
          maxDelay: 15m
          # Your composite hierarchy
          components:
            objectives:
              # String, mandatory
              # The identifier of the project that holds the SLO you're including as a component in your composite
              - project: project-1
                # String, mandatory. The identifier of an SLO you're including as a component in your composite
                slo: my-slo-1
                # String, mandatory. The identifier of your component objective
                objective: my-objective-1
                # Number, mandatory
                weight: 1
                # Enum, mandatory: CountAsGood | CountAsBad | Ignore
                whenDelayed: CountAsGood
              - project: project-2
                slo: my-slo-2
                objective: my-objective-2
                weight: 3
                whenDelayed: CountAsBad
    # String, mandatory. The name identifier of the service that will hold your composite
    service: my-service
    timeWindows:
      # Enum, mandatory: Hour| Day | Week | Month
      - unit: Day
        # Number, mandatory. The number of units in your time window
        count: 1
        # Boolean, mandatory: true for rolling time windows, false for calendar-aligned
        isRolling: false
        calendar:
          # A timestamp in the 24h format without the time zone
          startTime: 2020-04-20 10:40:00
          # Your required time zone
          timeZone: Europe/Warsaw
FieldTypeDescription
kind
mandatory*
enumThe resource type
* Use kind: SLO to create and SLO.
metadata.name
mandatory
stringThe name identifier of your composite
Only lowercase alphanumeric characters and dashes. Up to 63 characters.
metadata.project
mandatory
stringThe name identifier of of the project you intend to locate your composite in
Only lowercase alphanumeric characters and dashes. Up to 63 characters.
metadata.displayName
optional
stringA user-friendly name of your composite
metadata.labels
optional
array of objectsThe key: value pairs
For key and value, use only lowercase alphanumeric characters and dashes. Up to 63 characters each.
Up to 20 labels per 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.

Last updated on
On this page