Construções na API

Este documento apresenta as estruturas usadas para representar serviços e SLOs na API do SLO e os mapeia para os conceitos descritos em geral em Conceitos de monitoramento de serviço .

A API SLO é usada para configurar objetivos de nível de serviço (SLOs) que podem ser usados ​​para monitorar a integridade dos seus serviços.

O Service Monitoring adiciona os seguintes recursos à API Monitoring:

Para obter informações sobre como invocar a API, consulte Trabalhando com a API .

Serviços

Um serviço é representado por um objeto Service . Este objeto inclui os seguintes campos:

  • Um nome: um nome de recurso totalmente qualificado para este serviço
  • Um nome de exibição: um rótulo para uso em componentes do console
  • Uma estrutura para um dos tipos BasicService .
  • Um objeto de configuração de telemetria fornecido pelo sistema

Para definir um serviço básico, especifique o tipo de serviço e forneça um conjunto de rótulos específicos do serviço que descrevem o serviço:

{
   "serviceType": string,
   "serviceLabels": {
      string: string,
      ...
   }
}

As seções a seguir fornecem exemplos para cada tipo de serviço.

Tipos de serviços básicos

Esta seção fornece exemplos de definições de serviços criadas no tipo BasicService , em que o valor do campo serviceType é um dos seguintes:

  • APP_ENGINE
  • CLOUD_ENDPOINTS
  • CLUSTER_ISTIO
  • ISTIO_CANONICAL_SERVICE
  • CLOUD_RUN

Cada um desses tipos de serviço utiliza o indicador de nível de serviço BasicSli .

Motor de aplicação 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "APP_ENGINE",
          "serviceLabels": {
            "module_id": "MODULE_ID"
          },
      },
    }

Terminais de nuvem 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLOUD_ENDPOINTS",
          "serviceLabels": {
            "service": "SERVICE"
          },
      },
    }

Cluster Istio 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLUSTER_ISTIO",
          "serviceLabels": {
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "service_namespace": "SERVICE_NAMESPACE",
            "service_name": "SERVICE_NAME"
          },
      },
    }

Serviço canônico do Istio 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "ISTIO_CANONICAL_SERVICE",
          "serviceLabels": {
            "mesh_uid": "MESH_UID",
            "canonical_service_namespace": "CANONICAL_SERVICE_NAMESPACE",
            "canonical_service": "CANONICAL_SERVICE"
          },
      },
    }

Execução na nuvem 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLOUD_RUN",
          "serviceLabels": {
            "service_name": "SERVICE_NAME",
            "location": "LOCATION"
          },
      },
    }

Tipos básicos de serviço do GKE

Esta seção contém exemplos de definições de serviço do GKE criadas com base no tipo BasicService , em que o valor do campo serviceType é um dos seguintes:

  • GKE_NAMESPACE
  • GKE_WORKLOAD
  • GKE_SERVICE

Você deve definir SLIs para esses tipos de serviço. Eles não podem usar indicadores de nível de serviço BasicSli . Para obter mais informações, consulte Indicadores de nível de serviço .

Namespace do GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_NAMESPACE",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME"
          }
      },
    }

Carga de trabalho do GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_WORKLOAD",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME",
            "top_level_controller_type": "TOPLEVEL_CONTROLLER_TYPE",
            "top_level_controller_name": "TOPLEVEL_CONTROLLER_NAME",
          }
      },
    }

Serviço do GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_SERVICE",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME",
            "service_name": "SERVICE_NAME"
          }
      },
    }

Serviços personalizados

Você poderá criar serviços customizados se nenhum dos tipos de serviços básicos for adequado. Um serviço personalizado se parece com o seguinte: 

    {
      "displayName": "DISPLAY_NAME",
      "custom": {}
    }

Você deve definir SLIs para esses tipos de serviço. Eles não podem usar indicadores de nível de serviço BasicSli . Para obter mais informações, consulte Indicadores de nível de serviço .

Indicadores de nível de serviço

Um indicador de nível de serviço (SLI) fornece uma medida do desempenho de um serviço. Um SLI é baseado na métrica capturada pelo serviço. A forma exacta como o SLI é definido depende do tipo de métrica utilizada como métrica de indicador, mas geralmente é uma comparação entre resultados aceitáveis ​​e resultados totais.

