Como monitorar RU/s normalizadas para uma conta ou um contêiner do Azure Cosmos DB

APLICA-SE AO: NoSQL MongoDB Cassandra Gremlin Table

O Azure Monitor para Azure Cosmos DB fornece uma exibição de métricas para monitorar sua conta e criar painéis. As métricas do Azure Cosmos DB são coletadas por padrão, e esse recurso não exige que você habilite nem configure nada explicitamente.

Definição de métrica

A métrica de Consumo de RU Normalizado é uma métrica entre 0% e 100% usada para ajudar a medir a utilização da taxa de transferência provisionada em um banco de dados ou contêiner. A métrica é emitida em intervalos de 1 minuto e é definida como a utilização máxima de RU/s em todos os intervalos de chaves de partição no intervalo de tempo. Cada intervalo de chaves de partição é mapeado para uma partição física e é atribuído para manter dados para um intervalo de valores de hash possíveis. Em geral, quanto maior a porcentagem de RU normalizado, mais você utilizou sua taxa de transferência provisionada. A métrica também pode ser usada para exibir a utilização de intervalos de chaves de partição individuais em um banco de dados ou contêiner.

Por exemplo, suponha que você tenha um contêiner onde você define a taxa de transferência máxima de dimensionamento automático de 20.000 RU/s (dimensionado entre 2000 e 20.000 RU/s) e você tem dois intervalos de chaves de partição (partições físicas) P1 e P2. Como o Azure Cosmos DB distribui a taxa de transferência provisionada igualmente em todos os intervalos de chaves de partição, P1 e P2 podem ser dimensionados entre 1000 e 10.000 RU/s. Suponha que em um intervalo de 1 minuto, em um determinado segundo, P1 consumiu 6.000 unidades de solicitação e P2 consumiu 8.000 unidades de solicitação. O consumo normalizado de RU de P1 é de 60% e 80% para P2. O consumo geral de RU normalizado de todo o contêiner é de MAX(60%, 80%) = 80%.

Se você estiver interessado em ver o consumo da unidade de solicitação em um intervalo por segundo, juntamente com o tipo de operação, poderá usar os Logs de Diagnóstico do recurso opcional e consultar a tabela PartitionKeyRUConsumption. Para obter uma visão geral de alto nível das operações e do código de status que seu aplicativo está executando no recurso do Azure Cosmos DB, você pode usar a métrica interna do Azure Monitor Total de Solicitações (API para o NoSQL), Solicitações do Mongo, Solicitações do Gremlin ou Solicitações do Cassandra. Posteriormente, você pode filtrar essas solicitações pelo código de status 429 e dividi-las por Tipo de Operação.

O que esperar e fazer quando RU/s normalizadas for maior

Quando o consumo normalizado de RU atingir 100% para determinado intervalo de chaves de partição e se um cliente ainda fizer solicitações nessa janela de tempo de 1 segundo para esse intervalo de chaves de partição específico, ele receberá um erro de taxa limitada (429).

Isso não significa necessariamente que haja um problema com seu recurso. Por padrão, os SDKs de cliente do Azure Cosmos DB e as ferramentas de importação de dados, como Azure Data Factory e biblioteca de executores em massa, retentam automaticamente em 429s. Eles são repetidos normalmente até 9 vezes. Como resultado, embora você possa ver os 429s nas métricas, esses erros podem nem mesmo ser retornados ao seu aplicativo.

Em geral, para uma carga de trabalho de produção, se você vir entre 1-5% das solicitações com 429s, e a latência de ponta a ponta for aceitável, esse é um sinal saudável de que as RU/s estão sendo utilizadas em sua totalidade. Nesse caso, a métrica de consumo de RU normalizado atingindo 100% significa apenas que, em um determinado segundo, pelo menos um intervalo de chaves de partição usou toda a taxa de transferência provisionada. Isso é aceitável porque a taxa global de 429s ainda é baixa. Nenhuma ação do usuário é necessária.

Para determinar qual porcentagem de suas solicitações para seu banco de dados ou contêiner resultou em 429s, na folha da conta do Azure Cosmos DB, acesse Insights>Solicitações>Total de Solicitações por Código de Status. Filtre para um banco de dados e contêiner específicos. Para a API do Gremlin, use a métrica Solicitações do Gremlin. Total Requests by Status Code chart that shows number of 429 and 2xx requests.

