Serviços de pedido-resposta

Um serviço de pedido-resposta é aquele em que um cliente pede explicitamente ao serviço para fazer algum trabalho e aguarda que esse trabalho seja concluído com êxito. Os exemplos mais comuns destes serviços são:

  • Aplicações Web com as quais os utilizadores humanos interagem diretamente através de um navegador.
  • Aplicações para dispositivos móveis que consistem numa aplicação cliente no telemóvel de um utilizador e num back-end de API com o qual o cliente interage.
  • Back-ends de API usados por outros serviços (em vez de utilizadores humanos).

Para todos estes serviços, a abordagem comum é começar com os SLIs de disponibilidade (medindo a relação de pedidos bem-sucedidos) e latência (medindo a relação de pedidos que são concluídos abaixo de um limite de tempo). Para mais informações sobre os SLIs de disponibilidade e latência, consulte o artigo Conceitos na monitorização de serviços.

Exprime um SLI de disponibilidade baseado em pedidos através da estrutura TimeSeriesRatio para configurar uma proporção de pedidos válidos em relação ao total de pedidos. Decide como filtrar a métrica usando as respetivas etiquetas disponíveis para chegar à sua determinação preferencial de "boa" ou "válida".

Exprime um SLI de latência baseado em pedidos através de uma estrutura DistributionCut.

Cloud Endpoints

O Cloud Endpoints é um serviço para gerir APIs. Permite-lhe usar uma API existente e expô-la com autenticação, quotas e monitorização.

O Endpoints é implementado como um proxy à frente do servidor de aplicações gRPC. Ao medir as métricas no proxy, pode processar corretamente o caso em que todos os back-ends estão indisponíveis e os utilizadores estão a ver erros. Os pontos finais escrevem dados nos tipos de métricas que começam com o prefixo serviceruntime.googleapis.com.

Para mais informações, consulte o seguinte:

INSs de disponibilidade

O Cloud Endpoints escreve dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado api e do tipo de métrica service-runtime api/request_count, que pode filtrar através da etiqueta de métrica response_code para contabilizar os pedidos "bons" e "totais".

Exprime um SLI de disponibilidade baseado em pedidos criando uma estrutura TimeSeriesRatio para bons pedidos em relação ao total de pedidos, conforme mostrado no exemplo seguinte:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"serviceruntime.googleapis.com/api/request_count\"
         resource.type=\"api\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
    }
  }
}

INSs de latência

O Cloud Endpoints usa os seguintes tipos de métricas principais para capturar a latência:

  • api/request_latencies: uma distribuição de latências em segundos para pedidos sem streaming. Use quando a experiência do utilizador geral for de importância primordial.
  • api/request_latencies_backend: uma distribuição das latências de back-end em segundos para pedidos não de streaming. Use-o para medir diretamente as latências de back-end.
  • api/request_latencies_overhead: uma distribuição das latências dos pedidos em segundos para pedidos não de streaming, excluindo o back-end. Use para medir a sobrecarga introduzida pelo proxy de Endpoints.

Tenha em atenção que a latência total do pedido é a soma das latências de back-end e gerais:

request_latencies = request_latencies_backend + request_latencies_overhead

Os pontos finais escrevem dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado api e de um dos tipos de métricas de latência de pedidos. Nenhum destes tipos de métricas fornece uma etiqueta response_code ouresponse_code_class ; por conseguinte, comunicam latências para todos os pedidos.

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

O SLO de exemplo seguinte espera que 99% de todos os pedidos no projeto se enquadrem entre 0 e 100 ms na latência total durante um período contínuo de uma hora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/ap/request_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

O SLO de exemplo seguinte espera que 98% dos pedidos se situem entre 0 e 100 ms na latência do back-end durante um período contínuo de uma hora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"serviceruntime.googleapis.com/api/backend_latencies\"
           resource.type=\"api\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.98,
  "rollingPeriod": "3600s",
  "displayName": "98% requests under 100 ms"
}

Cloud Run

