Usar métricas do Cloud Load Balancing

Esta página revê os tipos de balanceadores de carga disponíveis no Cloud Load Balancing e descreve como usar as métricas do Cloud Monitoring expostas por estes como SLIs.

Os serviços do Cloud Load Balancing oferecem frequentemente o primeiro ponto de entrada para aplicações alojadas no Google Cloud. Os balanceadores de carga são instrumentados automaticamente para fornecer informações sobre o tráfego, a disponibilidade e a latência dos serviços que expõem. Por conseguinte, os balanceadores de carga atuam frequentemente como uma excelente origem de métricas de SLI sem necessidade de instrumentação de aplicações. Google Cloud

Ao começar, pode optar por focar-se na disponibilidade e na latência como as dimensões principais da fiabilidade e criar SLIs e SLOs para medir e emitir alertas sobre essas dimensões. Esta página fornece exemplos de implementação.

Para mais informações, consulte o seguinte:

INSs e SLOs de disponibilidade

Para aplicações não UDP, um SLI de disponibilidade baseado em pedidos é o mais adequado, uma vez que as interações de serviço são mapeadas de forma clara para pedidos.

Exprime um SLI de disponibilidade baseado em pedidos através da estrutura TimeSeriesRatio para configurar uma proporção de pedidos válidos para o total de pedidos, conforme mostrado nos exemplos de disponibilidade seguintes. Para chegar à sua determinação preferida de "bom" ou "válido", filtre a métrica através das respetivas etiquetas disponíveis.

Balanceador de carga externo da camada 7 (HTTP/S)

Os balanceadores de carga HTTP/S são usados para expor aplicações acedidas através de HTTP/S e para distribuir tráfego para recursos localizados em várias regiões.

Os equilibradores de carga de aplicações externos escrevem dados de métricas na monitorização através do tipo de recurso monitorizado https_lb_rule e dos tipos de métricas com o prefixo loadbalancing.googleapis.com. O tipo de métrica mais relevante para os SLOs de disponibilidade é https/request_count, que pode filtrar através da etiqueta de métrica response_code_class.

Se optar por não contabilizar os pedidos que resultam num código de resposta de erro 4xx como "válidos" porque podem indicar erros do cliente, em vez de erros do serviço ou da aplicação, pode escrever o filtro para "total" da seguinte forma:

"totalServiceFilter":
  "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
   resource.type=\"https_lb_rule\"
   resource.label.\"url_map_name\"=\"my-app-lb\"
   metric.label.\"response_code_class\"!=\"400\"",

Também tem de determinar como contabilizar os pedidos "bons". Por exemplo, se optar por contabilizar apenas os que devolvem um código de resposta de estado de êxito 200 OK, pode escrever o filtro para "bom" da seguinte forma:

"goodServiceFilter":
  "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
   resource.type=\"https_lb_rule\"
   resource.label.\"url_map_name\"=\"my-app-lb\"
   metric.label.\"response_code_class\"=\"200\"",

Em seguida, pode expressar um SLI baseado em pedidos da seguinte forma:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
         resource.type=\"https_lb_rule\"
         resource.label.\"url_map_name\"=\"my-app-lb\"
         metric.label.\"response_code_class\"!=\"400\"",
      "goodServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/request_count\"
         resource.type=\"https_lb_rule\"
         resource.label.\"url_map_name\"=\"my-app-lb\"
         metric.label.\"response_code_class\"=\"200\"",
    }
  }
},

Para aplicações em que o tráfego é fornecido por vários backends, pode optar por definir SLIs para um backend específico. Para criar um SLI de disponibilidade para um backend específico, use a métrica https/backend_request_count com a etiqueta de recurso backend_target_name nos seus filtros, conforme mostrado neste exemplo:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
         resource.type=\"https_lb_rule\"
         resource.label.\"url_map_name\"=\"my-app-lb\"
         resource.label.\"backend_target_name\"=\"my-app-backend\"
         metric.label.\"response_code_class\"!=\"400\"",
      "goodServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/backend_request_count\"
         resource.type=\"https_lb_rule\" resource.label.\"url_map_name\"=\"my-app-lb\"
         resource.label.\"backend_target_name\"=\"my-app-backend\"
         metric.label.\"response_code_class\"=\"200\"",
    }
  }
}

