Medir os SLOs

Last reviewed 2024-03-29 UTC

Este documento do framework de arquitetura do Google Cloud se baseia nas discussões anteriores sobre objetivos de nível de serviço (SLOs) explorando o que e como medir em relação a cargas de trabalho de serviço comuns. Este documento se baseia nos conceitos definidos em Componentes de objetivos de nível de serviço.

Decida o que avaliar

Seja qual for o domínio, muitos serviços compartilham recursos comuns e podem usar SLOs genéricos. Nesta seção, discutimos SLOs genéricos para diferentes tipos de serviço e fornecemos explicações detalhadas dos SLIs que se aplicam a cada SLO.

Cada uma das subseções a seguir identifica um tipo de serviço específico e fornece uma breve descrição desse serviço. Em seguida, em cada tipo de serviço, estão listados possíveis SLIs, uma definição do indicador e outras informações relacionadas ao SLI.

Serviços orientados por solicitação

Esse tipo de serviço recebe uma solicitação de um cliente (um usuário ou outro serviço), executa alguns cálculos, possivelmente envia solicitações de rede para um back-end e retorna uma resposta ao cliente.

Disponibilidade como um SLI

Disponibilidade é a proporção de solicitações válidas que são veiculadas. A lista a seguir abrange informações a serem consideradas ao usar a disponibilidade como um SLI:

  • Como proprietário do serviço, você decide o que é uma solicitação válida. As definições comuns incluem não tamanho zero ou adere a um protocolo cliente-servidor. Um método para avaliar a validade é analisar os códigos de resposta HTTP (ou RPC). Por exemplo, códigos HTTP 5xx são erros relacionados ao servidor que contam em um SLO, enquanto os códigos 4xx são erros de cliente que não contam.
  • Cada código de resposta retornado pelo serviço precisa ser examinado para garantir que o aplicativo use esses códigos de maneira adequada e consistente. O código é um indicador preciso da experiência dos usuários com o serviço? Por exemplo, como um site de e-commerce responde quando um usuário tenta pedir um item esgotado? A solicitação falha e retorna uma mensagem de erro? O site sugere produtos semelhantes? Os códigos de erro precisam estar vinculados às expectativas do usuário.
  • Os desenvolvedores podem usar erros de forma acidental. Usando o cenário esgotado do marcador anterior, um desenvolvedor pode retornar um erro por engano. No entanto, o sistema está funcionando corretamente e não retornando erro. O código precisa retornar um sucesso, mesmo que o usuário não tenha conseguido comprar o item. Embora os proprietários de serviços devam receber uma notificação sobre o baixo inventário, a incapacidade de fazer uma venda não é um erro do ponto de vista do cliente e não é contabilizado em um SLO.
  • Um exemplo de serviço mais complexo é aquele que gerencia solicitações assíncronas ou fornece um processo de longa duração para os clientes. Embora seja possível expor a disponibilidade de outra maneira, recomendamos representar a disponibilidade como a proporção de solicitações válidas que são bem-sucedidas. A disponibilidade também pode ser definida como o número de minutos em que a carga de trabalho do cliente está em execução (às vezes chamada de abordagem de bons minutos).
  • Considere um serviço que oferece máquinas virtuais (VMs). É possível medir a disponibilidade em termos do número de minutos após uma solicitação inicial de que a VM está disponível para o usuário.

Latência como um SLI

A latência (ou velocidade) é a proporção de solicitações válidas que são exibidas mais rápido que um limite. Assim, a latência indica a rapidez do serviço e pode ser medida pelo cálculo da diferença entre os horários de início e término de um determinado tipo de solicitação. Essa é a percepção de latência do usuário, e os proprietários de serviços geralmente medem esse valor com muita precisão. Na realidade, os usuários não conseguem distinguir entre uma atualização de 100 milissegundos (ms) e uma atualização de 300 ms e podem até aceitar respostas entre 300 ms e 1.000 ms como normal. Para mais informações, consulte o Modelo de cauda.

Desenvolva métricas centradas na atividade com foco no usuário. Veja a seguir alguns exemplos dessas métricas:

  • Interativo: um usuário aguarda 1.000 ms por um resultado depois de clicar em um elemento.
  • Gravação: uma alteração em um sistema distribuído subjacente leva 1.500 ms. Embora esse período seja considerado lento, os usuários tendem a aceitá-lo. Recomendamos que você diferencie explicitamente entre gravações e leituras em suas métricas.
  • Segundo plano: ações que não são visíveis ao usuário, como uma atualização periódica de dados ou outras solicitações assíncronas, não levam mais de 5.000 ms para serem concluídas.

