Consulta com AliyunAMQPReadOnlyAccess
A política AliyunAMQPReadOnlyAccess concede apenas as permissões amqp:Get* e amqp:List*. Para acessar mensagens em uma fila, adicione a permissão personalizada amqp:BasicGet. Para mais informações, consulte Referência de políticas personalizadas do ApsaraMQ for RabbitMQ.
Acúmulo de mensagens após limpar uma fila
A operação de limpeza não remove mensagens atrasadas por padrão.
Mecanismo de QoS
Se você enfrentar timeouts ou bloqueios, defina o QoS ou Prefetch Count como 1. Isso impede que o cliente armazene em cache muitas mensagens que podem expirar simultaneamente.
Entrega de mensagens na fila dead-letter
Uma mensagem sem valor de TTL é enviada para a fila dead-letter apenas se receber uma confirmação negativa (NACK) ou se a contagem de tentativas atingir o limite máximo.
Definição de um ID de mensagem
Para mais informações, consulte Como definir um ID de mensagem.
Diminuição da contagem de mensagens em filas dead-letter
O ApsaraMQ for RabbitMQ retém mensagens por no máximo 3 dias. Se uma mensagem não for consumida dentro desse período, ela será excluída automaticamente da fila dead-letter, o que reduz a contagem de mensagens. Para mais informações, consulte Limites.
Período de retenção de mensagens
O ApsaraMQ for RabbitMQ retém todas as mensagens por no máximo 3 dias, independentemente de terem sido consumidas. Para mais informações, consulte Limites.
Segmentos de rede do RabbitMQ
Os segmentos de rede das instâncias do ApsaraMQ for RabbitMQ não são fixos, portanto, não é possível obter essas informações antecipadamente.
Problemas com exclusão automática de filas
Se um consumidor não tiver se inscrito com sucesso em uma fila, a chamada de channel.close não aciona a exclusão automática da fila. A lógica de exclusão automática só entra em vigor depois que um consumidor se inscreve com sucesso usando channel.basicConsume.
Taxas de armazenamento
O ApsaraMQ for RabbitMQ retém mensagens por 3 dias. A taxa de armazenamento é calculada com base no volume de armazenamento dos corpos das mensagens. Não é possível limpar esse espaço manualmente; ele só é liberado quando as mensagens expiram.
Como a limpeza não exclui mensagens, ela não reduz o uso do seu espaço de armazenamento.
Limpeza de uma fila
Limpar uma fila redefine o offset do consumidor, fazendo com que os consumidores ignorem mensagens não consumidas. A operação não exclui as mensagens, que permanecem acessíveis.
Fatores que determinam a taxa de saída da fila
A taxa de entrega de mensagens de uma fila depende do volume de mensagens, do número de consumidores e das configurações de QoS deles.
Considerações para filas exclusivas
Ao usar o framework Spring no modo CONNECTION, crie o exchange, a fila e as bindings no console antecipadamente. O modo CONNECTION não declara nem cria esses recursos automaticamente.
Faturamento para tentativas de mensagem
Você é cobrado apenas uma vez pela entrega inicial. Tentativas subsequentes de reenfileiramento e consumo não geram cobranças adicionais.
O reenfileiramento ocorre quando um consumidor falha ao processar uma mensagem e ela é devolvida a uma fila do servidor. O servidor usa uma fila de tentativas dedicada para reentregar a mensagem ao consumidor em intervalos específicos.
Métrica para limite de TPS
O limite de TPS corresponde à métrica Peak API Request Rate per Instance no CloudMonitor.
Exceder o limite de conexões
Embora o limite de conexões seja documentado como um limite no nível da instância, ele é aplicado no nível do nó de backend. Como resultado, o número total de conexões de uma instância pode exceder ligeiramente o limite declarado.
As configurações de instâncias de assinatura não podem ser ajustadas dinamicamente. Planeje seus recursos cuidadosamente ao criar uma instância para evitar a ultrapassagem de limites de recursos e interrupções nos negócios.
Acúmulo de mensagens com taxas equilibradas
Mesmo que as taxas de produção e consumo estejam equilibradas, atrasos na confirmação (ACK) de algumas mensagens podem fazer com que as ferramentas de monitoramento relatem um acúmulo temporário de mensagens em um momento específico de amostragem. O nível de acúmulo geralmente volta ao normal no próximo ciclo de amostragem.
Queda repentina na taxa de consumo do pod
Verifique o desempenho do pod. A alta utilização da CPU pode impedir que o cliente envie ACKs prontamente. Se o servidor não receber um ACK, ele não poderá enviar novas mensagens e precisará aguardar um timeout antes de tentar novamente. Isso leva a uma queda na taxa de consumo.
Por exemplo, se o QoS estiver definido como 1, o consumidor poderá ter apenas uma mensagem não confirmada por vez. O servidor deve aguardar o consumidor processar a mensagem e enviar um ACK antes de poder enviar a próxima mensagem. Se nenhum ACK for recebido, o servidor deverá aguardar um timeout antes de tentar novamente.
Se um consumidor voltar a consumir por um curto período após uma reinicialização e depois parar de consumir novamente, a causa raiz é a mesma da queda na taxa de consumo do pod descrita acima. Em ambos os casos, uma falha de ACK faz com que o servidor pare de enviar mensagens. Verifique os dois cenários a seguir:
ACKs não são enviados corretamente: Uma lógica anormal no código do consumidor impede que um ACK seja enviado com sucesso. Como resultado, a mensagem permanece no estado pendente, o que aciona o limitador de QoS e faz com que o servidor pare de enviar novas mensagens. Verifique a lógica de envio de ACK no código do consumidor e certifique-se de que o consumidor envia um ACK após terminar de processar uma mensagem.
A lógica de negócios está bloqueada: O consumidor demora muito para processar uma mensagem ou a lógica de negócios trava, impedindo o envio de um ACK a tempo. Após o timeout do servidor ao aguardar o ACK, ele para de enviar novas mensagens. Verifique se a lógica de negócios contém operações de longa duração, deadlocks ou outros bloqueios síncronos.
Se um consumidor parar de consumir novamente logo após uma reinicialização, ou se você vir mensagens pendentes, ACK não enviado ou lógica de negócios bloqueada em seus logs, use os dois cenários anteriores para solucionar o problema. Combine-os com as verificações de CPU e QoS descritas anteriormente nesta entrada.
Uso da chave mestra padrão
Sim.
Erro: "The channelMax limit is reached"
O servidor limita o número de canais por conexão, e não o número total de canais em todas as conexões.
Esse erro é registrado pelo SDK sempre que o método createChannel
retorna null.
Após atualizar uma instância, reinicie seus clientes. Caso contrário, as conexões existentes continuarão a usar o limite de canais anterior à atualização, fazendo com que o erro persista.
Por exemplo, se uma instância for adquirida com um Channel Max de 100, o cliente e o servidor negociam esse limite quando uma conexão é estabelecida. Se você atualizar a instância posteriormente para suportar 2.000 ou 2.500 canais, as conexões estabelecidas antes da atualização ainda estarão vinculadas ao limite original de 100 canais e continuarão a acionar o erro.
Processo de negociação de parâmetros de canal
Impacto da atualização de TPS
Não. A atualização do limite de TPS no console não interrompe nem desconecta as conexões existentes.
Novas conexões causando desligamento de canais
Normalmente, não. No entanto, recursos insuficientes do cliente, como largura de banda de rede, memória ou capacidade da JVM, podem causar a interrupção de outras conexões ou canais. Examine o uso de recursos do cliente para identificar contenção ou escassez de recursos que possam estar causando essas interrupções.
Consumidores de fila desaparecendo
Primeiro, verifique a lógica do aplicativo e o status dos recursos do cliente no momento do incidente. Procure problemas como processos suspensos ou escassez de recursos que possam ter interrompido o aplicativo. Se o cliente estiver funcionando corretamente, verifique se o servidor está entregando as mensagens conforme o esperado.
Limpeza de fila não surte efeito
Limpar uma fila não remove mensagens não confirmadas (unacked). Essas são mensagens que foram entregues a um cliente, mas ainda não foram confirmadas. A contagem de mensagens unacked é atualizada automaticamente após a expiração das mensagens.
Cálculo de TPS a partir de logs do cliente
Use a seguinte consulta SQL:
Resultado de exemplo:
Logs vazios após alterar o Logstore
No novo Logstore, clique em Enable Indexing. Aguarde cerca de um minuto, atualize a página e visualize os logs.
Procedimento:
1) Clique em Enable Indexing.
2) Clique em OK.
Causas de desconexões do RabbitMQ
Se um cliente enviar um número baixo de ACKs válidos, o servidor reentregará mensagens repetidamente por não receber confirmações. Isso pode levar a um acúmulo persistente de mensagens.
Esse acúmulo de mensagens no lado do cliente pode impedir que a conexão envie pacotes de heartbeat. Isso eventualmente aciona um erro Connection ALL_IDLE e uma desconexão. Primeiro, investigue por que o cliente está falhando ao enviar ACKs válidos.
Configurações de TTL
O TTL máximo é de 3 dias; qualquer configuração superior a 3 dias é ineficaz. Se o TTL for ineficaz, as mensagens expiradas não serão movidas para a fila dead-letter e poderão causar outros comportamentos inesperados.
1) Se nenhum TTL estiver definido, todas as mensagens na fila serão mensagens normais. A métrica readyMessage no monitoramento reflete o número real de mensagens acumuladas.
2) Se um TTL estiver definido, a métrica readyMessage representa o número de mensagens ativas:
a) Se o TTL estiver funcionando corretamente, o número de mensagens ativas será calculado dinamicamente com base no TTL. A métrica readyMessage reflete esse número com precisão.
b) Se o TTL estiver definido, mas não for eficaz, o número de mensagens ativas será sempre 0. A métrica readyMessage também mostra 0 e não reflete o acúmulo real de mensagens.
Erro: "java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768"
Esse erro indica que o cabeçalho da mensagem excedeu o limite de tamanho do quadro. O limite padrão para um cabeçalho de mensagem é de 32 KB e não pode ser alterado no servidor.
Para evitar esse erro, mova dados grandes do cabeçalho da mensagem para o corpo da mensagem.
Localização de mensagens após a limpeza de uma fila
A função de pesquisa de mensagens consulta dados de log, e não a fila ativa. Como os logs são retidos por mais tempo, você pode encontrar registros de mensagens mesmo depois que elas forem limpas da fila.
Erro de desvinculação de assinatura
Causa:
Uma fila exclusiva é visível apenas para a conexão que a declarou primeiro. Portanto, ela só pode ser excluída por essa conexão específica, e não pelo console.
Para mais informações, consulte Filas exclusivas.
Solução:
1) Se você não precisar mais da fila exclusiva, desconecte a conexão correspondente. A fila e suas bindings serão excluídas automaticamente.
2) Se não conseguir encontrar o ID da conexão que criou a fila, exclua a fila exclusiva reiniciando o cliente.
Erro: "VPC flow is not allowed to login in"
Causa:
O servidor detecta que as credenciais usadas não são credenciais estáticas geradas no console. Ele interpreta incorretamente a solicitação como tráfego de autenticação de código aberto e rejeita a conexão.
Solução:
Após confirmar a conectividade da sua VPC, certifique-se de estar usando as credenciais estáticas geradas no console. Se não tiver certeza, regenere as credenciais.
A criação da instância leva mais de 30 minutos
Etapas de solução de problemas:
Verifique se a VPC especificada durante a criação da instância existe, pertence à sua conta (UID) e está no estado Available.
Verifique se o vSwitch especificado durante a criação da instância atende aos requisitos. Consulte o parâmetro VswitchIds da API CreateInstance.
Causa:
Esse problema geralmente ocorre quando a configuração da VPC ou do vSwitch muda durante o processo de criação da instância. Por exemplo, se a VPC for excluída após a validação da solicitação inicial ser aprovada, a criação assíncrona da instância falhará.
Solução:
Se os parâmetros de criação mudaram durante o processo (por exemplo, a VPC ou o vSwitch foi excluído), libere a instância do ApsaraMQ for RabbitMQ e crie uma nova.
Acesso à rede privada entre regiões
A solução padrão para acesso à rede privada entre regiões é usar uma combinação de PrivateLink e Cloud Enterprise Network (CEN).
Observe que essa solução incorre em taxas do PrivateLink. Para mais informações, consulte Endpoints do PrivateLink.
Erro ao criar endpoint do PrivateLink: parâmetro VPC
Causa:
O ID da VPC não existe ou a VPC não está no estado Available.
Solução:
Verifique se a Virtual Private Cloud (VPC) selecionada existe e está no estado "Available". Você pode verificar o status da VPC no console de VPC.
Erro ao criar endpoint do PrivateLink: parâmetro VSwitch
Causa:
O vSwitch selecionado não atende a uma ou mais das seguintes condições:
Selecione vSwitches de pelo menos duas zonas diferentes (isso não se aplica a algumas regiões de zona única).
O vSwitch deve pertencer à VPC selecionada.
O vSwitch deve estar no estado Available.
O vSwitch deve ter pelo menos 20 endereços IP disponíveis.
A zona onde o vSwitch reside deve suportar a criação de NLB.
Solução:
Verifique o número de vSwitches: para regiões de zona única (como Wuhan-Local, Southeast Asia 6, Southeast Asia 7, NE 2 e MEA 1), selecione pelo menos um vSwitch. Para outras regiões, selecione vSwitches de pelo menos duas zonas diferentes.
Certifique-se de que o vSwitch pertence à VPC selecionada e está no estado Available.
Certifique-se de que o vSwitch tem pelo menos 20 endereços IP disponíveis.
Certifique-se de que a zona onde o vSwitch reside suporta a criação de NLB.
Erro ao criar endpoint do PrivateLink: parâmetro SecurityGroup
Causa:
O grupo de segurança selecionado não atende a uma ou mais das seguintes condições:
O grupo de segurança deve ter uma regra de entrada que permita tráfego TCP nas portas de destino 5672 e 5671.
Grupos de segurança gerenciados não são suportados.
O grupo de segurança deve pertencer à VPC selecionada.
O número de grupos de segurança não deve exceder a cota da sua conta.
Solução:
Certifique-se de que o grupo de segurança tenha uma regra de entrada que permita tráfego TCP nas portas de destino 5672 e 5671.
Certifique-se de não ter selecionado um grupo de segurança gerenciado.
Certifique-se de que o grupo de segurança pertence à VPC selecionada.
Erro: service PrivateLink não ativado
Causa:
O service PrivateLink não está ativado para a sua conta.
Solução:
ative o service PrivateLink e tente criar o endpoint do PrivateLink novamente. Para mais informações, consulte O que é o PrivateLink?.
O que causa IOException ou erro de conexão no cliente?
Os seguintes fatores podem causar IOException ou erro de conexão:
Problemas de rede
Instabilidade ou interrupções de rede entre o cliente e o servidor podem causar a queda da conexão.
Problemas de ALL_IDEL
O ALL_IDEL pode ocorrer por vários motivos:
Interrupções de SDK: o SDK usado pelo cliente parou de enviar pacotes de heartbeat para o servidor.
Threads de consumidor bloqueadas: se a thread do consumidor estiver bloqueada, o buffer TCP será preenchido com mensagens do servidor. O cliente não consegue enviar pacotes de heartbeat.
Picos de tráfego em uma única conexão com múltiplos canais: vários canais em uma única conexão enviam mensagens simultaneamente e causam um aumento no tráfego TCP. Se combinado com pacotes do servidor, o Linux Netfilter Conntrack pode ficar INVALID. Isso fará com que o cliente reinicie a conexão.
Verifique:
Se o mecanismo de heartbeat do cliente está ativado;
Se as threads do consumidor não estão bloqueadas, como por exemplo, excesso de lógica de consumo ou bloqueios de BasicAck causados por operações síncronas.
Se o cliente está enviando heartbeats ou conexões RST. Use o tcpdump para obter pacotes locais e verificar as conexões do cliente e do servidor.