Consultas comuns do SLS para solução de problemas - ApsaraMQ for RabbitMQ: Central de Documentação do Alibaba Cloud

Este tópico apresenta consultas comuns do Simple Log Service (SLS) para solucionar problemas no ApsaraMQ for RabbitMQ, como falhas na entrega de mensagens, erros de consumo e acúmulos de mensagens.

Pré-requisitos

Você ativou o recurso de gerenciamento de logs e configurou índices.

Consultas comuns

Localizar endereços IP de produtores por exchange
Localizar endereços IP de consumidores por fila
Rastrear uma mensagem
Analisar taxas de consumo da fila
Consultar mensagens de dead-letter

Este tópico lista consultas comuns do Simple Log Service (SLS). Para obter etapas detalhadas e descrições do formato de log, consulte gerenciamento de logs.

Localizar endereços IP de produtores por exchange

Execute a consulta a seguir para listar os endereços IP dos produtores.

* and Action : SendMessage and Code : 200 | 
select 
  split_part(ResourceName,',',2) as exchange_name, 
  split_part(ResourceName, ',', 3) as routing_key, 
  RemoteAddress as ip_port, 
  count(*) as total_send_num 
group by 
  exchange_name, routing_key, ip_port 
order by 
  total_send_num DESC 
limit 1000000

Localizar endereços IP de consumidores por fila

Execute a consulta a seguir para listar os endereços IP dos consumidores.

* and Action : PushMessage and Code : 200 | 
select 
  InstanceId as instance_id,
  VHost as virtual_host, 
  Queue as queue_name, 
  RemoteAddress as ip_port, 
  count(*) as push_total_num 
group by 
  instance_id,virtual_host, ip_port, queue_name 
order by 
  push_total_num DESC
limit 10000000

Rastrear uma mensagem

Execute uma consulta na caixa de pesquisa para rastrear uma mensagem.

Rastreie uma mensagem pelo ID da mensagem
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:cycle**** and ResourceName:msgId=27127757-44dc-4373-afc5-f8ea12f****
```
A consulta retorna duas entradas de log: uma com Action SendMessage (Code: 200) e outra com Action PushMessage (Code: 200). Isso indica que a mensagem foi enviada e entregue com sucesso.

Quando um cliente se inscreve usando BasicConsume, é possível rastrear a mensagem desde o envio até a entrega pelo servidor. Uma ação SendMessage corresponde à chamada BasicPublish do cliente, e uma ação PushMessage corresponde ao servidor entregando a mensagem ao cliente. Se o cliente buscar a mensagem usando BasicGet, o Action será BasicGet em vez de PushMessage.
Nota
- Se os resultados do log contiverem apenas uma entrada SendMessage, mas múltiplas entradas PushMessage or BasicGet, o cliente pode não ter confirmado a mensagem chamando BasicAck dentro do consumption timeout após o primeiro PushMessage or BasicGet. Isso faz com que o servidor considere o consumo como falho e reentregue a mensagem. Para mais informações sobre o tempo limite de consumo, consulte Descrição do parâmetro da política de nova tentativa da instância.
- Caso os resultados do log contenham logs SendDlqMessage além de SendMessage e PushMessage, um log SendDlqMessage indica que a mensagem atual foi movida para a fila de dead-letter.
Verifique se uma mensagem foi consumida
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:cycle**** and Queue:cycleCheckQueue**** and ConnectionId:00163efffe08281f-00004e11-0009732f-799c0af9bc4e4913-96b3**** and  ChannelId:1 and (ResourceName:deliveryTag=90 or Property:deliveryTag=90) and RemoteAddress:"/192.168.XX.XX:XXXX"            
```
Obtenha os valores para ConnectionId, ChannelId, deliveryTag e RemoteAddress nos logs de PushMessage. O RemoteAddress é o endereço IP do cliente. O ConnectionId é o identificador exclusivo da conexão. O ChannelId é o identificador exclusivo do canal. A deliveryTag é o identificador exclusivo da mensagem no servidor. Uma entrada de log DeleteMessage indica que a mensagem foi consumida com sucesso pelo cliente.

A consulta retorna três entradas de log. Os valores de Action incluem DeleteMessage e BasicAck, e o Code de cada um é 200. Isso indica que a mensagem foi consumida com sucesso.
Nota
Se um cliente definir autoAck=false ao chamar BasicConsume, ele deverá chamar BasicAck para confirmar que a mensagem foi consumida. Em seguida, o servidor exclui a mensagem. A chamada BasicAck deve ocorrer dentro do período de tempo limite de consumo, que começa a partir do timestamp de PushMessage. Se o período de tempo limite for excedido, o servidor considera o consumo como falho e reentrega a mensagem ao cliente. Para mais informações, consulte Descrição do parâmetro da política de nova tentativa da instância.
- Se o cliente chamou BasicAck, mas uma consulta sobre o status de consumo da mensagem não retornar uma entrada de log DeleteMessage, o consumo falhou. Verifique a diferença de tempo entre as entradas PushMessage e BasicAck. Se a diferença for maior que o tempo limite de consumo, a chamada BasicAck é inválida.
- Caso você encontre apenas entradas PushMessage e DeleteMessage, mas nenhuma entrada BasicAck, o cliente pode ter usado BasicAck(deliveryTag, multiple=true) para confirmar todas as mensagens anteriores até a deliveryTag especificada em uma única chamada.