A latência é geralmente medida como uma distribuição e conforme mencionado em Escolha seus SLIs. Dada uma distribuição, é possível medir vários percentis. Por exemplo, é possível medir o número de solicitações que são mais lentas do que o 99º percentil histórico. Os eventos mais rápidos que esse limite são considerados bons; as solicitações mais lentas são consideradas não tão boas. Você define esse limite com base nos requisitos do produto. É possível definir vários SLOs de latência, por exemplo, latência típica versus latência de cauda.

Não use apenas a latência média (ou mediana) como SLI. Se a latência média for muito lenta, metade dos usuários já está insatisfeito. Além disso, o serviço pode passar por uma latência ruim por dias antes da descoberta do problema. Portanto, defina seu SLO de latência de cauda (95o percentil) e de latência mediana (50o percentil).

No artigo Métricas importantes da ACM, Benjamin Treynor Sloss escreve o seguinte:

  • "Uma boa regra prática... é que a latência de 99º percentil não deve ser mais que três a cinco vezes a latência mediana."
  • "Descobrimos que as medidas de latência de 50º, 95º e 99º percentis de um serviço são valiosas individualmente, e o ideal é definir os SLOs para cada uma delas."

Determine seus limites de latência com base em percentis históricos e meça quantas solicitações se enquadram em cada bucket. Essa abordagem é um bom modelo a seguir.

Qualidade como um SLI

Qualidade é a proporção de solicitações válidas que são veiculadas sem degradação do serviço. Por exemplo, qualidade é um SLI útil para serviços complexos projetados para falhar normalmente. Para ilustrar, considere uma página da Web que carrega o conteúdo principal de um repositório de dados e recursos opcionais de 100 outros serviços e repositórios de dados. Se um dos elementos opcionais estiver fora de serviço ou for muito lento, a página ainda será renderizada sem os elementos opcionais. Nesse cenário, é possível usar SLIs para as seguintes ações:

  • Ao medir o número de solicitações que recebem uma resposta degradada (uma resposta sem resposta de pelo menos um serviço de back-end), é possível informar a proporção de solicitações inválidas.
  • É possível acompanhar o número de respostas sem resposta de um único back-end ou de vários back-ends.

Serviços de processamento de dados

Esses serviços consomem dados de uma entrada, processam esses dados e geram uma saída. O desempenho do serviço em etapas intermediárias não é tão importante quanto o resultado final. Os SLIs mais fortes são atualização, cobertura, precisão e capacidade. A latência e a disponibilidade são menos úteis.

Atualização como um SLI

A atualização é a proporção de dados válidos atualizados mais recentemente do que um limite. A lista a seguir fornece alguns exemplos de como usar a atualização como um SLI:

  • Em um sistema em lote, a atualização é medida como o tempo decorrido durante uma execução de processamento concluída para uma determinada saída.
  • No processamento em tempo real ou em sistemas mais complexos, a atualização rastreia a idade do registro mais recente processado em um pipeline.
  • Em um jogo on-line que gera blocos de mapa em tempo real, os usuários podem não perceber a rapidez com que os blocos são criados, mas podem perceber quando os dados do mapa estão ausentes ou não estão atualizados. Nesse caso, a atualização rastreia dados ausentes ou desatualizados.
  • Em um serviço que lê registros em um sistema de rastreamento para gerar a mensagem "X itens em estoque" para um site de e-commerce, um SLI de atualização pode ser definido como a porcentagem de solicitações que estão usando informações de estoque atualizadas recentemente (dentro de última hora).
  • É possível também usar uma métrica para exibir dados não atualizados para atualizar o SLI quanto à qualidade.

Cobertura como um SLI

Cobertura é a proporção de dados válidos processados.

Para definir a cobertura, siga estas etapas:

  1. Determine se uma entrada será aceita como válida ou ignore-a. Por exemplo, se um registro de entrada estiver corrompido ou tiver tamanho zero e não puder ser processado, considere o registro inválido como uma métrica.
  2. Conte o número de registros válidos. Essa contagem pode ser realizada com um método *count() *simples e representa a contagem total de registros.
  3. Por fim, conte o número de registros que foram processados e compare esse número com a contagem total de registros válidos. Esse valor é o SLI para cobertura.

Correção como um SLI

A correção é a proporção de dados válidos que produziram a saída correta. Considere os seguintes pontos ao usar a correção como um SLI:

  • Em alguns casos, os métodos para determinar a exatidão de uma saída são usados para validar o processamento da saída. Por exemplo, um sistema que gira ou colore uma imagem nunca deve produzir uma imagem de zero byte ou uma imagem com comprimento ou largura igual a zero. É importante separar essa lógica de validação da própria lógica de processamento.
  • Um método para medir um SLI de correção é usar dados de entrada de teste comprovado que produzem uma saída correta conhecida. Lembre-se de que os dados de entrada precisam ser representativos dos dados do usuário.
  • Em outros casos, é possível usar uma verificação matemática ou lógica na saída, como no exemplo anterior de rotação de uma imagem.
  • Por fim, considere um sistema de faturamento que determina a validade da transação verificando a diferença entre o saldo antes e depois de uma transação. Se esse valor corresponder ao valor da transação, ela é válida.

