Como Detectar um Relay do Mastodon com Mau Comportamento que Inunda o Sidekiq

Relays do Mastodon distribuem postagens públicas entre instâncias, mas um relay mal configurado ou malicioso pode inundar sua fila do Sidekiq com milhares de jobs por minuto. Essa inundação desacelera ou interrompe completamente a federação, atualizações da linha do tempo local e entrega de e-mails. A causa raiz geralmente é um relay que envia muitas atividades ou as envia rápido demais para sua instância processar. Este artigo explica como identificar o relay ofensor, confirmar que ele está inundando o Sidekiq e tomar as medidas corretivas.

Por que um Relay Inunda o Sidekiq e Como Identificar

Um relay do Mastodon funciona assinando uma caixa de entrada compartilhada. Quando o relay recebe uma nova postagem pública de qualquer instância inscrita, ele encaminha essa postagem para todos os outros assinantes. Se o relay estiver mal configurado — por exemplo, tem um bug que faz com que reenvie a mesma postagem repetidamente, ou assina muitas instâncias e encaminha todas as postagens sem desduplicação — sua instância receberá um alto volume de jobs ActivityPub::ProcessingWorker e ActivityPub::DistributionWorker.

O primeiro sinal de uma inundação é um aumento repentino no tamanho da fila do Sidekiq. Você pode verificar isso acessando https://sua-instancia.example/sidekiq e observando a fila padrão. Uma fila saudável deve ter menos de 100 jobs pendentes durante a operação normal. Se você vir milhares ou dezenas de milhares de jobs, e todos estiverem relacionados a um único domínio de relay, esse relay é provavelmente a causa.

Outro indicador é a latência dos jobs. O Sidekiq mostra o tempo que o job pendente mais antigo está esperando. Se a latência exceder 30 segundos, sua instância está com dificuldade para acompanhar. Em casos extremos, a latência pode chegar a vários minutos ou até horas.

Passos para Identificar o Relay que Está Inundando

1. Abra o painel do Sidekiq
   Navegue até https://sua-instancia.example/sidekiq e faça login com suas credenciais de administrador. Observe a fila padrão. Se o tamanho da fila estiver acima de 500 e crescendo, uma inundação está em andamento.
2. Verifique os argumentos dos jobs
   No painel do Sidekiq, clique na fila padrão para ver a lista de jobs pendentes. Cada job mostra seus argumentos, que incluem o ID da atividade e o domínio de origem. Procure por um domínio que apareça em muitos jobs — esse é o seu relay suspeito.
3. Inspecione a lista de relays no admin do Mastodon
   Vá para https://sua-instancia.example/admin/relays. Você verá todos os relays aos quais sua instância está inscrita. Observe a coluna last_activity_at. Um relay que está inundando mostrará um horário de última atividade muito recente — geralmente nos últimos segundos — mesmo que nenhuma nova postagem esteja sendo criada em sua instância.
4. Revise o log de auditoria da instância
   Navegue até https://sua-instancia.example/admin/action_logs. Filtre pelo tipo de ação relay. Procure por ações repetidas de ativação ou desativação. Um relay com mau comportamento pode ter sido alternado várias vezes enquanto os administradores tentavam corrigir a inundação.
5. Monitore os tipos de jobs no Sidekiq
   No painel do Sidekiq, clique na aba Busy para ver os workers em execução no momento. Se a maioria dos workers estiver executando ActivityPub::ProcessingWorker ou ActivityPub::DistributionWorker com o mesmo domínio de relay nos argumentos, isso confirma a fonte da inundação.

Se o Mastodon Ainda Tiver Problemas Após Identificar o Relay

A fila continua crescendo após desativar o relay

Se você desativou o relay, mas a fila continua crescendo, a inundação pode já ter enfileirado milhares de jobs antes da desativação. Esses jobs ainda serão processados. Para limpá-los, você pode reiniciar o Sidekiq ou usar a API do Sidekiq para excluir jobs da fila. No painel do Sidekiq, clique em Queues e depois no ícone de exclusão ao lado da fila padrão. Isso remove todos os jobs pendentes sem processá-los.

Relay se reativa sozinho após ser desativado

Alguns scripts de gerenciamento de relay de terceiros ou cron jobs podem reativar um relay automaticamente. Verifique seu crontab do servidor e quaisquer scripts personalizados que interajam com a API do Mastodon. Também verifique se nenhum outro administrador reativou o relay. Use o log de auditoria para ver quem realizou a última ação de ativação.

Outros relays também começam a inundar após a remoção de um relay

Isso é raro, mas pode acontecer se o primeiro relay era um hub que encaminhava atividades de muitos outros relays. Quando você remove o hub, os relays restantes podem começar a enviar diretamente para sua instância. Nesse caso, considere limitar o número de relays aos quais sua instância se inscreve. A documentação do Mastodon recomenda inscrever-se em no máximo três relays para uma instância de médio porte.

Relay do Mastodon vs Federação Direta: Comparação de Carga no Sidekiq

Item	Assinatura de Relay	Federação Direta
Tipo de job	ActivityPub::ProcessingWorker para cada postagem encaminhada	ActivityPub::ProcessingWorker apenas para postagens de contas seguidas
Volume de jobs por minuto	100–5000+ dependendo do tamanho do relay	1–50 para uma instância típica de usuário único
Controle sobre o conteúdo	Nenhum — o relay encaminha tudo	Total — você segue apenas as contas que escolher
Risco de inundação	Alto — um único relay mal configurado pode sobrecarregar o Sidekiq	Baixo — cada conta seguida tem limites de taxa

A federação direta oferece controle granular sobre quais postagens entram em sua instância. Relays são convenientes para descobrir novos conteúdos, mas exigem monitoramento ativo. Se você administra uma instância pequena, considere desativar todos os relays e confiar em seguidores diretos e descoberta local.

Agora você pode detectar um relay do Mastodon com mau comportamento monitorando o painel do Sidekiq, verificando os argumentos dos jobs e revisando a lista de relays no painel administrativo. O próximo passo é desativar o relay ofensor e limpar quaisquer jobs enfileirados usando a interface do Sidekiq. Para proteção contínua, configure um cron job que verifique o tamanho da fila do Sidekiq a cada cinco minutos e alerte você se exceder 200 jobs pendentes.