Um SLI é representado pelo objeto ServiceLevelIndicator . Este objeto é uma forma coletiva de referir os três tipos de SLIs suportados:

  • Um SLI básico, criado automaticamente para instâncias do tipo de serviço BasicService . Este tipo de SLI é descrito em Objetivos de nível de serviço ; ele é representado por um objeto BasicSli e mede a disponibilidade ou latência.

  • Um SLI baseado em solicitação, que pode ser usado para contar eventos que representam um serviço aceitável. O uso desse tipo de SLI é descrito em SLOs baseados em solicitação ; ele é representado por um objeto RequestBasedSli .

  • Um SLI baseado em janela, que você pode usar para contar períodos de tempo que atendem a algum critério de qualidade. O uso desse tipo de SLI é descrito em SLOs baseados em Windows ; ele é representado por um objeto WindowsBasedSli .

Por exemplo, o seguinte mostra um SLI de disponibilidade básica: 

{
  "basicSli": {
    "availability": {},
    "location": [
      "us-central1-c"
    ]
  }
}

Estruturas para SLIs baseados em solicitações

Um SLI baseado em solicitação é baseado em uma métrica que conta unidades de serviço como uma proporção entre um resultado específico e o total. Por exemplo, se você usar uma métrica que conte solicitações, poderá construir a proporção entre o número de solicitações que retornam sucesso e o número total de solicitações.

Existem duas maneiras de construir um SLI baseado em solicitação:

  • Como TimeSeriesRatio , quando a proporção entre serviço bom e serviço total é calculada a partir de duas séries temporais cujos valores possuem um tipo de métrica DELTA ou CUMULATIVE .
  • Como DistributionCut , quando a série temporal possui tipo de valor DISTRIBUTION e cujos valores possuem uma métrica do tipo DELTA ou CUMULATIVE . O valor do bom serviço é a contagem de itens que se enquadram nos intervalos do histograma em um intervalo especificado, e o total é a contagem de todos os valores na distribuição.

Veja a seguir a representação JSON de um SLI que usa uma proporção de série temporal: 

{
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count"",
      "goodServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count" metric.label.response_code_class=200",
    }
  }
}

As séries temporais nesta proporção são identificadas pelo par de tipo de recurso monitorado e tipo de métrica:

  • Recurso: https_lb_rule
  • Tipo de métrica: loadbalancing.googleapis.com/https/request_count

O valor do totalServiceFilter é representado pelo par de métrica e tipo de recurso. O valor do goodServiceFilter é representado pelo mesmo par, mas onde algum rótulo possui um valor específico; neste caso, quando o valor do rótulo response_code_class for 200 .

A proporção entre os filtros mede o número de solicitações que retornam um status HTTP 2xx em relação ao número total de solicitações.

Veja a seguir a representação JSON de um SLI que usa um corte de distribuição: 

{
  "requestBased": {
    "distribution_cut": {
      "distribution_filter": "resource.type=https_lb_rule  metric.type="loadbalancing.googleapis.com/https/backend_latencies" metric.label.response_code_class=200",
      "range": {
        "min": "-Infinity",
        "max": 500.0
      }
    }
  }
}

A série temporal é identificada pelo tipo de recurso monitorado, tipo de métrica e valor de um rótulo de métrica:

  • Recurso: https_lb_rule
  • Tipo de métrica: loadbalancing.googleapis.com/https/backend_latencies
  • Par rótulo-valor: response_code_class = 200

A faixa de latências considerada boa é designada pelo campo range . Este SLI calcula a razão entre as latências das respostas da classe 2xx abaixo de 500 e as latências de todas as respostas da classe 200.

Estruturas para SLIs baseados em Windows

Um SLI baseado em janelas conta as janelas de tempo em que o serviço prestado é considerado bom. O critério para determinar a qualidade do serviço faz parte da definição do SLI.

Todos os SLIs baseados em janelas incluem um período de janela de 60 a 86.400 segundos (1 dia).

Há duas maneiras de especificar o critério de bom serviço para um SLI baseado em Windows:

  • Crie uma sequência de filtros, descrita em Monitorando filtros , que retorna uma série temporal com valores booleanos. Uma janela é boa se o valor dessa janela for true . Esse filtro é chamado goodBadMetricFilter .

  • Crie um objeto PerformanceThreshold que represente um limite para desempenho aceitável. Este objeto é especificado como o valor de goodTotalRatioThreshold .

    Um objeto PerformanceThreshold especifica um valor limite e um SLI de desempenho. Se o valor do SLI de desempenho atingir ou exceder o valor limite, a janela de tempo será considerada boa.

    Existem duas maneiras de especificar o SLI de desempenho:

    • Como um objeto BasicSli no campo basicPerformanceSli .
    • Como um objeto RequestBasedSli no campo performance . Se você usar um SLI baseado em solicitação, o tipo de métrica do seu SLI deverá ser DELTA ou CUMULATIVE . Você não pode usar métricas GAUGE em SLIs baseados em solicitação.