Capacidade como um SLI

A capacidade de processamento é a proporção de tempo em que a taxa de processamento de dados foi mais rápida que o limite. Veja alguns pontos a serem considerados ao usar a capacidade como um SLI:

  • A capacidade de processamento em um sistema de processamento de dados geralmente é mais representativa da satisfação do usuário do que uma única medida de latência para uma determinada operação. Se o tamanho de cada entrada variar drasticamente, pode não fazer sentido comparar o tempo que cada elemento leva para ser concluído (se todos os jobs progridem a uma taxa aceitável).
  • Bytes por segundo é uma maneira comum de medir o volume de trabalho necessário para processar dados, seja qual for o tamanho do conjunto de dados. Mas qualquer métrica que faça o dimensionamento aproximado e linear em relação ao custo de processamento pode funcionar.
  • Pode valer a pena particionar os sistemas de processamento de dados com base nas taxas de capacidade de processamento esperadas. Ou implemente um sistema de qualidade de serviçoque garanta que as entradas de alta prioridade sejam processadas e que as de baixa prioridade sejam enfileiradas. De qualquer forma, medir a capacidade conforme definido nesta seção ajuda a determinar se seu sistema está funcionando como dentro do SLO.

Serviços de execução programada

Para serviços que precisam executar uma ação em um intervalo regular, como cron jobs do Kubernetes, é possível medir o desvio e a duração da execução. Veja a seguir um exemplo de cron job programado do Kubernetes:

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:
schedule: "0 * * * *"

Desvio como um SLI

Desvio é a proporção de execuções iniciadas dentro de uma janela aceitável do horário de início esperado. Ao usar o desvio, considere o seguinte:

  • O desvio mede a diferença de tempo entre o horário de início de um job e o horário de início real. Considere o exemplo anterior do cron job do Kubernetes. Se estiver definido para começar no minuto zero de cada hora, mas começar três minutos após a hora, o desvio será de três minutos. Quando um job é executado antecipadamente, você tem um desvio negativo.
  • É possível medir o desvio como uma distribuição ao longo do tempo, com intervalos aceitáveis correspondentes que definem um bom desvio. Para determinar o SLI, compare o número de execuções que estavam dentro de um bom intervalo.

Duração da execução como um SLI

Duração da execução é a proporção de execuções que são concluídas dentro da janela de duração aceitável. A seguir, abordamos conceitos importantes relacionados ao uso da duração da execução:

  • Duração da execução é o tempo que um job leva para ser concluído. Para uma determinada execução, um modo de falha comum é quando a duração real excede a duração programada.
  • Um caso interessante é aplicar esse SLI a um job sem fim. Como esses jobs não são concluídos, registre o tempo gasto em um determinado job em vez de esperar que um job seja concluído. Essa abordagem fornece uma distribuição precisa de quanto tempo leva para ser concluído, mesmo nos piores cenários.
  • Assim como acontece com o desvio, é possível acompanhar a duração da execução como uma distribuição e definir limites superiores e inferiores aceitáveis para bons eventos.

Métricas para outros tipos de sistema

Muitas outras cargas de trabalho têm as próprias métricas para gerar SLIs e SLOs. Confira estes exemplos:

  • Sistemas de armazenamento: durabilidade, capacidade de processamento, tempo para o primeiro byte, disponibilidade de blob;
  • Mídia/vídeo: continuidade de reprodução do cliente, tempo para iniciar a reprodução, transcodificação da totalidade de execução do gráfico;
  • Jogos: tempo para combinar jogadores ativos, tempo para gerar um mapa.

Decida como medir

A seção anterior abordou o que você está medindo. Depois de determinar o que medir, você pode decidir como medir. É possível coletar métricas de SLI de várias maneiras. As seções abaixo identificam vários métodos de medição, fornecem uma breve descrição de cada um, listam as vantagens e desvantagens e identificam as ferramentas de implementação adequadas para cada método.

Geração de registros do lado do servidor

O método de geração de registros do lado do servidor envolve o processamento de registros de solicitações ou dados processados do lado do servidor.

Geração de registros do lado do servidor Detalhes
Vantagens
  • Reprocessar os registros atuais para preencher os registros históricos de SLI.
  • Usar identificadores de sessão entre serviços para reconstruir jornadas complexas do usuário em vários serviços.
Desvantagens
  • As solicitações que não chegam ao servidor não são registradas.
  • As solicitações que causam falhas em um servidor podem não ser registradas.
  • O tempo de processamento dos registros pode resultar em SLIs obsoletos, que podem ser dados inadequados de uma resposta operacional.
  • Escrever código para processar registros pode ser uma tarefa passível de erro e demorada.