O Cloud Run é uma plataforma de computação totalmente gerida para implementar e dimensionar aplicações contentorizadas de forma rápida e segura. Destina-se a abstrair toda a gestão de infraestrutura respondendo às alterações no tráfego através do aumento e diminuição automáticos a partir de zero quase instantaneamente e cobrando-lhe apenas os recursos exatos que usa.

Para mais informações sobre a observabilidade do Cloud Run, consulte o seguinte:

INSs de disponibilidade

O Cloud Run escreve dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado cloud_run_revision e do tipo de métrica request_count. Pode filtrar os dados usando a etiqueta da métrica response_codeou response_code_class para contabilizar os pedidos "bons" e "totais".

Exprime um SLI de disponibilidade baseado em pedidos criando uma estrutura TimeSeriesRatio para bons pedidos em relação ao total de pedidos, conforme mostrado no exemplo seguinte:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         metric.label.\"response_code_class\"!=\"4xx\"",
      "goodServiceFilter":
        "metric.type=\"run.googleapis.com/request_count\"
         resource.type=\"cloud_run_revision\"
         (metric.label.\"response_code_class\"=\"1xx\"" OR
          metric.label.\"response_code_class\"=\"2xx\""),
     }
  }
}

INSs de latência

Para medir a latência, o Cloud Run escreve dados de métricas no Cloud Monitoring usando o tipo de recurso monitorizado cloud_run_revision e o tipo de métrica request_latencies. Os dados são uma distribuição da latência de pedidos em milissegundos que atinge a revisão. Pode filtrar os dados usando a etiqueta da métrica response_codeou response_code_class se precisar de medir explicitamente a latência de todos os pedidos ou apenas dos pedidos bem-sucedidos.

Exprime um SLI de latência baseado em pedidos através de uma estrutura DistributionCut. O exemplo de SLO seguinte 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=\"run.googleapis.com/request_latencies\"
           resource.type=\"cloud_run_revision"",
        "range": {
           "min": 0,
           "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

Funções do Cloud Run

As funções do Cloud Run são uma oferta de funções como serviço (FaaS) de pagamento conforme a utilização escalável que executa o seu código sem ter de gerir qualquer infraestrutura. As funções são usadas em muitos padrões de arquitetura para realizar ações como o processamento de eventos, a automatização e a publicação de pedidos HTTP/S.

Para obter informações sobre a observabilidade das funções do Cloud Run, consulte o seguinte:

INSs de disponibilidade

As funções do Cloud Run escrevem dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado cloud_function e do tipo de métrica function/execution_time. Pode filtrar os dados através da etiqueta da métrica status para contabilizar as execuções "boas" e "totais".

Exprime um SLI de disponibilidade baseado em pedidos criando uma estrutura TimeSeriesRatio para bons pedidos em relação ao total de pedidos, conforme mostrado no exemplo seguinte:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\"",
      "goodServiceFilter":
        "metric.type=\"cloudfunctions.googleapis.com/function/execution_count\"
         resource.type=\"cloud_function\
         metric.label.\"status\"=\"ok\"",
     }
  }
}

INSs de latência

Para medir a latência, as funções do Cloud Run escrevem dados de métricas no Cloud Monitoring usando o tipo de recurso monitorizado cloud_function e o tipo de métrica function/execution_times. Os dados são uma distribuição dos tempos de execução das funções em nanosegundos." Pode filtrar os dados através do ícone status se precisar de medir explicitamente a latência de todas as execuções ou apenas das execuções bem-sucedidas.

Exprime um SLI de latência baseado em pedidos através de uma estrutura DistributionCut. O exemplo de SLO seguinte espera que 99% de todas as execuções de funções do Cloud Run se enquadrem entre 0 e 100 ms na latência total durante um período contínuo de uma hora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"cloudfunctions.googleapis.com/function/execution_times\"
           resource.type=\"cloud_function\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

App Engine

O App Engine oferece uma plataforma sem servidor totalmente gerida para criar e executar aplicações. Tem a opção de escolher entre dois ambientes: padrão ou flexível. Para mais informações, consulte o artigo Escolher um ambiente do App Engine.

Para mais informações sobre o App Engine, consulte o seguinte:

INSs de disponibilidade