Veja a seguir a representação JSON de um SLI baseado em Windows criado com base em um limite de desempenho para um SLI de disponibilidade básica: 

{
  "windowsBased": {
     "goodTotalRatioThreshold": {
       "threshold": 0.9,
       "basicSliPerformance": {
         "availability": {},
         "location": [
           "us-central1-c"
         ]
       }
     },
     "windowPeriod": "300s"
   }
}

Este SLI especifica um bom desempenho como uma janela de 5 minutos em que a disponibilidade atinge 90% ou melhor. A estrutura de um SLI básico é mostrada em Indicadores de nível de serviço .

Você também pode incorporar um SLI baseado em solicitação no SLI baseado em Windows. Para obter mais informações sobre as estruturas incorporadas, consulte Estruturas para SLIs baseados em solicitação .

Objetivos de nível de serviço

Um objetivo de nível de serviço (SLO) é representado por um objeto ServiceLevelObjective . Este objeto inclui os seguintes campos:

  • Um nome
  • Um nome de exibição
  • O SLI alvo; um objeto ServiceLevelIndicator incorporado
  • A meta de desempenho para o SLI
  • O período de conformidade para o SLI

Veja a seguir a representação JSON de um SLO que usa um SLI de disponibilidade básica como o valor do campo serviceLevelIndicator : 

{
   "name": "projects/PROJECT_NUMBER/services/PROJECT_ID-zone-us-central1-c-csm-main-default-currencyservice/serviceLevelObjectives/3kavNVTtTMuzL7KcXAxqCQ",
   "serviceLevelIndicator": {
     "basicSli": {
       "availability": {},
       "location": [
         "us-central1-c"
       ]
     }
   },
   "goal": 0.98,
   "calendarPeriod": "WEEK",
   "displayName": "98% Availability in Calendar Week"
}

Este SLO define a meta de desempenho em 98% de disponibilidade durante um período de uma semana.

,

Este documento apresenta as estruturas usadas para representar serviços e SLOs na API do SLO e os mapeia para os conceitos descritos em geral em Conceitos de monitoramento de serviço .

A API SLO é usada para configurar objetivos de nível de serviço (SLOs) que podem ser usados ​​para monitorar a integridade dos seus serviços.

O Service Monitoring adiciona os seguintes recursos à API Monitoring:

Para obter informações sobre como invocar a API, consulte Trabalhando com a API .

Serviços

Um serviço é representado por um objeto Service . Este objeto inclui os seguintes campos:

  • Um nome: um nome de recurso totalmente qualificado para este serviço
  • Um nome de exibição: um rótulo para uso em componentes do console
  • Uma estrutura para um dos tipos BasicService .
  • Um objeto de configuração de telemetria fornecido pelo sistema

Para definir um serviço básico, especifique o tipo de serviço e forneça um conjunto de rótulos específicos do serviço que descrevem o serviço:

{
   "serviceType": string,
   "serviceLabels": {
      string: string,
      ...
   }
}

As seções a seguir fornecem exemplos para cada tipo de serviço.

Tipos de serviços básicos

Esta seção fornece exemplos de definições de serviços criadas no tipo BasicService , em que o valor do campo serviceType é um dos seguintes:

  • APP_ENGINE
  • CLOUD_ENDPOINTS
  • CLUSTER_ISTIO
  • ISTIO_CANONICAL_SERVICE
  • CLOUD_RUN

Cada um desses tipos de serviço utiliza o indicador de nível de serviço BasicSli .

Motor de aplicação 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "APP_ENGINE",
          "serviceLabels": {
            "module_id": "MODULE_ID"
          },
      },
    }

Terminais de nuvem 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLOUD_ENDPOINTS",
          "serviceLabels": {
            "service": "SERVICE"
          },
      },
    }

Cluster Istio 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLUSTER_ISTIO",
          "serviceLabels": {
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "service_namespace": "SERVICE_NAMESPACE",
            "service_name": "SERVICE_NAME"
          },
      },
    }

Serviço canônico do Istio 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "ISTIO_CANONICAL_SERVICE",
          "serviceLabels": {
            "mesh_uid": "MESH_UID",
            "canonical_service_namespace": "CANONICAL_SERVICE_NAMESPACE",
            "canonical_service": "CANONICAL_SERVICE"
          },
      },
    }

