Esta página analisa os tipos de balanceadores de carga disponíveis no Cloud Load Balancing e descreve como usar as métricas do Cloud Monitoring expostas por eles como SLIs.
Os serviços do Cloud Load Balancing geralmente fornecem o primeiro ponto de entrada para aplicativos hospedados no Google Cloud. Os balanceadores de carga são instrumentados automaticamente para fornecer informações sobre tráfego, disponibilidade e latência dos serviços do Google Cloud que eles expõem. Portanto, os balanceadores de carga geralmente atuam como uma fonte excelente de métricas de SLI sem a necessidade de instrumentação do aplicativo.
Ao começar, você pode optar por se concentrar na disponibilidade e na latência como as dimensões principais de confiabilidade e criar SLIs e SLOs para medir e alertar sobre essas dimensões. Nesta página, fornecemos exemplos de implementação.
Para mais informações, consulte os seguintes tópicos:
- Conceitos no monitoramento de serviços
- Documentação do Cloud Load Balancing
- Lista de tipos de métrica
loadbalancing.googleapis.com
SLOs e SLIs de disponibilidade
Para aplicativos não UDP, o SLI de disponibilidade baseado em solicitação é o mais apropriado, porque as interações de serviço mapeiam corretamente para as solicitações.
Para expressar um SLI de disponibilidade baseado em solicitação, use a estrutura TimeSeriesRatio para configurar uma proporção de solicitações boas para o total de solicitações, conforme mostrado nos seguintes exemplos de disponibilidade.
Para chegar à determinação preferida de "boa" ou "válida", filtre a métrica usando os rótulos disponíveis.
Balanceador de carga externo da camada 7 (HTTP/S)
Os balanceadores de carga HTTP/S são usados para expor aplicativos que são acessados por HTTP/S e distribuir tráfego para recursos localizados em várias regiões.
Os balanceadores de carga de aplicativo externos gravam dados de métrica no Monitoring usando o tipo de recurso monitorado https_lb_rule e os tipos de métrica com o prefixo loadbalancing.googleapis.com. O tipo de métrica mais relevante para os SLOs de disponibilidade é https/request_count, que pode ser filtrado usando o rótulo de métrica response_code_class.
Se você optar por não contabilizar essas solicitações que resultam em um código de resposta de erro 4xx como "válidas" porque elas podem indicar erros de cliente, em vez de erros de serviço ou aplicativo, escreva o filtro como "total", desta 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\"",
Você também precisa determinar como contar solicitações "boas". Por exemplo, se você optar por contar apenas as que retornem um código de resposta de status de sucesso 200 OK, poderá escrever o filtro como "boas", desta 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\"",
Expresse um SLI baseado em solicitação desta 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 aplicativos em que o tráfego é veiculado por vários back-ends, é possível definir SLIs para um back-end específico. Para criar um SLI de disponibilidade para um back-end específico, use a métrica https/backend_request_count com o rótulo de recurso backend_target_name nos seus filtros, como 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 balanceadores de carga de aplicativo internos gravam dados de métrica no Monitoring usando o tipo de recurso monitorado internal_http_lb_rule e os tipos de métrica com o prefixo loadbalancing.googleapis.com. O tipo de métrica mais relevante para os SLOs de disponibilidade é https/internal_request_count, que pode ser filtrado usando o rótulo de métrica response_code_class.
Veja a seguir um exemplo de SLI de disponibilidade baseado em solicitação:
"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 de camada 3 (TCP)
Os balanceadores de carga TCP não fornecem métricas de solicitação porque os aplicativos que os usam podem não ser baseados no modelo de solicitação-resposta. Nenhuma das métricas loadbalancing.googleapis.com fornecidas por esses balanceadores de carga serve para SLIs de disponibilidade de solicitações boas.
Para criar SLIs de disponibilidade para esses balanceadores de carga, é preciso criar métricas personalizadas ou com base em registros. Para mais informações, consulte Como usar métricas personalizadas ou Como usar métricas com base em registros.
SLOs e SLIs de latência
Para aplicativos de solicitação/resposta, há duas maneiras de escrever SLOs de latência:
- Como SLOs baseados em solicitações.
- Como SLOs baseados em janelas.
SLOs de latência baseados em solicitações
Um SLO baseado em solicitação aplica um limite de latência e conta a fração de solicitações concluídas abaixo do limite em uma determinada janela de conformidade. Um exemplo de SLO baseado em solicitação é "99% das solicitações concluídas em menos de 100 ms em um período contínuo de uma hora".
Para expressar um SLI de latência baseado em solicitação, use uma estrutura DistributionCut, como mostrado nos exemplos de latência a seguir.
Um único SLO baseado em solicitação não captura o desempenho típico e a degradação da experiência do usuário, em que as solicitações "de cauda" ou mais lentas veem tempos de resposta cada vez maiores. Um SLO de desempenho típico não é compatível com o entendimento da latência de cauda. Para mais informações sobre a latência de cauda, consulte a seção "Como se preocupar com a latência de cauda" (Worrying about your Tail) no Capítulo 6: "Como monitorar sistemas distribuídos" (Monitoring Distributed Systems) do manual Engenharia de confiabilidade do site (em inglês).
Para atenuar essa limitação, escreva um segundo SLO para se concentrar especificamente na latência de cauda, por exemplo, "99,9% das solicitações concluídas em menos de 1.000 ms em uma janela contínua de uma hora". A combinação dos dois SLOs captura as degradações na experiência típica do usuário e na latência de cauda.
SLOs de latência baseados em janela
Um SLO baseado em janela define um critério de qualidade para o período de medições e calcula a proporção de intervalos "bons" para o número total de intervalos. Um exemplo de SLO baseado em janela é "A métrica de latência do 95º percentil é menor que 100 ms para pelo menos 99% das janelas de um minuto, em uma janela de 28 dias":
- Um período de medição "bom" é de um minuto em que 95% das solicitações têm latência abaixo de 100 ms.
- A medida de conformidade é a fração de tais períodos. O serviço estará em conformidade se essa fração for de, pelo menos, 0,99 e calculada durante o período de conformidade.
É preciso usar um SLO baseado em janela se a métrica bruta disponível para você for um percentil de latência, ou seja, quando estas duas opções forem verdadeiras:
- Os dados são agrupados em períodos (por exemplo, em intervalos de um minuto).
- Os dados são expressos em grupos de percentil (por exemplo, p50, p90, p95, p99).
Para esse tipo de dados, cada grupo de percentil indica o tempo, dividindo 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, para esse minuto, o serviço respondeu a 95% das solicitações em 89 ms ou menos.
Balanceador de carga de aplicativo externo
Os balanceadores de carga de aplicativo externo usam os seguintes tipos de métricas principais para capturar a latência:
https/total_latencies: uma distribuição da latência calculada a partir do momento em que a solicitação foi recebida pelo proxy até o proxy receber a confirmação do cliente do último byte de resposta. Use quando a experiência geral do usuário for de grande importância.https/backend_latencies: uma distribuição da latência calculada do momento em que a solicitação foi enviada 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 veiculam tráfego por trás do balanceador de carga.
Essas métricas são escritas no tipo de recurso monitorado https_lb_rule.
Latência total
Este exemplo de SLO espera que 99% das solicitações fiquem entre 0 e 100 ms na latência total ao longo de 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% das solicitações para o destino de back-end "my-app-backend" estejam entre 0 e 100 ms em latência em um período contínuo de uma hora:
{
"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 aplicativo interno
Os balanceadores de carga de aplicativo internos usam dois tipos de métricas principais para capturar a latência:
https/internal/total_latencies: uma distribuição da latência calculada a partir do momento em que a solicitação foi recebida pelo proxy até o proxy ter recebido a confirmação do cliente no último byte de resposta. Use quando a experiência geral do usuário for de grande importância.https/internal/backend_latencies: uma distribuição da latência calculada do momento em que a solicitação foi enviada 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 veiculam tráfego por trás do balanceador de carga.
Essas métricas são escritas no tipo de recurso monitorado internal_http_lb_rule.
Latência total
Este exemplo de SLO espera que 99% das solicitações fiquem entre 0 e 100 ms na latência total ao longo de um período contínuo de uma hora:
{
"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 exemplo de SLO espera que 99% das solicitações fiquem entre 0 e 100 ms na latência total ao longo de um período contínuo de uma hora:
Latência de back-end
Este SLO de exemplo espera que 98% das solicitações para o destino de back-end "my-internal-backend" estejam entre 0 e 100 ms em latência em um período contínuo de uma hora:
{
"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 de camada 3 (TCP)
Os balanceadores de carga TCP externos usam um único tipo de métrica, l3/external/rtt_latencies, que registra a distribuição do tempo de retorno medido em conexões TCP para fluxos do balanceador de carga externo.
Esta métrica é gravada no recurso tcp_lb_rule.
Este exemplo de SLO espera que 99% das solicitações fiquem entre 0 e 100 ms na latência total ao longo de um período contínuo de uma hora:
{
"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 registra a distribuição do tempo de retorno medido em conexões TCP para fluxos do balanceador de carga interno.
Esta métrica é gravada no recurso internal_tcp_lb_rule.
Este exemplo de SLO espera que 99% das solicitações fiquem entre 0 e 100 ms na latência total ao longo de um período contínuo de uma hora:
{
"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"
}