Se a métrica de consumo de RU normalizado for consistentemente 100% entre vários intervalos de chaves de partição e a taxa de 429s for maior que 5%, é recomendável aumentar a taxa de transferência. Você pode descobrir quais operações são pesadas e o uso de pico delas utilizando as métricas do Azure Monitor e os logs de diagnóstico do Azure Monitor. Siga as práticas recomendadas para escalar a taxa de transferência provisionada (RU/s).

Nem sempre você verá o erro de limitação de taxa 429 apenas porque a RU normalizada atingiu 100%. Isso ocorre porque o RU normalizado é um único valor que representa o uso máximo em todos os intervalos de chave de partição. Um intervalo de chaves de partição pode estar ocupado, mas os outros intervalos de chaves de partição podem atender a solicitações sem problemas. Por exemplo, uma única operação, como um procedimento armazenado que consome todas as RU/s em um intervalo de chaves de partição, levará a um curto pico na métrica de consumo normalizado de RU/s. Nesses casos, não haverá erro de limitação de taxa imediata, se a taxa de solicitação geral for baixa ou se forem feitas solicitações a outras partições em diferentes intervalos de chaves de partição.

Saiba mais sobre como interpretar e depurar erros de limitação de taxa 429.

Como monitorar partições frequentes

A métrica de consumo de RU normalizado pode ser usada para monitorar se a carga de trabalho possui uma partição frequente. Uma partição em chamas ocorre quando uma ou algumas chaves de partição lógicas consomem uma quantidade desproporcional do total de RU/s devido a um volume de solicitação mais alto. Isso pode ser causado por um design de chave de partição que não distribui as solicitações de maneira uniforme. Isso resulta em muitas solicitações sendo direcionadas a um pequeno subconjunto de partições lógicas (o que pressupõe intervalos de chaves de partição) que se tornam "frequentes". Como todos os dados de uma partição lógica residem em um intervalo de chave de partição e o total de RU/s é distribuído uniformemente entre todos os intervalos de chaves de partição, uma partição frequente pode levar a 429s e o uso ineficiente da taxa de transferência.

Como identificar se há uma partição frequente

Para verificar se há uma partição em chamas, navegue até Insights>Taxa de Transferência>Consumo de RU Normalizado (%) Por PartitionKeyRangeID. Filtre para um banco de dados e contêiner específicos.

Cada PartitionKeyRangeId é mapeada para uma partição física. Se houver um PartitionKeyRangeId que tenha um consumo de RU normalizado significativamente maior do que outros (por exemplo, um está consistentemente em 100%, mas outros estão em 30% ou menos), isso pode ser um sinal de uma partição em chamas.

Normalized RU Consumption by PartitionKeyRangeId chart with a hot partition.

Para identificar as partições lógicas que estão consumindo mais RU/s, bem como as soluções recomendadas, consulte o artigo Diagnosticar e solucionar problemas com exceções de taxas de solicitação do Azure Cosmos DB (429).

Consumo de RU normalizado e dimensionamento automático

A métrica de consumo de RU normalizado será mostrada como 100% se pelo menos 1 intervalo de chaves de partição usar todas as RU/s alocadas em qualquer segundo determinado no intervalo de tempo. Uma pergunta comum que surge é: por que o consumo normalizado de RU é de 100%, mas o Azure Cosmos DB não dimensionou as RU/s para a taxa de transferência máxima com dimensionamento automático?

Observação

As informações abaixo descrevem a implementação atual do dimensionamento automático e podem estar sujeitas a alterações no futuro.

Quando você usa o dimensionamento automático, o Azure Cosmos DB dimensiona as RU/s para a taxa de transferência máxima somente quando o consumo de RU normalizado for de 100% para um período de tempo contínuo e sustentado em um intervalo de 5 segundos. Isso é feito para garantir que a lógica de dimensionamento seja econômica para o usuário, pois garante que picos únicos e momentâneos não levem a um dimensionamento desnecessário e custos mais altos. Quando há picos momentâneos, o sistema normalmente é dimensionado para um valor superior ao dimensionado anteriormente para RU/s, mas inferior ao máximo de RU/s.

Por exemplo, suponha que você tenha um contêiner com taxa de transferência máxima de dimensionamento automático de 20.000 RU/s (dimensionado entre 2000 e 20.000 RU/s) e dois intervalos de chaves de partição. Cada intervalo de chaves de partição pode ser dimensionado entre 1000 e 10.000 RU/s. Como o dimensionamento automático provisiona todos os recursos necessários antecipadamente, você pode usar até 20.000 RU/s a qualquer momento. Digamos que você tenha um pico intermitente de tráfego, em que, por um segundo, o uso de um dos intervalos de chaves de partição é de 10.000 RU/s. Nos segundos subsequentes, o uso volta para 1000 RU/s. Como a métrica de consumo de RU normalizado mostra a maior utilização no período em todas as partições, ela mostrará 100%. No entanto, como a utilização foi de apenas 100% por 1 segundo, o dimensionamento automático não será dimensionado automaticamente ao máximo.