Execução na nuvem 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "CLOUD_RUN",
          "serviceLabels": {
            "service_name": "SERVICE_NAME",
            "location": "LOCATION"
          },
      },
    }

Tipos básicos de serviço do GKE

Esta seção contém exemplos de definições de serviço do GKE criadas com base no tipo BasicService , em que o valor do campo serviceType é um dos seguintes:

  • GKE_NAMESPACE
  • GKE_WORKLOAD
  • GKE_SERVICE

Você deve definir SLIs para esses tipos de serviço. Eles não podem usar indicadores de nível de serviço BasicSli . Para obter mais informações, consulte Indicadores de nível de serviço .

Namespace do GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_NAMESPACE",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME"
          }
      },
    }

Carga de trabalho do GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_WORKLOAD",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME",
            "top_level_controller_type": "TOPLEVEL_CONTROLLER_TYPE",
            "top_level_controller_name": "TOPLEVEL_CONTROLLER_NAME",
          }
      },
    }

Serviço do GKE 

    {
      "displayName": "DISPLAY_NAME",
      "basicService": {
          "serviceType": "GKE_SERVICE",
          "serviceLabels": {
            "project_id": "PROJECT_ID",
            "location": "LOCATION",
            "cluster_name": "CLUSTER_NAME",
            "namespace_name": "NAMESPACE_NAME",
            "service_name": "SERVICE_NAME"
          }
      },
    }

Serviços personalizados

Você poderá criar serviços customizados se nenhum dos tipos de serviços básicos for adequado. Um serviço personalizado se parece com o seguinte: 

    {
      "displayName": "DISPLAY_NAME",
      "custom": {}
    }

Você deve definir SLIs para esses tipos de serviço. Eles não podem usar indicadores de nível de serviço BasicSli . Para obter mais informações, consulte Indicadores de nível de serviço .

Indicadores de nível de serviço

Um indicador de nível de serviço (SLI) fornece uma medida do desempenho de um serviço. Um SLI é baseado na métrica capturada pelo serviço. A forma exacta como o SLI é definido depende do tipo de métrica utilizada como métrica de indicador, mas geralmente é uma comparação entre resultados aceitáveis ​​e resultados totais.

Um SLI é representado pelo objeto ServiceLevelIndicator . Este objeto é uma forma coletiva de referir os três tipos de SLIs suportados:

  • Um SLI básico, criado automaticamente para instâncias do tipo de serviço BasicService . Este tipo de SLI é descrito em Objetivos de nível de serviço ; ele é representado por um objeto BasicSli e mede a disponibilidade ou latência.

  • Um SLI baseado em solicitação, que pode ser usado para contar eventos que representam um serviço aceitável. O uso desse tipo de SLI é descrito em SLOs baseados em solicitação ; ele é representado por um objeto RequestBasedSli .

  • Um SLI baseado em janela, que você pode usar para contar períodos de tempo que atendem a algum critério de qualidade. O uso desse tipo de SLI é descrito em SLOs baseados em Windows ; ele é representado por um objeto WindowsBasedSli .

Por exemplo, o seguinte mostra um SLI de disponibilidade básica: 

{
  "basicSli": {
    "availability": {},
    "location": [
      "us-central1-c"
    ]
  }
}

Estruturas para SLIs baseados em solicitações

Um SLI baseado em solicitação é baseado em uma métrica que conta unidades de serviço como uma proporção entre um resultado específico e o total. Por exemplo, se você usar uma métrica que conte solicitações, poderá construir a proporção entre o número de solicitações que retornam sucesso e o número total de solicitações.

Existem duas maneiras de construir um SLI baseado em solicitação:

  • Como TimeSeriesRatio , quando a proporção entre serviço bom e serviço total é calculada a partir de duas séries temporais cujos valores possuem um tipo de métrica DELTA ou CUMULATIVE .
  • Como DistributionCut , quando a série temporal possui tipo de valor DISTRIBUTION e cujos valores possuem uma métrica do tipo DELTA ou CUMULATIVE . O valor do bom serviço é a contagem de itens que se enquadram nos intervalos do histograma em um intervalo especificado, e o total é a contagem de todos os valores na distribuição.

Veja a seguir a representação JSON de um SLI que usa uma proporção de série temporal: 

{
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count"",
      "goodServiceFilter": "resource.type=https_lb_rule metric.type="loadbalancing.googleapis.com/https/request_count" metric.label.response_code_class=200",
    }
  }
}

As séries temporais nesta proporção são identificadas pelo par de tipo de recurso monitorado e tipo de métrica:

  • Recurso: https_lb_rule
  • Tipo de métrica: loadbalancing.googleapis.com/https/request_count

