{"id":15130518,"url":"https://github.com/openslo/openslo","last_synced_at":"2025-05-14T14:07:48.010Z","repository":{"id":37403930,"uuid":"362280755","full_name":"OpenSLO/OpenSLO","owner":"OpenSLO","description":"Open specification for defining and expressing service level objectives (SLO)","archived":false,"fork":false,"pushed_at":"2025-05-06T09:36:10.000Z","size":1157,"stargazers_count":1402,"open_issues_count":21,"forks_count":61,"subscribers_count":37,"default_branch":"main","last_synced_at":"2025-05-12T07:59:12.714Z","etag":null,"topics":["slo","spec","specification"],"latest_commit_sha":null,"homepage":"https://www.openslo.com","language":"Makefile","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/OpenSLO.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2021-04-27T23:34:53.000Z","updated_at":"2025-05-08T14:16:24.000Z","dependencies_parsed_at":"2023-11-20T10:27:43.742Z","dependency_job_id":"11fa7f19-9d4f-4e84-903f-1eef77588ab0","html_url":"https://github.com/OpenSLO/OpenSLO","commit_stats":null,"previous_names":[],"tags_count":3,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenSLO%2FOpenSLO","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenSLO%2FOpenSLO/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenSLO%2FOpenSLO/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenSLO%2FOpenSLO/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/OpenSLO","download_url":"https://codeload.github.com/OpenSLO/OpenSLO/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254160026,"owners_count":22024567,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["slo","spec","specification"],"created_at":"2024-09-26T03:01:09.905Z","updated_at":"2025-05-14T14:07:47.988Z","avatar_url":"https://github.com/OpenSLO.png","language":"Makefile","funding_links":[],"categories":[],"sub_categories":[],"readme":"#\n\n\u003c!-- markdownlint-disable MD033--\u003e\n\u003cpicture\u003e\n  \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"images/openslo_light.png\"\u003e\n  \u003cimg alt=\"OpenSLO light theme\" src=\"images/openslo.png\"\u003e\n\u003c/picture\u003e\n\u003c!-- markdownlint-enable MD033--\u003e\n\n## Table of Contents\n\n- [Introduction](#introduction)\n- [Specification](#specification)\n  - [Goals](#goals)\n  - [General Schema](#general-schema)\n    - [Notes (General Schema)](#notes-general-schema)\n  - [Custom Data Types](#custom-data-types)\n    - [duration-shorthand](#duration-shorthand)\n  - [Object Types](#object-types)\n    - [DataSource](#datasource)\n      - [Notes (DataSource)](#notes-datasource)\n    - [SLO](#slo)\n      - [Notes (SLO)](#notes-slo)\n      - [Objectives](#objectives)\n        - [Notes (Objectives)](#notes-objectives)\n    - [SLI](#sli)\n      - [Notes (SLI)](#notes-sli)\n      - [Ratio Metric](#ratio-metric)\n    - [AlertPolicy](#alertpolicy)\n      - [Notes (AlertPolicy)](#notes-alertpolicy)\n    - [AlertCondition](#alertcondition)\n      - [Notes (AlertCondition)](#notes-alertcondition)\n    - [AlertNotificationTarget](#alertnotificationtarget)\n      - [Notes (AlertNotificationTarget)](#notes-alertnotificationtarget)\n    - [Service](#service)\n- [Examples](examples/README.md)\n- [Glossary](glossary/README.md)\n- Work in progress for future versions\n  - [v2alpha](enhancements/v2alpha.md)\n- [SDK](#sdk)\n\n## Introduction\n\nThe intent of this document is to outline the OpenSLO specification.\n\nThe goal of this project is to provide an open specification for defining SLOs\nto enable a common, vendor–agnostic approach to tracking and interfacing with\nSLOs. Platform-specific implementation details are purposefully excluded from\nthe scope of this specification.\n\nOpenSLO is an open specification i.e., it is a specification created and\ncontrolled, in an open and fair process, by an association or a standardization\nbody intending to achieve interoperability and interchangeability. An open\nspecification is not controlled by a single company or individual or by a group\nwith discriminatory membership criteria. Additionally, this specification is\ndesigned to be extended where needed to meet the needs of the implementation.\n\nBefore making a contribute please read our [contribution guideline](https://github.com/OpenSLO/OpenSLO/blob/main/CONTRIBUTING.md).\n\n## Specification\n\n### Goals\n\n- Compliance with the Kubernetes YAML format\n- Vendor-agnostic\n- Be flexible enough to be extended elsewhere\n\n### General Schema\n\n```yaml\napiVersion: openslo/v1\nkind: DataSource | SLO | SLI | AlertPolicy | AlertCondition | AlertNotificationTarget | Service\nmetadata:\n  name: string\n  displayName: string # optional\n  labels: # optional, it's allowed to assign multiple values to a single key\n    # example labels\n    organization: \"acme\"\n    team:\n      - \"identity\"\n      - \"rbac\"\n    costCentre: \"project1\"\n    serviceTier:\n      - \"tier-1\"\n  annotations: # optional\n    # example annotations\n    openslo.com/key1: value1\n    fooimplementation.com/key2: value2\nspec:\n```\n\n#### Notes (General Schema)\n\n- **kind** _string_ - required, one of: [DataSource](#datasource), [SLO](#slo),\n  [SLI](#sli), [AlertPolicy](#alertpolicy), [AlertCondition](#alertcondition),\n  [AlertNotificationTarget](#alertnotificationtarget), [Service](#service)\n- **metadata.name:** _string_ - required field\n  - all implementations must at least support object names that follow [RFC1123][rfc1123-names]:\n    - are up to 63 characters in length\n    - contain lowercase alphanumeric characters or `-`\n    - start with an alphanumeric character\n    - end with an alphanumeric character\n- **metadata.labels:** _map[string]string|string[]_ - optional field `key` \u003c\u003e `value`\n  - the `key` segment is required and must contain at most 63 characters beginning and ending\n    with an alphanumeric character `[a-z0-9A-Z]` with dashes `-`, underscores `_`, dots `.`\n    and alphanumerics between.\n  - the `value` of `key` segment can be a string or an array of strings\n- **metadata.annotations:** _map[string]string_ - optional field `key` \u003c\u003e `value`\n  - `annotations` should be used to define implementation / system specific metadata about the SLO.\n    For example, it can be metadata about a dashboard url, or how to name a metric created by the SLI, etc.\n  - `key` have two segments: an optional `prefix` and `name`, separated by a slash `/`\n  - the `name` segment is required and must contain at most 63 characters beginning and ending\n    with an alphanumeric character `[a-z0-9A-Z]` with dashes `-`, underscores `_`, dots `.`\n    and alphanumerics between.\n  - the `prefix` is optional and must be a DNS subdomain: a series of DNS labels separated by dots `.`,\n    it must contain at most 253 characters, followed by a slash `/`.\n  - the `openslo.com/` is reserved for OpenSLO usage\n\n### Custom Data Types\n\n#### duration-shorthand\n\nThe duration shorthand is specified as a single–word string (no whitespaces) consisting\nof a positive integer `number` followed by a case–sensitive single–character `postfix`.\n\nAllowed postfixes are:\n\n- _m_ – minutes\n- _h_ – hours\n- _d_ – days\n- _w_ – weeks\n- _M_ – months\n- _Q_ – quarters\n- _Y_ – years\n\nExamples: `12h`, `4w`, `1M`, `1Q`, `365d`, `1Y`.\n\nThis specification does not put requirements on how (or whether) to implement each\npostfix, therefore implementers are free to pick an implementation that best suits\ntheir environments.\n\nThere is however the possibility that future versions of this spec will take a more\nprescriptive stance on this issue.\n\n### Object Types\n\n\u003e 💡 **Note:** Specific attributes are described in detail in the **Notes**\n\u003e subsection of each object type's section.\n\n#### DataSource\n\nA DataSource represents connection details with a particular metric source.\n\n\u003e [Check work in progress for v2.](enhancements/v2alpha.md#datasource)\n\n```yaml\napiVersion: openslo/v1\nkind: DataSource\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  description: string # optional up to 1050 characters\n  type: string # predefined type e.g. Prometheus, Datadog, etc.\n  connectionDetails:\n    # fields used for creating a connection with particular datasource e.g. AccessKeys, SecretKeys, etc.\n    # everything that is valid YAML can be put here\n```\n\n##### Notes (DataSource)\n\nDataSource enables reusing one source between many SLOs and moving\nconnection specific details (e.g. authentication) away from SLO definitions.\n\nThis spec does not enforce naming conventions for data source types, however\nthe OpenSLO project will publish guidelines in the form of supplementary materials\nonce common patterns start emerging from implementations.\n\nAn example of the DataSource kind can be:\n\n```yaml\napiVersion: openslo/v1\nkind: DataSource\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  type: CloudWatch\n  connectionDetails:\n    accessKeyID: accessKey\n    secretAccessKey: secretAccessKey\n```\n\n---\n\n#### SLO\n\nA service level objective (SLO) is a target value or a range of values for\na service level that is described by a service level indicator (SLI).\n\n\u003e [Check work in progress for v2.](enhancements/v2alpha.md#slo)\n\n```yaml\napiVersion: openslo/v1\nkind: SLO\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  description: string # optional up to 1050 characters\n  service: string # name of the service to associate this SLO with, may refer (depends on implementation) to existing object Kind: Service\n  indicator: # see SLI below for details\n  indicatorRef: string # name of the SLI. Required if indicator is not given.\n  timeWindow:\n    # exactly one item; one of possible: rolling or calendar–aligned time window\n    ## rolling time window\n    - duration: duration-shorthand # duration of the window eg 1d, 4w\n      isRolling: true\n    # or\n    ## calendar–aligned time window\n    - duration: duration-shorthand # duration of the window eg 1M, 1Q, 1Y\n      calendar:\n        startTime: 2020-01-21 12:30:00 # date with time in 24h format, format without time zone\n        timeZone: America/New_York # name as in IANA Time Zone Database\n      isRolling: false # if omitted assumed `false` if `calendar:` is present\n  budgetingMethod: Occurrences | Timeslices | RatioTimeslices\n  objectives: # see objectives below for details\n  alertPolicies: # see alert policies below for details\n```\n\n##### Notes (SLO)\n\n- **indicator** optional, represents the Service Level Indicator (SLI),\n  described in [SLI](#sli) section.\n  One of `indicator` or `indicatorRef` must be given. If declaring composite SLO must be moved into `objectives[]`.\n- **indicatorRef** optional, this is the name of Service Level Indicator (SLI).\n  One of `indicator` or `indicatorRef` must be given. If declaring composite SLO must be moved into `objectives[]`.\n- **timeWindow[ ]** optional, _TimeWindow_ is a list but accepting only exactly one\n  item, one of the rolling or calendar aligned time window:\n\n  - Rolling time window. Duration should be provided in shorthand format\n    e.g. 5m, 4w, 31d.\n  - Calendar Aligned time window. Duration should be provided in shorthand format\n    eg. 1d, 2M, 1Q, 366d.\n\n- **description** _string_ optional field, contains at most 1050 characters\n\n- **budgetingMethod** _enum(Occurrences \\| Timeslices \\| RatioTimeslices)_, required field\n\n  - Occurrences method uses a ratio of counts of good events to the total count of the events.\n  - Timeslices method uses a ratio of good time slices to total time slices in a budgeting period.\n  - RatioTimeslices method uses an average of all time slices' success ratios in a budgeting period.\n\n- **objectives[ ]** _Threshold_, required field, described in [Objectives](#objectives)\n  section. If `thresholdMetric` has been defined, only one Threshold can be defined.\n  However, if using `ratioMetric` then any number of Thresholds can be defined.\n\n- **alertPolicies\\[ \\]** _AlertPolicy_, optional field.\n  section. An alert policy can be defined inline or can refer to an [Alert Policies](#alertpolicy) object,\n  in which case the following are required:\n  - **alertPolicyRef** _string_: this is the name of the AlertPolicy\n\n##### Objectives\n\nObjectives are the thresholds for your SLOs. You can use objectives to define\nthe tolerance levels for your metrics.\n\n```yaml\nobjectives:\n  - displayName: string # optional\n    op: lte | gte | lt | gt # conditional operator used to compare the SLI against the value. Only needed when using a thresholdMetric\n    value: numeric # optional, value used to compare threshold metrics. Only needed when using a thresholdMetric\n    target: numeric [0.0, 1.0) # budget target for given objective of the SLO, can't be used with targetPercent\n    targetPercent: numeric [0.0, 100) # budget target for given objective of the SLO, can't be used with target\n    timeSliceTarget: numeric (0.0, 1.0] # required only when budgetingMethod is set to TimeSlices\n    timeSliceWindow: duration-shorthand # required only when budgetingMethod is set to TimeSlices or RatioTimeslices\n    indicator: # required only when creating composite SLO, see SLI below for more details\n    indicatorRef: string # required only when creating composite SLO, required if indicator is not given.\n    compositeWeight: numeric (0.0, inf+] # optional, supported only when declaring multiple objectives, default value 1.\n```\n\nExample:\n\n```yaml\nobjectives:\n  - displayName: Foo Total Errors\n    target: 0.98\n  - displayName: Bar Total Errors\n    targetPercent: 99.99\n```\n\n###### Notes (Objectives)\n\n- **op** _enum( lte | gte | lt | gt )_, operator used to compare the SLI against the value. Only needed when using a `thresholdMetric`\n\n- **value** _numeric_, required field, used to compare values gathered from\n  metric source. Only needed when using a `thresholdMetric`.\n\nEither `target` or `targetPercent` must be used.\n\n- **target** _numeric [0.0, 1.0)_, optional, but either this or `targetPercent` must\n  be used. Budget target for a given objective of the SLO. A `target: 0.9995` is\n  equivalent to `targetPercent: 99.95`.\n\n- **targetPercent**: _numeric [0.0, 100)_, optional, but either this or `target` must\n  be used. Budget target for a given objective of the SLO. A `targetPercent: 99.95`\n  is equivalent to `target: 0.9995`.\n\n- **timeSliceTarget** _numeric [0.0, 1.0]_, required only when budgeting\n  method is set to TimeSlices\n\n- **timeSliceWindow** _(numeric | duration-shorthand)_, required only when budgeting\n  method is set to TimeSlices or RatioTimeslices. Denotes the size of a time slice for\n  which data will be evaluated e.g. 5, 1m, 10m, 2h, 1d. Also ascertains the frequency\n  at which to run the queries. Default interpretation of unit if specified as a number\n  in minutes.\n\n- **indicator** optional, represents the Service Level Indicator (SLI),\n  described in [SLI](#sli) section.\n  One of `indicator` or `indicatorRef` must be given in objective when creating composite SLO.\n\n- **indicatorRef** optional, this is the name of Service Level Indicator (SLI).\n  One of `indicator` or `indicatorRef` must be given when creating composite SLO.\n\n##### Notes (Composite SLO)\n\n**Composite SLO** goal of composite SLO is to enable user an end-to-end journey, it is done by defining many\nindependent objectives. Each objective can have different queries, data sources and targets. The basic implementation\nassumes that the Composite Error Budget burns if the Error Budget for any of the SLO objectives within the Composite SLO\nis burning. The logic of those calculations is the same for Composite SLOs as for regular (standard) objectives and SLOs.\n\n**Weight** allows the user to change the impact of a given SLO on the whole composite SLO. Weight is just multiplier, it\nmeans that if weight is `0.5`, SLO will have half impact as default, on the other hand if weight is `100`, this SLO will\nbe 100 times more impactful. By default, weight has value 1 and doesn't need to be specified.\n\n**Calculations** should be as simple as possible to make composite SLO intuitive and easy to implement. It is hard to compare\ndifferent error budget calculating methods therefore all composite objectives need to be calculated with one type of error\nbudget calculating method. Here is brief description how given budgeting method should impact composite SLO and how wight scale its\nimpact:\n\n- Occurrences - if SLO burns its budget composite is burning its budget at the same rate. Each violation that consumed\n  SLO's budget will impact Composite at the same rate. Weight multiplies the rate of burning of SLO (referenced as burn\n  rate) that burns composite.\n- Timeslices - this is binary depending on whether it was a good or bad minute. If it was a bad minute for any individual\n  objective, it's considered a bad minute for the Composite SLO.\n- Ratiotimeslices - it is the sum of missing up to 100 percent. If two SLOs have average of Ratiotimeslices on 95%,\n  composite will have average of Ratiotimeslices on 90%. Weight multiplies missing part of given slo.\n\n#### SLI\n\nA service level indicator (SLI) represents how to read metrics from data sources.\n\n\u003e [Check work in progress for v2.](enhancements/v2alpha.md#sli)\n\n```yaml\napiVersion: openslo/v1\nkind: SLI\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  description: string # optional up to 1050 characters\n  thresholdMetric: # either thresholdMetric or ratioMetric must be provided\n    metricSource:\n      metricSourceRef: string # optional, this field can be used to refer to DataSource object\n      type: string # optional, this field describes predefined metric source type e.g. Prometheus, Datadog, etc.\n      spec:\n        # arbitrary chosen fields for every data source type to make it comfortable to use\n        # anything that is valid YAML can be put here.\n  ratioMetric: # either thresholdMetric or ratioMetric must be provided\n    counter:\n      true | false # true if the metric is a monotonically increasing counter,\n      # or false, if it is a single number that can arbitrarily go up or down\n      # ignored when using \"raw\"\n    good: # the numerator, either \"good\" or \"bad\" must be provided if \"total\" is used\n      metricSource:\n        metricSourceRef: string # optional\n        type: string # optional\n        spec:\n          # arbitrary chosen fields for every data source type to make it comfortable to use.\n    bad: # the numerator, either \"good\" or \"bad\" must be provided if \"total\" is used\n      metricSource:\n        metricSourceRef: string # optional\n        type: string # optional\n        spec:\n          # arbitrary chosen fields for every data source type to make it comfortable to use.\n    total: # the denominator used with either \"good\" or \"bad\", either this or \"raw\" must be used\n      metricSource:\n        metricSourceRef: string # optional\n        type: string # optional\n        spec:\n          # arbitrary chosen fields for every data source type to make it comfortable to use.\n\n    rawType:\n      success | failure # required with \"raw\", indicates how the stored ratio was calculated:\n      #  success – good/total\n      #  failure – bad/total\n    raw: # the precomputed ratio stored as a metric, can't be used together with good/bad/total\n      metricSource:\n        metricSourceRef: string # optional\n        type: string # optional\n        spec:\n          # arbitrary chosen fields for every data source type to make it comfortable to use.\n```\n\n##### Notes (SLI)\n\n- **description** _string_ optional field, contains at most 1050 characters\n\nEither `ratioMetric` or `thresholdMetric` must be used.\n\n- **thresholdMetric** _Metric_, represents the query used for\n  gathering data from metric sources. Raw data is used to compare objectives\n  (threshold) values.\n\n- **ratioMetric** _Metric {good, total}, {bad, total} or raw_.\n\n  - **counter** _enum(true \\| false)_, specifies whether the metric is a monotonically\n    increasing counter. Has no effect when using a `raw` query.\n\n  - **good** represents the query used for gathering data from metric sources used\n    as the numerator. Received data is used to compare objectives (threshold)\n    values to find good values. If `bad` is defined then `good` must not be set.\n\n  - **bad** represents the query used for gathering data from metric sources used\n    as the numerator. Received data is used to compare objectives (threshold)\n    values to find bad values. If `good` is defined then `bad` must not be set.\n\n  - **total** represents the query used for gathering data from metric sources\n    that is used as the denominator. Received data is used to compare objectives\n    (threshold) values to find total number of metrics.\n\n  - **rawType** _enum(success \\| failure)_, required when using `raw`, specifies\n    whether the ratios represented by the \"raw\" ratio metric are of successes or failures.\n    Not to be used with `good` and `bad` as picking one of those determines the type of\n    ratio.\n\n  - **raw** represents the query used for gathering already precomputed ratios.\n    The type of ratio (_success_ or _failure_) is specified using `rawType`.\n\nAn example of an SLO where SLI is inlined:\n\n```yaml\napiVersion: openslo/v1\nkind: SLO\nmetadata:\n  name: foo-slo\n  displayName: Foo SLO\nspec:\n  service: foo\n  indicator:\n    metadata:\n      name: foo-error\n      displayName: Foo Error\n    spec:\n      ratioMetric:\n        counter: true\n        good:\n          metricSource:\n            metricSourceRef: datadog-datasource\n            type: Datadog\n            spec:\n              query: sum:trace.http.request.hits.by_http_status{http.status_code:200}.as_count()\n        total:\n          metricSource:\n            metricSourceRef: datadog-datasource\n            type: Datadog\n            spec:\n              query: sum:trace.http.request.hits.by_http_status{*}.as_count()\n  objectives:\n    - displayName: Foo Total Errors\n      target: 0.98\n```\n\n##### Ratio Metric\n\nIf a service level indicator has `ratioMetric` defined, the following maths can\nbe used to calculate the value of the SLI. Below we describe the advised formulas\nfor calculating the indicator value.\n\n_Good-Total queries_\nIf the `good` and `total` queries are given then following formula can be used\nto calculate the value:\n\n```text\nindicatorValue = good / total\n```\n\nIf we have 99 good requests out of a total of 100 requests, the calculated value\nfor the indicator would be: `99 / 100  = 0.99`. This represents 99% on a 0-100 scale\nusing the formula `0.99 * 100 = 99`.\n\n_Bad-Total queries_\nIf the `bad` and `total` queries are given then following formula can be used\nto calculate the value:\n\n```text\nindicatorValue = ( total - bad ) / total\n```\n\nIf we have 1 error out of a total of 100 requests, the calculated value for\nthe indicator would be: `(100 - 1) = 0.99`. This represents 99% on a 0-100 scale\nusing the formula `0.99 * 100 = 99`.\n\n\u003e 💡 **Note:** As you can see for both query combinations we end up with the same calculated\n\u003e value for the service level indicator.\n\nThe required `spec` key will be used to pass extraneous data to the data source. The goal of this approach\nis to provide maximum flexibility when querying data from a particular source. In the following examples\nwe can see that this works fine for both simple and more complex cases.\n\nAn example of **ratioMetric**:\n\n```yaml\nratioMetric:\n  counter: true\n  good:\n    metricSource:\n      type: Prometheus\n      metricSourceRef: prometheus-datasource\n      spec:\n        query: sum(localhost_server_requests{code=~\"2xx|3xx\",host=\"*\",instance=\"127.0.0.1:9090\"})\n  total:\n    metricSource:\n      type: Prometheus\n      metricSourceRef: prometheus-datasource\n      spec:\n        query: localhost_server_requests{code=\"total\",host=\"*\",instance=\"127.0.0.1:9090\"}\n```\n\nAn example of **thresholdMetric**:\n\n```yaml\nthresholdMetric:\n  metricSource:\n    metricSourceRef: redshift-datasource\n    spec:\n      region: eu-central-1\n      clusterId: metrics-cluster\n      databaseName: metrics-db\n      query: SELECT value, timestamp FROM metrics WHERE timestamp BETWEEN :date_from AND :date_to\n```\n\nField `type` can be omitted because the type will be inferred from the DataSource when `metricSourceRef` is specified.\n\nAn example **thresholdMetric** that does not reference a defined DataSource:\n\n```yaml\nthresholdMetric:\n  metricSource:\n    type: Redshift\n    spec:\n      region: eu-central-1\n      clusterId: metrics-cluster\n      databaseName: metrics-db\n      query: SELECT value, timestamp FROM metrics WHERE timestamp BETWEEN :date_from AND :date_to\n      accessKeyID: accessKey\n      secretAccessKey: secretAccessKey\n```\n\nField `type` can't be omitted because the reference to an existing DataSource is not specified.\n\n---\n\n#### AlertPolicy\n\nAn Alert Policy allows you to define the alert conditions for an SLO.\n\n```yaml\napiVersion: openslo/v1\nkind: AlertPolicy\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  description: string # optional up to 1050 characters\n  alertWhenNoData: boolean\n  alertWhenResolved: boolean\n  alertWhenBreaching: boolean\n  conditions: # list of alert conditions\n    - conditionRef: # required when alert condition is not inlined\n  notificationTargets:\n    - targetRef: # required when alert notification target is not inlined\n```\n\n##### Notes (AlertPolicy)\n\n- **description** _string_, optional description about the alert policy, contains at most 1050 characters\n- **alertWhenBreaching** _boolean_, `true`, `false`, whether the alert should be triggered\n  when the condition is breaching\n- **alertWhenResolved** _boolean_, `true`, `false`, whether the alert should be triggered\n  when the condition is resolved\n- **alertWhenNoData** _boolean_, `true`, `false`, whether the alert should be triggered\n  when the condition indicates that no data is available\n- **conditions\\[ \\]** _Alert Condition_, an array, (max of one condition), required field.\n  A condition can be defined inline or can refer to external Alert condition defined in this case the following are required:\n  - **conditionRef** _string_: this is the name of the Alert condition\n- **notificationTargets\\[ \\]** _Alert Notification Target_, required field.\n  A condition can be defined inline or can refer to an [AlertNotificationTarget](#alertnotificationtarget)\n  object, in which case the following are required:\n  - **targetRef** _string_: this is the name of the AlertNotificationTarget\n\n\u003e 💡 **Note:** The `conditions` field is of the type `array` of _AlertCondition_\n\u003e but only allows one single condition to be defined.\n\u003e The use of an array is for future-proofing purposes.\n\nAn example of an Alert policy which refers to another Alert Condition:\n\n```yaml\napiVersion: openslo/v1\nkind: AlertPolicy\nmetadata:\n  name: AlertPolicy\n  displayName: Alert Policy\nspec:\n  description: Alert policy for cpu usage breaches, notifies on-call devops via email\n  alertWhenBreaching: true\n  alertWhenResolved: false\n  conditions:\n    - conditionRef: cpu-usage-breach\n  notificationTargets:\n    - targetRef: on-call-devops-mail-notification\n```\n\nAn example of an Alert Policy where the Alert Condition is inlined:\n\n```yaml\napiVersion: openslo/v1\nkind: AlertPolicy\nmetadata:\n  name: AlertPolicy\n  displayName: Alert Policy\nspec:\n  description: Alert policy for cpu usage breaches, notifies on-call devops via email\n  alertWhenBreaching: true\n  alertWhenResolved: false\n  conditions:\n    - kind: AlertCondition\n      metadata:\n        name: cpu-usage-breach\n        displayName: CPU Usage breaching\n      spec:\n        description: SLO burn rate for cpu-usage-breach exceeds 2\n        severity: page\n        condition:\n          kind: burnrate\n          op: lte\n          threshold: 2\n          lookbackWindow: 1h\n          alertAfter: 5m\n  notificationTargets:\n    - targetRef: on-call-devops-mail-notification\n```\n\n---\n\n#### AlertCondition\n\nAn Alert Condition allows you to define under which conditions an alert for an SLO\nneeds to be triggered.\n\n```yaml\napiVersion: openslo/v1\nkind: AlertCondition\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  description: string # optional up to 1050 characters\n  severity: string # required\n  condition: # required\n    kind: string\n    op: enum\n    threshold: number\n    lookbackWindow: duration-shorthand\n    alertAfter: duration-shorthand\n```\n\n##### Notes (AlertCondition)\n\n- **description** _string_, optional description about the alert condition, contains at most 1050 characters\n- **severity** _string_, required field describing the severity level of the alert (ex. \"sev1\", \"page\", etc.)\n- **condition**, required field. Defines the conditions of the alert\n  - **kind** _enum(burnrate)_ the kind of alerting condition thats checked, defaults to `burnrate`\n\nIf the kind is `burnrate` the following fields are required:\n\n- **op** _enum(lte | gte | lt | gt)_, required field, the conditional operator used to compare against the threshold\n- **threshold** _number_, required field, the threshold that you want alert on\n- **lookbackWindow** _duration-shorthand_, required field, the time-frame for which to calculate the threshold e.g. `5m`\n- **alertAfter** _duration-shorthand_: the duration the condition needs to be valid for before alerting, defaults to `0m`\n\nIf the alert condition is breaching, and the alert policy has `alertWhenBreaching` set to `true`\nthe alert will be triggered\n\nIf the alert condition is resolved, and the alert policy has `alertWhenResolved` set to `true`\nthe alert will be triggered\n\nIf the _service level objective_ associated with the alert condition returns\nno value for the burn rate, for example, due to the service level indicators\nmissing data (e.g. no time series being returned) and the `alertWhenNoData`\nis set to `true` the alert will be triggered.\n\n\u003e 💡 **Note:** The `alertWhenBreaching` and `alertWhenResolved`, `alertWhenNoData` can be combined,\n\u003e if you want an alert to trigger whenever at least one of these conditions is true.\n\n---\n\nAn example of an alert condition:\n\n```yaml\napiVersion: openslo/v1\nkind: AlertCondition\nmetadata:\n  name: cpu-usage-breach\n  displayName: CPU usage breach\nspec:\n  description: If the CPU usage is too high for given period then it should alert\n  severity: page\n  condition:\n    kind: burnrate\n    op: lte\n    threshold: 2\n    lookbackWindow: 1h\n    alertAfter: 5m\n```\n\n---\n\n#### AlertNotificationTarget\n\nAn Alert Notification Target defines the possible targets where alert notifications\nshould be delivered to. For example, this can be a web-hook, Slack or any other\ncustom target.\n\n```yaml\napiVersion: openslo/v1\nkind: AlertNotificationTarget\nmetadata:\n  name: string\n  displayName: string # optional, human readable name\nspec:\n  target: # required\n  description: # optional\n```\n\nAn example Alert Notification Target:\n\n```yaml\napiVersion: openslo/v1\nkind: AlertNotificationTarget\nmetadata:\n  name: OnCallDevopsMailNotification\nspec:\n  description: Notifies by a mail message to the on-call devops mailing group\n  target: email\n```\n\nAlternatively, a similar notification target can be defined for Slack like this:\n\n```yaml\napiVersion: openslo/v1\nkind: AlertNotificationTarget\nmetadata:\n  name: OnCallDevopsSlackNotification\nspec:\n  description: \"Sends P1 alert notifications to the slack channel\"\n  target: slack\n```\n\n##### Notes (AlertNotificationTarget)\n\n- **target** _string_, describes the target of the notification, e.g. Slack, email, web-hook, Opsgenie etc\n- **description** _string_, optional description about the notification target, contains at most 1050 characters\n\n\u003e 💡 **Note:** The way the alert notification targets are is an implementation detail of the\n\u003e system that consumes the OpenSLO specification.\n\u003e\n\u003e For example, if the OpenSLO is consumed by a solution that generates Prometheus recording rules,\n\u003e and alerts, you can imagine that the name of the alert notification gets passed as a label\n\u003e to Alertmanager which then can be routed accordingly based on this label.\n\n---\n\n#### Service\n\nA Service is a high-level grouping of SLO. It may be defined before creating SLO to be able to refer to it in SLO's `spec.service`.\nMultiple SLOs can refer to the same Service.\n\n```yaml\napiVersion: openslo/v1\nkind: Service\nmetadata:\n  name: string\n  displayName: string # optional\nspec:\n  description: string # optional up to 1050 characters\n```\n\n[rfc1123-names]: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names\n\n## SDK\n\n_DISCLAIMER: The SDK is a work in progress and is subject to change._\n\nThe OpenSLO SDK is a set of utilities designed for programmatic access to\nOpenSLO specification.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenslo%2Fopenslo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenslo%2Fopenslo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenslo%2Fopenslo/lists"}