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

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

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, esse recurso não exige que você habilite ou configure nada explicitamente.

Definição de métrica

A métrica 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 preservar os dados de um intervalo de valores hash possíveis. Em geral, quanto maior for a percentagem de RU Normalizadas, mais débito aprovisionado foi utilizado. 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 defina a taxa de transferência máxima de escala automática de 20.000 RU/s (escalas entre 2000 - 20.000 RU/s) e tenha 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 6000 unidades de solicitação e P2 consumiu 8000 unidades de solicitação. O consumo normalizado de RU de P1 é de 60% e 80% para P2. O consumo global normalizado de RU de todo o recipiente é 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, você pode usar o recurso de aceitação Logs de diagnóstico 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 Azure Monitor Total Requests (API for NoSQL), Mongo Requests, Gremlin Requests ou Cassandra Requests . Mais tarde, 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 o RU/s normalizado é maior

Quando o consumo normalizado de RU atinge 100% para determinado intervalo de chaves de partição, e se um cliente ainda faz solicitações nessa janela de tempo de 1 segundo para esse intervalo de chave de partição específico - ele recebe um erro limitado de taxa (429).

Isso não significa necessariamente que há 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 o Azure Data Factory e a biblioteca de executores em massa, repetem automaticamente as solicitações em 429s. Eles tentam novamente normalmente até 9 vezes. Como resultado, embora você possa ver 429s nas métricas, esses erros podem nem ter sido retornados ao seu aplicativo.

Em geral, para uma carga de trabalho de produção, se vir entre 1–5% dos pedidos com erros 429 e a latência ponto a ponto for aceitável, é um bom sinal de que as RU/s estão a ser totalmente utilizadas. Nesse caso, a métrica de consumo de RU normalizada atingindo 100% significa apenas que, em um determinado segundo, pelo menos um intervalo de chaves de partição usou toda a sua taxa de transferência provisionada. Isto é aceitável porque a taxa global de 429s ainda é baixa. Não são necessárias mais ações.

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, navegue até Total de solicitações do Insights>>por código de status. Filtre para um banco de dados e contêiner específicos. Para API para Gremlin, use a métrica Gremlin Requests .

Se a métrica de consumo de RU normalizada for consistentemente de 100% em 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. Pode descobrir que operações são pesadas e qual é a utilização máxima com as métricas do Azure Monitor e os registos de diagnóstico do Azure Monitor. Siga as melhores práticas para o dimensionamento do débito aprovisionado (RU/s).

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

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

Como monitorar partições quentes

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

Como identificar se há uma partição quente

Para verificar se há uma partição ativa, navegue até Consumo de RU normalizado de taxa de transferência>do Insights>(%) por PartitionKeyRangeID. Filtre para um banco de dados e contêiner específicos.

Cada PartitionKeyRangeId é mapeado 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 quente.

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 de exceções de taxa de solicitação do Azure Cosmos DB muito grandes (429).

Consumo normalizado de RU e dimensionamento automático

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

Quando você usa o dimensionamento automático, o Azure Cosmos DB só dimensiona o RU/s para a taxa de transferência máxima quando o consumo normalizado de RU é de 100% por um período de tempo sustentado e contínuo 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 escalonamentos desnecessários e custos mais altos. Quando há picos momentâneos, o sistema normalmente escala até um valor maior do que o anteriormente dimensionado para RU/s, mas menor do que o 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 (escala entre 2000 - 20.000 RU/s) e 2 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, onde, por um único 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 normalizada mostra a maior utilização no período de tempo 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.

Como resultado, mesmo que a escala automática não fosse dimensionada ao máximo, você ainda podia usar o total de RU/s disponível. Para verificar seu consumo de RU/s, você pode usar o recurso de aceitação Logs de diagnóstico 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 escala automática, se você vir entre 1-5% das solicitações com 429s, e sua latência de ponta a ponta for aceitável, isso é um sinal saudável de que os RU/s estão sendo totalmente utilizados. Mesmo que o consumo normalizado de RU ocasionalmente atinja 100% e a escala automática não aumente para o máximo de RU/s, isso é ok porque a taxa geral de 429s é baixa. nenhuma ação necessária.

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

1. Inicie sessão no portal do Azure.

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

   

3. No painel> Métricas, selecione 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 suas contas existentes do Azure Cosmos DB e selecione Aplicar.

   

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 a métrica Consumo de RU normalizado 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. No máximo, você pode visualizar as métricas dos últimos 30 dias. Depois de aplicar o filtro, é apresentado um gráfico com base no filtro.

   

Filtros para métrica de consumo de RU normalizada

Você também pode filtrar métricas e o gráfico exibido 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 em que você está interessado. Em seguida, o gráfico exibe a métrica de consumo de RU normalizada para o contêiner para o período selecionado.

Você pode agrupar métricas usando a opção Aplicar divisão . Para bancos de dados de taxa de transferência compartilhados, a métrica RU normalizada mostra dados apenas na granularidade do banco de dados, não mostra nenhum dado por coleção. Portanto, para o banco de dados de taxa de transferência compartilhado, você não verá nenhum dado quando aplicar a divisão por nome de coleção.

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

Próximos passos

• Monitore os dados do Azure Cosmos DB usando as configurações de diagnóstico no Azure.
• Auditar as operações do plano de controle do Azure Cosmos DB
• Diagnosticar e resolver problemas de exceções A taxa de pedidos do Azure Cosmos DB é demasiado grande (429)