Analisar taxas de consumo da fila

Execute a consulta a seguir para verificar a distribuição das ações SendMessage, PushMessage or BasicGet, BasicAck e DeleteMessage. Se as porcentagens dessas quatro ações forem aproximadamente iguais, as taxas de produção e consumo estão equilibradas, com pouco ou nenhum acúmulo de mensagens.

InstanceId:amqp-cn-i7m29o3s**** and Vhost:cycle**** and Queue: cycleCheckQueue**** and (SendMessage or PushMessage or BasicAck  or DeleteMessage)

No painel Quick Analysis, no lado esquerdo da página de resultados da consulta, visualize a distribuição do campo Action. Por exemplo, a distribuição pode ser BasicAck 25%, DeleteMessage 25%, PushMessage 25% e SendMessage 24%.

Se você observar qualquer um dos padrões a seguir nos logs, analise a causa provável:

Ausência de entradas DeleteMessage nos resultados do log: Isso pode ocorrer se o cliente definiu autoAck=true ao chamar BasicConsume ou BasicGet. Alternativamente, todas as solicitações BasicAck do cliente podem ter excedido o tempo limite de consumo, tornando as chamadas inválidas. Para mais informações sobre o tempo limite de consumo, consulte Descrição do parâmetro da política de nova tentativa da instância.
A porcentagem de entradas PushMessage é muito menor que a de entradas SendMessage: Isso pode indicar assinantes insuficientes. Recomendamos adicionar mais conexões e criar novos consumidores.
As porcentagens de entradas SendMessage e PushMessage são semelhantes, mas a porcentagem de entradas DeleteMessage é muito menor: Muitas solicitações BasicAck podem ter excedido o tempo limite de consumo e se tornado inválidas. Para mais informações sobre o tempo limite de consumo, consulte Descrição do parâmetro da política de nova tentativa da instância.
As porcentagens de entradas SendMessage, PushMessage e DeleteMessage são aproximadamente iguais, mas a porcentagem de entradas BasicAck é muito menor: Verifique se o seu código usa BasicAck(multiple=true).

Consultar mensagens de dead-letter

Na caixa de pesquisa de logs, insira uma consulta para recuperar as mensagens relevantes.

Mensagem roteada para uma fila de dead-letter devido à expiração do TTL da mensagem
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and ResourceName:msgId=02a162ba-f842-440f-bfd4-2595dd19****
```
A consulta retorna duas entradas de log. O campo Code de ambas é 200, o que indica que as operações da mensagem foram bem-sucedidas.

Uma entrada SendMessage corresponde à sua chamada BasicPublish para enviar a mensagem. Uma entrada SendDlqMessage indica que a mensagem foi enviada para a fila de dead-letter correspondente após a expiração do seu TTL.

Nota
Esta entrada de log é gerada apenas se você tiver configurado uma fila de dead-letter.
Mensagem roteada para uma fila de dead-letter devido à expiração do TTL da fila
1. Defina as propriedades de dead-letter e o TTL para a fila.
```
Map<String, Object> argument = new HashMap<>();
argument.put("x-dead-letter-exchange", [exchangeName]);
argument.put("x-dead-letter-routing-key", [routingKey]);
argument.put("x-message-ttl", [ttl]);
channel.queueDeclare([queueName], true, false, false, argument);
```
2. Insira a consulta a seguir na caixa de pesquisa de logs para recuperar entradas SendMessage e SendDlqMessage.
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and ResourceName:msgId=034a75c5-d957-422f-822e-72dfad2a****
```
  A consulta retorna duas entradas de log: uma ação SendDlqMessage para a fila a e uma ação SendMessage para a fila b. Ambas têm Code 200. No painel Quick Analysis à esquerda, a distribuição do campo Action mostra 50% SendMessage e 50% SendDlqMessage.
Chame BasicReject ou BasicNack com requeue=false
```
InstanceId:amqp-cn-i7m29o3s**** and VHost:dlq**** and (ResourceName:msgId=034a75c5-d957-422f-822e-72dfad2a**** or ResourceName:deliveryTag=1)
```
Uma entrada de log PushMessage indica que o servidor entregou uma mensagem ao cliente. Após receber a mensagem, o cliente chama BasicReject(requeue=false). A entrada de log SendDlqMessage correspondente indica que a mensagem foi roteada para a fila de dead-letter.

A consulta retorna três entradas de log com as seguintes ações: PushMessage (Code: 200), BasicReject (Code: 200) e SendDlqMessage (Code: 200).