Um serviço de solicitação/resposta é aquele em que um cliente solicita explicitamente que o serviço faça algum trabalho e aguarda que ele seja concluído. Os exemplos mais comuns desses serviços são:
- Aplicativos da Web com os quais usuários humanos interagem diretamente usando um navegador.
- Aplicativos para dispositivos móveis que consistem em um aplicativo cliente no smartphone de um usuário e um back-end de API com que o cliente interage.
- Back-ends de API usados por outros serviços (em vez de usuários humanos).
Para todos esses serviços, a abordagem comum é começar com os SLIs de disponibilidade, que medem a proporção de solicitações bem-sucedidas, e de latência, que avaliam a proporção de solicitações concluídas em um limite de tempo. Para mais informações sobre os SLIs de disponibilidade e latência, consulte Conceitos no monitoramento de serviço.
Expresse um SLI de disponibilidade baseado em solicitação usando a estrutura TimeSeriesRatio para configurar uma proporção de solicitações "boas" para o total de solicitações. Você decide como filtrar a métrica usando os rótulos disponíveis para chegar à determinação preferida de "boa" ou "válida".
Para expressar um SLI de latência baseado em solicitações, use uma estrutura DistributionCut.
Cloud Endpoints
O Cloud Endpoints é um serviço para gerenciar APIs. Com ele, você usa uma API existente e a expõe com autenticação, cotas e monitoramento.
O Endpoints é implementado como um proxy na frente do servidor de aplicativos do gRPC. Ao medir as métricas no proxy, é possível gerenciar corretamente o caso quando todos os back-ends estiverem indisponíveis e os usuários estiverem vendo erros.
O Endpoints grava dados em tipos de métricas que começam com o prefixo serviceruntime.googleapis.com.
Para ver mais informações, consulte os seguintes tópicos:
- Documentação do Cloud Endpoints.
- Lista de tipos de métrica
serviceruntime.googleapis.com.
SLIs de disponibilidade
O Cloud Endpoints grava dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado api e o tipo de métrica
api/request_count do ambiente de execução do serviço, que pode ser filtrada usando o rótulo de métrica response_code para contar solicitações "boas" e "totais".
Para expressar um SLI de disponibilidade com base em solicitações, crie uma estrutura TimeSeriesRatio para solicitações "boas" para o total de solicitações, como mostrado no exemplo a seguir:
"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\""),
}
}
}
SLIs de latência
O Cloud Endpoints usa os seguintes tipos de métricas principais para capturar latência:
-
api/request_latencies: uma distribuição de latências em segundos para solicitações sem streaming. Use quando a experiência geral do usuário for de grande importância. -
api/request_latencies_backend: uma distribuição de latências de back-end em segundos para solicitações sem streaming. Use para medir as latências de back-end diretamente. -
api/request_latencies_overhead: uma distribuição de latências de solicitação em segundos para solicitações sem streaming, excluindo o back-end. Use para medir a sobrecarga introduzida pelo proxy do Endpoints.
Observe que a latência total da solicitação é a soma das latências de back-end e sobrecarga:
request_latencies = request_latencies_backend + request_latencies_overhead
O Endpoints grava dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado api e um dos tipos de métricas de latência de solicitação.
Nenhum desses tipos de métrica fornece um rótulo response_code ou response_code_class. Portanto, eles informam as latências de todas as solicitações.
Para expressar um SLI de latência baseado em solicitação, use uma estrutura DistributionCut, como mostrado nos exemplos a seguir.
O SLO de exemplo a seguir espera que 99% de todas as solicitações no projeto estejam entre 0 e 100 ms em latência total em 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 a seguir espera que 98% das solicitações estejam 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 gerenciada para implantar e escalonar aplicativos conteinerizados de maneira rápida e segura. Ele cuida do gerenciamento de toda a infraestrutura respondendo às mudanças no tráfego aumentando ou diminuindo o uso de recursos quase instantaneamente conforme o tráfego, e cobramos apenas pelos recursos exatos que você usa.
Para mais informações sobre a observabilidade do Cloud Run, consulte:
- Documentação do Cloud Run.
- Lista de tipos de métrica
run.googleapis.com.
SLIs de disponibilidade
O Cloud Run grava dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado cloud_run_revision e o tipo de métrica request_count. Filtre os dados usando o rótulo de métrica response_code ou response_code_class para contar solicitações "boas" e "totais".
Para expressar um SLI de disponibilidade com base em solicitações, crie uma estrutura TimeSeriesRatio para solicitações "boas" para o total de solicitações, como mostrado no exemplo a seguir:
"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\""),
}
}
}
SLIs de latência
Para medir a latência, o Cloud Run grava dados de métrica no Cloud Monitoring usando o tipo de recurso monitorado cloud_run_revision e o tipo de métrica
request_latencies. Os dados são uma distribuição da latência da solicitação em milissegundos alcançando a revisão. Filtre os dados usando o rótulo de métrica response_code ou response_code_class se precisar medir explicitamente a latência de todas as solicitações ou apenas as solicitações bem-sucedidas.
Para expressar um SLI de latência baseado em solicitações, use uma estrutura DistributionCut. O SLO de exemplo a seguir espera que 99% das solicitações estejam entre 0 e 100 ms na latência total durante um período contínuo de uma hora:
{
"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 ofertas escalonáveis de funções como serviço com pagamento por utilização que executa seu código sem a necessidade de gerenciar uma infraestrutura. As funções são usadas em muitos padrões de arquitetura para realizar ações como processamento de eventos, automação e exibição de solicitações HTTP/S.
Para informações sobre a observabilidade das funções do Cloud Run, consulte:
- Documentação para Funções do Cloud Run.
- Lista de tipos de métrica
run.googleapis.com.
SLIs de disponibilidade
As funções do Cloud Run gravam dados de métricas no Cloud Monitoring usando o tipo de recurso monitorado cloud_function e o tipo de métrica function/execution_time.
Filtre os dados usando o rótulo de métrica status para contar as execuções "boas" e "totais".
Para expressar um SLI de disponibilidade com base em solicitações, crie uma estrutura TimeSeriesRatio para solicitações "boas" para o total de solicitações, como mostrado no exemplo a seguir:
"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\"",
}
}
}
SLIs de latência
Para medir a latência, as funções do Cloud Run grava dados de métrica no Cloud Monitoring usando o tipo de recurso monitorado cloud_function e o tipo de métrica
function/execution_times. Os dados são uma distribuição do tempo de execução das funções em nanossegundos.
Filtre os dados usando status se precisar medir explicitamente a latência de todas as execuções ou apenas as execuções bem-sucedidas.
Para expressar um SLI de latência baseado em solicitações, use uma estrutura DistributionCut. O exemplo de SLO a seguir espera que 99% de todas as execuções das funções do Cloud Run estejam entre 0 e 100 ms em latência total em 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 fornece uma plataforma sem servidor totalmente gerenciada para criar e executar aplicativos. Escolha entre dois ambientes, padrão ou flexível. Para mais informações, consulte Como escolher um ambiente do App Engine.
Para mais informações sobre o App Engine, consulte:
- Documentação do App Engine.
- Lista de tipos de métrica
appengine.googleapis.com.
SLIs de disponibilidade
O App Engine grava dados de métricas no
Cloud Monitoring usando o
tipo de recurso monitorado
gae_app e
o tipo de métrica http/server/response_count.
Filtre os dados usando o rótulo de métrica response_code para contar as respostas "boas" e "totais".
Para expressar um SLI de disponibilidade baseado em solicitação para o App Engine, crie uma estrutura TimeSeriesRatio para solicitações boas a solicitações totais como mostrado
no exemplo a seguir:
"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\"",
}
}
}
SLIs de latência
Para medir a latência, o App Engine grava dados de métricas no
Cloud Monitoring usando o tipo de recurso monitorado gae_app
e o
tipo de métrica http/server/response_latencies.
Filtre os dados usando o rótulo de métrica response_code para contar as execuções "boas" e "totais".
Expresse um SLI de latência baseado em solicitações para o App Engine
usando uma estrutura
DistributionCut. O SLO de exemplo a seguir espera que 99% de todas as solicitações estejam 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 do Kubernetes gerenciado e seguro do Google com escalonamento automático quadridirecional e suporte a vários clusters. O Istio é uma malha de serviço de código aberto que permite conectar, proteger, controlar e observar serviços. O Istio pode ser instalado no GKE como um complemento (Cloud Service Mesh) ou pelo usuário no projeto de código aberto. Em ambos os casos, o Istio fornece telemetria excelente, incluindo informações sobre tráfego, erros e latência para cada serviço gerenciado pela malha.
Para uma lista completa das métricas do Istio, consulte Tipos de métricas istio.io.
SLIs de disponibilidade
O Istio grava dados de métricas no Cloud Monitoring usando o tipo de métrica service/server/request_count e um dos tipos de recursos monitorados a seguir:
Filtre os dados usando o rótulo de métrica response_code para contar solicitações "boas" e "totais". Também é possível usar o rótulo de métrica destination_service_name para contar solicitações para um serviço específico.
Para expressar um SLI de disponibilidade baseado em solicitação para um serviço em execução no GKE gerenciado pela malha de serviço do Istio, crie uma estrutura TimeSeriesRatio para solicitações boas a solicitações totais, conforme mostrado no exemplo a seguir:
"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\"",
}
}
}
SLIs de latência
Para medir a latência, o Istio grava dados de métricas no Cloud Monitoring usando o tipo de métrica service/server/response_latencies e um dos tipos de recursos monitorados a seguir:
Filtre os dados usando o rótulo de métrica para contar solicitações response_code e "good" and "total" requests. You can also use the. Use o rótulo de métrica destination_service_name para contar solicitações de um serviço específico.
Expresse um SLI de latência baseado em solicitação para um serviço em execução no GKE gerenciado pela malha de serviço do Istio usando uma estrutura DistributionCut.
O SLO de exemplo a seguir espera que 99% de todas as solicitações para o serviço frontend estejam entre 0 e 100 ms em latência total em um período de uma hora contínua:
{
"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"
}