Método e ferramentas de implementação

Métricas do servidor de aplicativos

O método de métricas do servidor de aplicativos envolve a exportação de métricas de SLI do código que atende às solicitações do usuário ou processa os dados dele.

Métricas do servidor de aplicativos Detalhes
Vantagens
  • Adicionar novas métricas ao código geralmente é rápido e barato.
Desvantagens
  • As solicitações que não chegam aos servidores de aplicativos não são registradas.
  • As solicitações de vários serviços podem ser difíceis de rastrear.
Método e ferramentas de implementação

Métricas de infraestrutura de front-end

O método de métricas da infraestrutura de front-end usa métricas da infraestrutura de balanceamento de carga (como um balanceador de carga global de camada 7 no Google Cloud).

Métricas de infraestrutura de front-end Detalhes
Vantagens
  • Métricas e dados históricos geralmente já existem, o que reduz o esforço de engenharia para dar os primeiros passos.
  • As medições são realizadas no ponto mais próximo do cliente, mas ainda dentro da infraestrutura de exibição.
Desvantagens
  • Não é viável para SLIs de processamento de dados.
  • Só pode aproximar jornadas de usuário de várias solicitações.
Método e ferramentas de implementação

Clientes ou dados sintéticos

O método de clientes ou dados sintéticos envolve o uso de clientes que enviam solicitações fabricadas em intervalos regulares e valida as respostas.

Clientes ou dados sintéticos Detalhes
Vantagens
  • Mede todas as etapas de uma jornada do usuário de várias solicitações.
  • O envio de solicitações de fora da infraestrutura captura mais do caminho geral da solicitação no SLI.
Desvantagens
  • Aproximar a experiência do usuário com solicitações sintéticas pode ser enganosa (tanto falsos positivos quanto falsos negativos).
  • Cobrir todos os casos extremos é difícil e pode acabar virando um teste de integração.
  • Metas de alta confiabilidade exigem sondagens frequentes para uma medição precisa.
  • O tráfego da sondagem pode esconder o tráfego real.
Método e ferramentas de implementação

Instrumentação do cliente

O método de instrumentação de cliente envolve a adição de recursos de observabilidade ao cliente com que o usuário interage e o registro de eventos na infraestrutura de serviço que acompanha SLIs.

Instrumentação do cliente Detalhes
Vantagens
  • Fornece a medida mais precisa da experiência do usuário.
  • Pode quantificar a confiabilidade de terceiros, por exemplo, provedores de CDN ou de pagamento.
Desvantagens
  • A latência de processamento e ingestão de registros do cliente torna esses SLIs inadequados para acionar uma resposta operacional.
  • As medições de SLI incluirão vários fatores de alta variação, possivelmente fora do controle direto.
  • Incorporar a instrumentação ao cliente pode envolver muito trabalho de engenharia.
Método e ferramentas de implementação

Escolher um método de medição

Depois de decidir o que e como medir seu SLO, a próxima etapa é escolher um método que se alinhe melhor à experiência do cliente com o serviço e exige o mínimo de esforço da sua parte. Para atingir esse ideal, talvez seja necessário usar uma combinação dos métodos nas tabelas anteriores. Confira a seguir as abordagens sugeridas que podem ser implementadas ao longo do tempo, listadas em ordem crescente de esforço:

  • Use exportações de servidores de aplicativos e métricas de infraestrutura. Em geral, é possível acessar essas métricas de imediato, e elas agregam valor rapidamente. Algumas ferramentas de APM incluem as ferramentas de SLO integradas.
  • Use a instrumentação do cliente. Como os sistemas legados geralmente não têm instrumentação do cliente para usuário final integrada, a configuração da instrumentação pode exigir um investimento significativo. No entanto, se você usar um pacote de APM ou um framework de front-end que fornece instrumentação do cliente, poderá acessar rapidamente insights sobre a satisfação do cliente.
  • Use o processamento de registros. Se não for possível implementar exportações de servidor ou instrumentação do cliente (marcadores anteriores), mas os registros existirem, o processamento de registros pode ser a melhor abordagem. Outro método é combinar exportações e processamento de registros. Use exportações como uma fonte imediata para alguns SLIs (como disponibilidade imediata) e processamento de registros para sinais de longo prazo (como alertas de gravação lenta discutidos no guia sobre SLOs e alertas).
  • Implemente testes sintéticos. Depois de ter uma compreensão básica de como seus clientes usam seu serviço, você testa o nível do serviço. Por exemplo, alimente contas de teste com dados válidos conhecidos e consulte-os. Essa abordagem pode ajudar a destacar modos de falha que não são prontamente observados, como para serviços de baixo tráfego.

A seguir