Construções na API

Este documento apresenta as estruturas usadas para representar serviços e SLOs na API SLO e mapeia-as para os conceitos descritos geralmente em Conceitos na monitorização de serviços.

A API SLO é usada para configurar objetivos ao nível do serviço (SLOs) que podem ser usados para monitorizar o estado dos seus serviços.

O Service Monitoring adiciona os seguintes recursos à API Monitoring:

Para obter informações sobre como invocar a API, consulte o artigo Trabalhar 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 a apresentar: uma etiqueta para utilização em componentes da consola
  • Uma estrutura para um dos tipos de BasicService.
  • Um objeto de configuração de telemetria fornecido pelo sistema

Para definir um serviço básico, especifica o tipo de serviço e fornece um conjunto de etiquetas específicas do serviço que descrevem o serviço:

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

As secções seguintes fornecem exemplos para cada tipo de serviço.

Tipos de serviços básicos

Esta secção fornece exemplos de definições de serviços criadas com base 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 destes tipos de serviços usa o indicador do nível de serviço BasicSli.

App Engine

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

Cloud Endpoints

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

Agrupe o 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"
          },
      },
    }

Cloud Run

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

Tipos de serviços básicos do GKE

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

  • GKE_NAMESPACE
  • GKE_WORKLOAD
  • GKE_SERVICE

Tem de definir os SLIs para estes tipos de serviços. Não podem usar BasicSli indicadores do nível de serviço. Para mais informações, consulte o artigo Indicadores ao nível do 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

Pode criar serviços personalizados se nenhum dos tipos de serviços básicos for adequado. Um serviço personalizado tem o seguinte aspeto:

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

Tem de definir os SLIs para estes tipos de serviços. Não podem usar BasicSli indicadores do nível de serviço. Para mais informações, consulte o artigo Indicadores ao nível do serviço.

Indicadores do nível de serviço

Um indicador do nível de serviço (INS) fornece uma medida do desempenho de um serviço. Um INS baseia-se numa métrica capturada pelo serviço. A forma exata como o SLI é definido depende do tipo de métrica usado como métrica do indicador, mas geralmente é uma comparação entre os resultados aceitáveis e os resultados totais.

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

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

  • Um SLI baseado em pedidos, que pode usar para contabilizar eventos que representam um serviço aceitável. A utilização deste tipo de SLI é descrita em SLOs baseados em pedidos; é representado por um objeto RequestBasedSli.

  • Um SLI baseado em janelas, que pode usar para contabilizar períodos que cumprem algum critério de qualidade. A utilização deste tipo de SLI é descrita em SLOs baseados no Windows; é representado por um objeto WindowsBasedSli.

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

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

Estruturas para INS baseados em pedidos

Um INS baseado em pedidos baseia-se numa métrica que contabiliza as unidades de serviço como uma relação entre um resultado específico e o total. Por exemplo, se usar uma métrica que contabiliza pedidos, pode criar a proporção entre o número de pedidos que devolvem êxito e o número total de pedidos.

Existem duas formas de criar um SLI baseado em pedidos:

  • Como TimeSeriesRatio, quando a proporção de bom serviço para o serviço total é calculada a partir de duas séries cronológicas cujos valores têm um tipo de métrica de DELTA ou CUMULATIVE.
  • Como DistributionCut, quando a série cronológica tem o tipo de valor DISTRIBUTION e cujos valores têm um tipo de métrica de DELTA ou CUMULATIVE. O valor de bom serviço é a contagem de itens que se enquadram nos intervalos do histograma num intervalo especificado, e o total é a contagem de todos os valores na distribuição.

O exemplo seguinte mostra a representação JSON de um SLI que usa uma proporção de séries cronológicas:

{
  "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",
    }
  }
}

Os intervalos temporais nesta proporção são identificados pelo par de tipo de recurso monitorizado e tipo de métrica:

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

O valor de totalServiceFilter é representado pelo par de métricas e tipo de recurso. O valor de goodServiceFilter é representado pelo mesmo par, mas em que alguma etiqueta tem um valor específico; neste caso, quando o valor da etiqueta response_code_class é 200.

A proporção entre os filtros mede o número de pedidos que devolvem um estado HTTP 2xx em relação ao número total de pedidos.

O exemplo seguinte mostra 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 cronológica é identificada pelo tipo de recurso monitorizado, o tipo de métrica e o valor de uma etiqueta de métrica:

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

O intervalo de latências considerado bom é designado pelo campo range. Este SLI calcula a proporção de latências de respostas da classe 2xx abaixo de 500 para as latências de todas as respostas da classe 200.

Estruturas para INS baseados no Windows

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

Todos os SLIs baseados no tempo incluem um período de tempo, de 60 a 86 400 segundos (1 dia).

Existem duas formas de especificar o critério de bom serviço para um SLI baseado no Windows:

  • Crie uma string de filtro, descrita em Filtros de monitorização, que devolve uma série cronológica com valores booleanos. Uma janela é boa se o valor dessa janela for true. Este filtro chama-se goodBadMetricFilter.
  • Crie um objeto PerformanceThreshold que represente um limite para um desempenho aceitável. Este objeto é especificado como o valor de goodTotalRatioThreshold.

    Um objeto PerformanceThreshold especifica um valor de limite e um SLI de desempenho. Se o valor do SLI de desempenho cumprir ou exceder o valor de limite, o período conta como bom.

    Existem duas formas de especificar o SLI de desempenho:

    • Como um objeto BasicSli no campo basicPerformanceSli.
    • Como um objeto RequestBasedSli no campo performance. Se usar um SLI baseado em pedidos, o tipo de métrica do SLI tem de ser DELTA ou CUMULATIVE. Não pode usar métricas GAUGE em SLIs baseados em pedidos.

O exemplo seguinte mostra a representação JSON de um SLI baseado no Windows criado com base num limite de desempenho para um SLI de disponibilidade básico:

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

Este SLI especifica um bom desempenho como um período de 5 minutos em que a disponibilidade atinge 90% ou mais. A estrutura de um INS básico é apresentada em Indicadores do nível de serviço.

Também pode incorporar um SLI baseado em pedidos no SLI baseado em janelas. Para mais informações sobre as estruturas incorporadas, consulte Estruturas para SLIs baseados em pedidos.

Objetivos ao nível do serviço

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

O exemplo seguinte mostra a representação JSON de um SLO que usa um INS de disponibilidade básico 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 o objetivo de desempenho numa disponibilidade de 98% durante um período de uma semana.