O App Engine escreve dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado gae_app e do tipo de métrica http/server/response_count. Pode filtrar os dados através da etiqueta da métrica response_code para contabilizar as respostas "boas" e "totais".

Pode expressar um SLI de disponibilidade baseado em pedidos para o App Engine criando uma estrutura TimeSeriesRatio para bons pedidos em relação ao total de pedidos, conforme mostrado no seguinte exemplo:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\">\"499\"
         metric.label.\"response_code\"<\"399\"",
      "goodServiceFilter":
        "metric.type=\"appengine.googleapis.com/http/server/response_count\"
         resource.type=\"gae_app\"
         metric.label.\"response_code\"<\"299\"",
     }
  }
}

INSs de latência

Para medir a latência, o App Engine escreve dados de métricas no Cloud Monitoring através do tipo de recurso monitorizado gae_app e do tipo de métrica http/server/response_latencies. Pode filtrar os dados através da etiqueta da métrica response_code para contabilizar as execuções "boas" e "totais".

Exprime um SLI de latência baseado em pedidos para o App Engine usando uma estrutura DistributionCut. O SLO de exemplo seguinte espera que 99% de todos os pedidos se enquadrem entre 0 e 100 ms na latência total durante um período contínuo de uma hora:

{
  "serviceLevelIndicator": {
    "requestBased": {
      "distributionCut": {
        "distributionFilter":
          "metric.type=\"appengine.googleapis.com/http/server/response_latencies\"
           resource.type=\"gae_app\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}

GKE e Istio

O Google Kubernetes Engine (GKE) é o serviço Kubernetes gerido e seguro da Google com escala automática de quatro vias e suporte multi-cluster. O Istio é uma malha de serviços de código aberto que lhe permite ligar, proteger, controlar e observar serviços. O Istio pode ser instalado no GKE como um suplemento, o Cloud Service Mesh, ou pelo utilizador a partir do projeto de código aberto. Em ambos os casos, o Istio oferece uma telemetria excelente, incluindo informações sobre o tráfego, os erros e a latência para cada serviço gerido pela malha.

Para ver uma lista completa de métricas do Istio, consulte os istio.iotipos de métricas.

INSs de disponibilidade

O Istio escreve dados de métricas no Cloud Monitoring através do tipo de métrica service/server/request_count e de um dos seguintes tipos de recursos monitorizados:

Pode filtrar os dados através da etiqueta da métrica response_code para contabilizar os pedidos "bons" e "totais". Também pode usar a etiqueta de métrica destination_service_name para contabilizar pedidos de um serviço específico.

Expressa um SLI de disponibilidade baseado em pedidos para um serviço executado no GKE gerido pela malha de serviços do Istio criando uma estrutura TimeSeriesRatio para bons pedidos em relação ao total de pedidos, conforme mostrado no exemplo seguinte:

"serviceLevelIndicator": {
  "requestBased": {
    "goodTotalRatio": {
      "totalServiceFilter":
        "metric.type=\"istio.io/service/server/request_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"",
      "goodServiceFilter":
        "metric.type=\istio.io/server/response_count\"
         resource.type=\"k8s_container\"
         metric.label.\"destination_service_name\"=\"frontend\"
         metric.label.\"response_code\"<\"299\"",
    }
  }
}

INSs de latência

Para medir a latência, o Istio escreve dados de métricas no Cloud Monitoring através do tipo de métrica service/server/response_latencies e de um dos seguintes tipos de recursos monitorizados:

Pode filtrar os dados usando a etiqueta da métrica response_codedestination_service_name"good" and "total" requests. You can also use the para contabilizar pedidos de um serviço específico.

Expressa um SLI de latência baseado em pedidos para um serviço executado no GKE gerido pela malha de serviços do Istio através de uma estrutura DistributionCut. O SLO de exemplo seguinte espera que 99% de todos os pedidos ao serviço frontend 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=\"istio.io/server/response_latencies\"
           resource.type=\"k8s_container\"
           metric.label.\"destination_service_name\"=\"frontend\"",
        "range": {
          "min": 0,
          "max": 100
        }
      }
    }
  },
  "goal": 0.99,
  "rollingPeriod": "3600s",
  "displayName": "99% requests under 100 ms"
}