O valor do totalServiceFilter é representado pelo par de métrica e tipo de recurso. O valor do goodServiceFilter é representado pelo mesmo par, mas onde algum rótulo possui um valor específico; neste caso, quando o valor do rótulo response_code_class for 200 .

A proporção entre os filtros mede o número de solicitações que retornam um status HTTP 2xx em relação ao número total de solicitações.

Veja a seguir a representação JSON de um SLI que usa um corte de distribuição: 

{
  "requestBased": {
    "distribution_cut": {
      "distribution_filter": "resource.type=https_lb_rule  metric.type="loadbalancing.googleapis.com/https/backend_latencies" metric.label.response_code_class=200",
      "range": {
        "min": "-Infinity",
        "max": 500.0
      }
    }
  }
}

A série temporal é identificada pelo tipo de recurso monitorado, tipo de métrica e valor de um rótulo de métrica:

  • Recurso: https_lb_rule
  • Tipo de métrica: loadbalancing.googleapis.com/https/backend_latencies
  • Par rótulo-valor: response_code_class = 200

A faixa de latências considerada boa é designada pelo campo range . Este SLI calcula a razão entre as latências das respostas da classe 2xx abaixo de 500 e as latências de todas as respostas da classe 200.

Estruturas para SLIs baseados em Windows

Um SLI baseado em janelas conta as janelas de tempo em que o serviço prestado é considerado bom. O critério para determinar a qualidade do serviço faz parte da definição do SLI.

Todos os SLIs baseados em janelas incluem um período de janela de 60 a 86.400 segundos (1 dia).

Há duas maneiras de especificar o critério de bom serviço para um SLI baseado em Windows:

  • Crie uma sequência de filtros, descrita em Monitorando filtros , que retorna uma série temporal com valores booleanos. Uma janela é boa se o valor dessa janela for true . Esse filtro é chamado goodBadMetricFilter .

  • Crie um objeto PerformanceThreshold que represente um limite para desempenho aceitável. Este objeto é especificado como o valor de goodTotalRatioThreshold .

    Um objeto PerformanceThreshold especifica um valor limite e um SLI de desempenho. Se o valor do SLI de desempenho atingir ou exceder o valor limite, a janela de tempo será considerada boa.

    Existem duas maneiras de especificar o SLI de desempenho:

    • Como um objeto BasicSli no campo basicPerformanceSli .
    • Como um objeto RequestBasedSli no campo performance . Se você usar um SLI baseado em solicitação, o tipo de métrica do seu SLI deverá ser DELTA ou CUMULATIVE . Você não pode usar métricas GAUGE em SLIs baseados em solicitação.

Veja a seguir a representação JSON de um SLI baseado em Windows criado com base em um limite de desempenho para um SLI de disponibilidade básica: 

{
  "windowsBased": {
     "goodTotalRatioThreshold": {
       "threshold": 0.9,
       "basicSliPerformance": {
         "availability": {},
         "location": [
           "us-central1-c"
         ]
       }
     },
     "windowPeriod": "300s"
   }
}

Este SLI especifica um bom desempenho como uma janela de 5 minutos em que a disponibilidade atinge 90% ou melhor. A estrutura de um SLI básico é mostrada em Indicadores de nível de serviço .

Você também pode incorporar um SLI baseado em solicitação no SLI baseado em Windows. Para obter mais informações sobre as estruturas incorporadas, consulte Estruturas para SLIs baseados em solicitação .

Objetivos de nível de serviço

Um objetivo de nível de serviço (SLO) é representado por um objeto ServiceLevelObjective . Este objeto inclui os seguintes campos:

  • Um nome
  • Um nome de exibição
  • O SLI alvo; um objeto ServiceLevelIndicator incorporado
  • A meta de desempenho para o SLI
  • O período de conformidade para o SLI

Veja a seguir a representação JSON de um SLO que usa um SLI de disponibilidade básica como o valor do campo serviceLevelIndicator : 

{
   "name": "projects/PROJECT_NUMBER/services/PROJECT_ID-zone-us-central1-c-csm-main-default-currencyservice/serviceLevelObjectives/3kavNVTtTMuzL7KcXAxqCQ",
   "serviceLevelIndicator": {
     "basicSli": {
       "availability": {},
       "location": [
         "us-central1-c"
       ]
     }
   },
   "goal": 0.98,
   "calendarPeriod": "WEEK",
   "displayName": "98% Availability in Calendar Week"
}

Este SLO define a meta de desempenho em 98% de disponibilidade durante um período de uma semana.