Dessa forma, mesmo que o dimensionamento automático não tenha sido dimensionado ao máximo, você ainda conseguiu usar o total de RU/s disponíveis. Para verificar o consumo de RU/s, você pode usar os Logs de Diagnóstico do recurso de aceitação para consultar o consumo geral de RU/s em um nível por segundo em todos os intervalos de chaves de partição.

CDBPartitionKeyRUConsumption
| where TimeGenerated >= (todatetime('2022-01-28T20:35:00Z')) and TimeGenerated <= todatetime('2022-01-28T20:40:00Z')
| where DatabaseName == "MyDatabase" and CollectionName == "MyContainer"
| summarize sum(RequestCharge) by bin(TimeGenerated, 1sec), PartitionKeyRangeId
| render timechart

Em geral, para uma carga de trabalho de produção usando o dimensionamento automático, se você vir entre 1-5% das solicitações com 429s, e a latência de ponta a ponta for aceitável, esse é um sinal saudável de que as RU/s estão sendo utilizadas em sua totalidade. Mesmo que o consumo normalizado de RU ocasionalmente atinja 100% e o dimensionamento automático não seja dimensionado até o máximo de RU/s, não há problemas, pois a taxa geral de 429s é baixa. Nenhuma ação é necessária.

Dica

Se você estiver usando o dimensionamento automático e descobrir que o consumo normalizado de RU é consistentemente 100% e você é dimensionado consistentemente para o máximo de RU/s, isso é um sinal de que usar a taxa de transferência manual pode ser mais econômico. Para determinar se o dimensionamento automático ou a taxa de transferência manual é melhor para sua carga de trabalho, consulte como escolher entre a taxa de transferência provisionada padrão (manual) e o dimensionamento automático. O Azure Cosmos DB também envia Recomendações do Assistente do Azure com base nos seus padrões de carga de trabalho para recomendar a taxa de transferência manual ou de dimensionamento automático.

Exibir a métrica de consumo normalizado de unidade de solicitação

  1. Entre no portal do Azure.

  2. Selecione Monitor na barra de menus de navegação à esquerda e selecione Métricas.

    Metrics pane in Azure Monitor

  3. No painel Métricas>Selecionar um recurso > escolha a assinatura necessária e o grupo de recursos. Para o Tipo de recurso, selecione Contas do Azure Cosmos DB, escolha uma das contas existentes do Azure Cosmos DB e selecione Aplicar.

    Select the account scope to view metrics

  4. Em seguida, você pode selecionar uma métrica na lista de métricas disponíveis. Você pode selecionar métricas específicas para unidades de solicitação, armazenamento, latência, disponibilidade, Cassandra e outros. Para saber mais detalhadamente sobre todas as métricas disponíveis nesta lista, consulte o artigo Métricas por categoria. Neste exemplo, vamos selecionar métrica Consumo Normalizado de RU e Max como o valor de agregação.

    Além desses detalhes, você também pode selecionar o Intervalo de tempo e a Granularidade de tempo das métricas. Você pode exibir as métricas de, no máximo, os últimos 30 dias. Depois que você aplicar o filtro, um gráfico será exibido com base no seu filtro.

    Choose a metric from the Azure portal

Filtros para a métrica de consumo de RU normalizado

Você também pode filtrar as métricas e o gráfico exibidos por um CollectionName, DatabaseName, PartitionKeyRangeID e Region específicos. Para filtrar as métricas, selecione Adicionar filtro e escolha a propriedade necessária, como CollectionName e o valor correspondente no qual você está interessado. O grafo então exibe as métricas de consumo normalizado de RU pelo contêiner para o período selecionado.

Você pode agrupar as métricas usando a opção Aplicar divisão. Para bancos de dados de taxa de transferência compartilhada, a métrica de RU normalizada mostra os dados somente na granularidade dos bancos de dados, mas ela não mostra nenhum dado por coleção. Portanto, para o banco de dados de taxa de transferência compartilhada, você não verá nenhum dado quando aplicar a divisão pelo nome da coleção.

A métrica de consumo normalizado de unidade de solicitação para cada contêiner é exibida conforme mostrado na imagem a seguir:

Apply filters to normalized request unit consumption metric

Próximas etapas