Balanceador de carga interno da camada 7 (HTTP/S)

Os equilibradores de carga de aplicações internos escrevem dados de métricas na monitorização através do tipo de recurso monitorizado internal_http_lb_rule e dos tipos de métricas com o prefixo loadbalancing.googleapis.com. O tipo de métrica mais relevante para os SLOs de disponibilidade é https/internal_request_count, que pode filtrar através da etiqueta de métrica response_code_class.

Segue-se um exemplo de um SLI de disponibilidade baseado em pedidos:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
         resource.type=\"internal_http_lb_rule\"
         resource.label.\"url_map_name\"=\"my-internal-lb\"
         metric.label.\"response_code_class\"!=\"400\"",
      "goodServiceFilter":
         "metric.type=\"loadbalancing.googleapis.com/https/internal/request_count\"
          resource.type=\"internal_http_lb_rule\"
          resource.label.\"url_map_name\"=\"my-internal-lb\"
          metric.label.\"response_code_class\"=\"200\"",
    }
  }
},

Balanceadores de carga da camada 3 (TCP)

Os balanceadores de carga TCP não fornecem métricas de pedidos porque as aplicações que usam estes podem não se basear no modelo de pedido-resposta. Nenhuma das métricas loadbalancing.googleapis.com fornecidas por estes balanceadores de carga se presta a bons SLIs de disponibilidade.

Para criar SLIs de disponibilidade para estes equilibradores de carga, tem de criar métricas personalizadas ou baseadas em registos. Para mais informações, consulte os artigos Usar métricas personalizadas ou Usar métricas baseadas em registos.

INSs e SLOs de latência

Para aplicações de pedido-resposta, existem duas formas de escrever SLOs de latência:

  • Como SLOs baseados em pedidos.
  • Como SLOs baseados em janelas.

SLOs de latência baseados em pedidos

Um SLO baseado em pedidos aplica um limite de latência e contabiliza a fração de pedidos que são concluídos abaixo do limite dentro de um determinado período de conformidade. Um exemplo de um SLO baseado em pedidos é "99% dos pedidos são concluídos em menos de 100 ms num período contínuo de uma hora".

Exprime um SLI de latência baseado em pedidos através de uma estrutura DistributionCut, conforme mostrado nos exemplos de latência seguintes.

Um SLO baseado em pedidos único não consegue captar o desempenho típico e a degradação da experiência do utilizador, em que os pedidos "de cauda" ou mais lentos registam tempos de resposta cada vez mais longos. Um SLO para o desempenho típico não suporta a compreensão da latência final. Para uma discussão sobre a latência de cauda, consulte a secção "Worrying About Your Tail" no Capítulo 6: Monitorização de sistemas distribuídos de Site Reliability Engineering.

Para mitigar esta limitação, pode escrever um segundo SLO para se focar especificamente na latência de cauda, por exemplo, "99,9% dos pedidos são concluídos em menos de 1000 ms durante um período de 1 hora contínuo". A combinação dos dois SLOs captura degradações na experiência do utilizador típica e na latência de cauda.

SLOs de latência baseados em janelas

Um SLO baseado em janelas define um critério de qualidade para o período de tempo das medições e calcula a proporção de intervalos "bons" em relação ao número total de intervalos. Um exemplo de um SLO baseado em janelas é "A métrica de latência do percentil 95 é inferior a 100 ms durante, pelo menos, 99% das janelas de um minuto, ao longo de uma janela contínua de 28 dias":

  • Um período de medição "bom" é um intervalo de um minuto em que 95% dos pedidos têm uma latência inferior a 100 ms.
  • A medida de conformidade é a fração desses períodos "bons". O serviço está em conformidade se esta fração for, pelo menos, 0,99, calculada durante o período de conformidade.

Tem de usar um SLO baseado em janelas se a métrica não processada disponível for um percentil de latência, ou seja, quando ambas as seguintes condições forem verdadeiras:

  • Os dados são agrupados em períodos (por exemplo, em intervalos de 1 minuto).
  • Os dados são expressos em grupos de percentis (por exemplo, p50, p90, p95 e p99).

