Monitorar unidades de solicitação normalizadas no Azure Cosmos DB

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 métrica

O consumo normalizado de RU é 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 Unidades de Solicitação por segundo (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 a porcentagem de RU normalizada, 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 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 dado segundo, P1 consumiu 6.000 RUs e P2 consumiu 8.000 RUs. 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 estiver interessado em ver o consumo de unidade de solicitação num intervalo de um segundo, juntamente com o tipo de operação, pode usar os logs de diagnóstico de subscrição 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 um 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 chaves de partição específico, ele recebe um erro de taxa limitada (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 execução em massa, recomeçam automaticamente as solicitações ao receberem o código de status HTTP 429. Eles tentam novamente normalmente até nove 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 se observam entre 1-5% de solicitações com 429s, e a latência de ponta a ponta é aceitável, isso é um sinal saudável de que os RU/s estão a ser totalmente utilizados. 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 o seu banco de dados ou contêiner resultou em 429s, na sua conta do Azure Cosmos DB, navegue até Insights>Solicitações>Total de Solicitações 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. Para saber mais sobre as práticas recomendadas, consulte Práticas recomendadas para dimensionamento da taxa de transferência provisionada (RU/s).

Nem sempre é o caso de você ver um erro de limitação 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 uma gama de chaves de partição, provoca um breve pico na métrica de consumo de RU normalizada. Nesses casos, não há 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.

Para saber mais, consulte Diagnosticar e solucionar problemas de exceções 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 uma partição quente

Para verificar se há uma partição ativa, navegue até 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 maior consumo de RU normalizado 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 consomem mais RU/s, consulte Como identificar a partição quente.

Consumo normalizado de RU e dimensionamento automático

A métrica de consumo de RU normalizada é mostrada como 100% se pelo menos um 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 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.

Agora digamos que você tenha um pico intermitente de tráfego:

Por um segundo, a Partição 1 aumenta para 10.000 RU/s e, em seguida, cai para 1.000 RU/s pelos próximos quatro segundos.

Simultaneamente, a Partição 2 aumenta para 8.000 RU/s; em seguida, cai para 1.000 RU/s nos quatro segundos seguintes.

É assim que as métricas se comportam:

O Consumo Normalizado de RU (que mostra o uso máximo ao longo do intervalo em todas as partições) mostra 100% de utilização, porque a Partição 1 atingiu o máximo por um segundo.

No entanto, a taxa de transferência provisionada e as métricas de RU dimensionadas automaticamente não são dimensionadas para o máximo de RU/s apenas por causa de um pico de 1 segundo. Ele é dimensionado com base em um intervalo de 5 segundos para ser econômico. Assim, para o exemplo anterior, o consumo de RU da partição 1 e da partição 2 não atinge 10.000 RU/s com base no intervalo de 5 segundos.

Como resultado, mesmo que o dimensionamento automático não tenha dimensionado ao máximo, você ainda conseguiu utilizar o total de RU/s disponível para esse segundo de pico. Para verificar o consumo de RU/s, pode utilizar a funcionalidade de Logs de diagnóstico para consultar o consumo geral de RU/s ao nível de 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% de 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 , escolha a assinatura>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

• Monitorar dados do Azure Cosmos DB usando as configurações de diagnóstico do Azure Monitor Log Analytics
• Como 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)