Acerca das rácios de métricas

Este documento ajuda a escolher a melhor abordagem para representar graficamente ou monitorizar uma proporção de dados de métricas. Também inclui links para exemplos, identifica quando pode calcular rácios e descreve as anomalias que pode ver quando cria um gráfico de um rácio de duas métricas diferentes. Estas anomalias devem-se a diferenças na taxa de amostragem ou nos parâmetros de alinhamento.

As rácios permitem-lhe transformar os dados das métricas num formato diferente e, potencialmente, mais útil. Por exemplo, considere um tipo de métrica que contabiliza o número de respostas HTTP por código de resposta. Os dados das métricas comunicam o número de erros, mas não a proporção de pedidos que falharam. No entanto, os requisitos de desempenho são frequentemente especificados como uma percentagem, como "A taxa de erro tem de ser inferior a 0,1%". Para determinar a taxa de erro através dos dados das métricas, calcula a proporção de pedidos com falhas em relação ao número total de pedidos.

Práticas recomendadas

Para monitorizar ou representar graficamente uma proporção de dados de métricas, recomendamos que use o PromQL. Pode usar o PromQL com a API Cloud Monitoring e com a Google Cloud consola. A Google Cloud consola inclui um editor de código que fornece sugestões, deteção de erros e outro apoio técnico para criar consultas PromQL válidas.

Para criar uma política de alerta que monitorize uma proporção de métricas quando não conhece o PromQL, use a API Cloud Monitoring e inclua um filtro de séries cronológicas. Para ver um exemplo, consulte o artigo Rácio de métricas.

Para criar um gráfico de uma proporção de dados de métricas quando não conhece o PromQL, recomendamos que use a Google Cloud consola e uma interface orientada por menus. Para ver instruções detalhadas, consulte os artigos: Crie um gráfico de uma proporção de métricas e Adicione gráficos e tabelas a um painel de controlo personalizado.

Restrições com rácios

Quando configura uma proporção, aplicam-se as seguintes restrições:

  • Após a agregação, as etiquetas na série cronológica do denominador têm de ser iguais ou um subconjunto das etiquetas na série cronológica do numerador.

    Recomendamos que selecione opções de agregação de forma que, após a agregação, as séries cronológicas do numerador e do denominador tenham as mesmas etiquetas.

    Considere uma configuração em que a série cronológica do numerador tem etiquetas method, quota_metric e project_id. A série cronológica do denominador tem as etiquetas limit_name, quota_metric e project_id. As opções válidas para o agrupamento do denominador dependem das seleções do numerador:

    • Numerador agrupado pela etiqueta method: combine a série cronológica do denominador numa única série cronológica. Nenhuma outra agrupamento resulta nas etiquetas da série cronológica do denominador serem um subconjunto das etiquetas da série cronológica do numerador.
    • Numerador agrupado pela etiqueta quota_metric: Agrupe o denominador por essa etiqueta ou combine todas as séries cronológicas no denominador numa única série cronológica.
    • Numerador agrupado pelas etiquetas quota_metric e project_id: Agrupe o denominador por ambas as etiquetas, por uma etiqueta ou combine a série cronológica do denominador numa única série cronológica.

    As opções de agregação de denominador válidas eliminam sempre a etiqueta limit_name da série cronológica agrupada porque essa etiqueta não está presente na série cronológica do numerador.

  • O período de alinhamento tem de ser o mesmo para o numerador e o denominador quando configurar um gráfico através da Google Cloud consola; no entanto, estes campos podem ser diferentes quando usar a API Cloud Monitoring.

    Recomendamos que use o mesmo período de alinhamento para o numerador e o denominador, independentemente da ferramenta que usar para criar o gráfico.

  • O numerador e o denominador têm de ter o mesmo tipo de valor. Por exemplo, quando o numerador é do tipo DOUBLE, o denominador também tem de ser do tipo DOUBLE.

    As rácios requerem que a métrica do numerador e do denominador tenha um tipo de valor de DOUBLE ou INT64.

  • As séries cronológicas alinhadas para o numerador e o denominador têm de ter o mesmo tipo de métrica. Quando as duas métricas têm tipos diferentes, tem de usar alinhadores para as converter no mesmo tipo.

    Considere uma configuração em que uma métrica DELTA é selecionada para o numerador e uma métrica GAUGE é selecionada para o denominador. Nesta situação, use o alinhador de taxas ALIGN_RATE, para converter a métrica DELTA numa métrica GAUGE. Para ver um exemplo, consulte o artigo Políticas de alerta de rácios sobre a utilização da quota de taxa para um limite.

  • Para rácios que não estão definidos com PromQL, o tipo de recurso monitorizado tem de ser o mesmo para o numerador e o denominador.

    Por exemplo, se o recurso da métrica do numerador forem instâncias do Compute Engine, o recurso da métrica do denominador também tem de ser instâncias do Compute Engine.

Anomalias devido a amostragem e incompatibilidades de alinhamento

Em geral, é melhor calcular as rácios com base nas séries cronológicas recolhidas para um único tipo de métrica, usando valores de etiquetas. Uma proporção calculada em dois tipos de métricas diferentes está sujeita a anomalias devido a diferentes períodos de amostragem e janelas de alinhamento.

Por exemplo, suponhamos que tem dois tipos de métricas diferentes, uma contagem total de RPCs e uma contagem de erros de RPCs, e quer calcular a proporção de RPCs de contagem de erros em relação ao total de RPCs. As RPCs sem êxito são contabilizadas na série cronológica de ambos os tipos de métricas. Por conseguinte, existe a possibilidade de, quando alinhar as séries cronológicas, uma RPC sem êxito não aparecer no mesmo intervalo de alinhamento para ambas as séries cronológicas. Esta diferença pode acontecer por vários motivos, incluindo os seguintes:

  • Porque existem duas séries cronológicas diferentes a registar o mesmo evento, existem dois valores de contador subjacentes a implementar a recolha e não são atualizados de forma atómica.
  • As taxas de amostragem podem diferir. Quando as séries cronológicas estão alinhadas com um período comum, as contagens de um único evento podem aparecer em intervalos de alinhamento adjacentes nas séries cronológicas para as diferentes métricas.

A diferença no número de valores nos intervalos de alinhamento correspondentes pode gerar valores de rácio error/total sem sentido, como 1/0 ou 2/1.

As proporções de números maiores têm menos probabilidade de resultar em valores sem sentido. Pode obter números maiores através da agregação, quer usando um período de alinhamento que seja mais longo do que o período de amostragem, quer agrupando dados para determinadas etiquetas. Estas técnicas minimizam o efeito de pequenas diferenças no número de pontos num determinado intervalo. Ou seja, uma disparidade de dois pontos é mais significativa quando o número esperado de pontos num intervalo é 3 do que quando o número esperado é 300.

Se estiver a usar tipos de métricas incorporados, pode não ter outra opção senão calcular rácios entre tipos de métricas para obter o valor de que precisa.

Se estiver a criar métricas personalizadas que podem contar a mesma coisa, como RPCs que devolvem o estado de erro, em duas métricas diferentes, considere usar uma única métrica que inclua cada contagem apenas uma vez. Por exemplo, suponhamos que está a contabilizar RPCs e quer acompanhar a proporção de RPCs sem êxito em relação a todas as RPCs. Para resolver este problema, crie um único tipo de métrica para contabilizar os RPCs e use uma etiqueta para registar o estado da invocação, incluindo o estado "OK". Em seguida, cada valor de estado, erro ou "OK", é registado atualizando um único contador para esse caso.

O que se segue?