Para este tipo de dados, cada grupo de percentis indica o tempo que divide os grupos de dados acima e abaixo desse percentil. Por exemplo, um intervalo de um minuto com uma métrica de latência p95 de 89 ms indica que, durante esse minuto, o serviço respondeu a 95% dos pedidos em 89 ms ou menos.

Balanceador de carga de aplicações externo

Os balanceadores de carga de aplicações externos usam os seguintes tipos de métricas principais para captar a latência:

  • https/total_latencies: uma distribuição da latência calculada a partir do momento em que o proxy recebeu o pedido até o proxy receber o ACK do cliente no último byte de resposta. Use quando a experiência geral do utilizador for de importância primordial.

  • https/backend_latencies: uma distribuição da latência calculada a partir do momento em que o pedido foi enviado pelo proxy para o back-end até o proxy receber do back-end o último byte da resposta. Use para medir as latências de back-ends específicos que publicam tráfego atrás do balanceador de carga.

Estas métricas são escritas em função do tipo de recurso monitorizado https_lb_rule.

Latência total

Este SLO espera que 99% dos pedidos se situem entre 0 e 100 ms na latência total durante um período contínuo de uma hora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
             "metric.type=\"loadbalancing.googleapis.com/https/total_latencies\"
              resource.type=\"https_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Latência de back-end

Este SLO de exemplo espera que 98% dos pedidos para o destino de back-end "my-app-backend" tenham uma latência entre 0 e 100 ms durante um período de uma hora contínuo:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/https/backend_latencies\"
           resource.type=\"https_lb_rule\"
           resource.label.\"backend_target_name\"=\"my-app-backend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Balanceador de carga de aplicações interno

Os balanceadores de carga de aplicações internos usam dois tipos de métricas principais para captar a latência:

  • https/internal/total_latencies: uma distribuição da latência calculada a partir do momento em que o pedido foi recebido pelo proxy até o proxy receber ACK do cliente no último byte de resposta. Use quando a experiência geral do utilizador for de importância primordial.

  • https/internal/backend_latencies: uma distribuição da latência calculada a partir do momento em que o pedido foi enviado pelo proxy para o back-end até o proxy receber do back-end o último byte da resposta. Use para medir as latências de back-ends específicos que publicam tráfego atrás do balanceador de carga.

Estas métricas são escritas em relação ao tipo de recurso monitorizado internal_http_lb_rule.

Latência total

Este SLO de exemplo espera que 99% dos pedidos se situem entre 0 e 100 ms na latência total durante um período de uma hora contínuo:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/https/internal/total_latencies\"
           resource.type=\"internal_http_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Este SLO de exemplo espera que 99% dos pedidos se situem entre 0 e 100 ms na latência total durante um período contínuo de uma hora.

Latência de back-end

Este SLO espera que 98% dos pedidos para o destino de back-end "my-internal-backend" tenham uma latência entre 0 e 100 ms durante um período de uma hora contínuo:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/https/internal/backend_latencies\"
           resource.type=\"https_lb_rule\"
           resource.label.\"backend_target_name\"=\"my-internal-backend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Balanceador de carga externo da camada 3 (TCP)

Os balanceadores de carga TCP externos usam um único tipo de métrica, l3/external/rtt_latencies, que regista a distribuição do tempo de resposta medido em ligações TCP para fluxos de balanceadores de carga externos.

Esta métrica é escrita no recurso tcp_lb_rule.

Este SLO de exemplo espera que 99% dos pedidos se situem entre 0 e 100 ms na latência total durante um período de uma hora contínuo:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/l3/external/rtt_latencies\"
           resource.type=\"tcp_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Balanceador de carga interno da camada 3 (TCP)

Os balanceadores de carga TCP internos usam um único tipo de métrica, l3/internal/rtt_latencies, que regista a distribuição do tempo de resposta medido em ligações TCP para fluxos do balanceador de carga interno.

Esta métrica é escrita no recurso internal_tcp_lb_rule.

Este SLO de exemplo espera que 99% dos pedidos se situem entre 0 e 100 ms na latência total durante um período de uma hora contínuo:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"loadbalancing.googleapis.com/l3/internal/rtt_latencies\"
           resource.type=\"internal_tcp_lb_rule\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}