Sidekiq

Sidekiq é um processador de background simples e eficiente para Ruby. É também o processador que usamos para processar jobs no AppSignal. Quando o AppSignal detecta métricas do Sidekiq, ele criará um Intelligence dashboard, permitindo que você monitore métricas principais visualmente.

Monitoramento Sidekiq para apps Ruby on Rails

A gem AppSignal Ruby insere automaticamente um listener na pilha de middleware do servidor Sidekiq se o módulo Sidekiq estiver presente, caso você use Rails. Nenhuma ação adicional é necessária. A integração com o Sidekiq é compatível com Active Job.

Monitoramento Sidekiq para apps Ruby

Adicionar esta config só deve ser necessário quando o Sidekiq não carrega o AppSignal automaticamente pelo framework do app, como o Rails. Adicione este snippet à sua config do Sidekiq com o ambiente e o nome corretos:

require 'appsignal'

Sidekiq.configure_server do |config|
  config.on(:startup) do
    # Inicia o AppSignal
    Appsignal.start
  end

  config.on(:shutdown) do
    # Para o agent
    Appsignal.stop('Sidekiq shutdown')
  end
end

Performance monitoring

Uma vez que o AppSignal comece a reportar métricas do Sidekiq, ele fornecerá insights de performance via:

Linha do tempo do trace
Error tracking
Incident grouping
Detalhamento do trace

Linha do tempo do trace

Spans perform_job.sidekiq aparecem na linha do tempo do trace na página de trace:

Error tracking

Rastreie exceptions que ocorrem ao executar jobs do Sidekiq. Quando o Sidekiq encontra um problema antes ou depois de um job ter sido processado, como ao fazer parse de JSON do Redis, ele gerará um erro. Esse erro é reportado sob a action SidekiqInternal no namespace background, pois o contexto do job é desconhecido quando o erro ocorre.

Reportar erros ao descartar job

Defina a opção de configuração sidekiq_report_errors como discard para reportar erros apenas quando um job é descartado. Quando um job é descartado, todas as tentativas de retry do job foram esgotadas, e o job não é mais executado novamente. Leia a documentação do Sidekiq para saber mais sobre o tratamento de exceptions do Sidekiq e retries de jobs com falha.

Ao usar o Sidekiq com o sistema de retry do Active Job, configure-o para reportar erros apenas no discard, para que ele não reporte erros várias vezes.Após o esgotamento dos retries do Active Job, o sistema de retry do Sidekiq irá assumir. Desabilite o sistema de retry do Sidekiq se este for um comportamento indesejado.

Incident grouping

Os nomes dos jobs são detectados automaticamente com base no nome da classe do worker Sidekiq e sufixados com o nome do método perform, resultando em algo como: MyWorker#perform.

Jobs do Sidekiq agrupados pelo nome da classe do worker na página Performance

Detalhamento do trace

O detalhamento do trace em uma página de trace mostra como o tempo de um job foi dividido entre grupos de eventos, como sidekiq e active_record, para que você identifique problemas de performance sem precisar ler a linha do tempo inteira.

Enqueue instrumentation

Enfileirar um job do Sidekiq registra um event enqueue.sidekiq, com o título baseado no job sendo enfileirado. O AppSignal registra events de enqueue na event timeline da transaction ativa, por exemplo, quando você enfileira um job a partir de uma requisição web ou de dentro de outro job. Ele só registra esses events quando uma transaction está ativa, então enfileirar um job fora de uma transaction não registra nada. Para parar de registrar events de enqueue em todas as integrações de background job, defina a opção de configuração enable_job_enqueue_instrumentation como false. Isso não afeta a instrumentação dos jobs em si.

Intelligence dashboard

Quando o AppSignal recebe métricas do Sidekiq, ele criará um Intelligence dashboard do Sidekiq, disponível na seção de dashboard do app AppSignal. O Intelligence dashboard do Sidekiq terá os seguintes gráficos:

Gráfico	Métricas	Tags
Connection count	`sidekiq_connection_count`	`hostname`
Duration per worker	`trace_duration`	`action` `namespace`
Job status per queue	`sidekiq_queue_job_count`	`status` `queue`
Overall job status	`sidekiq_job_count`	`status` `hostname`
Queue latency	`sidekiq_queue_latency`	`hostname` `queue`
Queue length	`sidekiq_queue_length`	`hostname` `queue`
Redis memory usage	`sidekiq_memory_usage` `sidekiq_memory_usage_rss`	`hostname`
Throughput per worker	`trace_duration`	`action` `namespace`
Worker/processes count	`sidekiq_worker_count` `sidekiq_process_count`	`hostname`

Os gráficos Duration per worker e Throughput per worker usam trace_duration para contas que migraram para as métricas de trace. Para contas que ainda não migraram, esses gráficos usam transaction_duration.

As tags fornecem um detalhamento contextual das informações de performance do Sidekiq. O AppSignal reporta as seguintes tags para jobs do Sidekiq:

Nome	Descrição
`action`	O nome da action da qual a métrica foi reportada (por exemplo, `YourWorker#perform`).
`hostname`	O hostname do servidor Redis que o Sidekiq usa, ou o valor de `hostname` definido na config do probe.
`namespace`	O nome do namespace do qual a métrica foi reportada.
`queue`	Fila nomeada na qual os jobs são processados, por exemplo, `default` ou `mailer`.
`status`	Status de cada job. Para Job status per queue: `processed` ou `failed`. Para Overall job status: `processed`, `failed`, `retry_queue`, `died`, `scheduled` ou `enqueued`. Jobs que são `failed` também são contados como `processed`.

Cada tag será representada com uma linha colorida no gráfico:

Gráfico Connection count

O gráfico Connection count mostra o número de clientes conectados ao servidor Redis usado pelo Sidekiq, por host Redis. Você pode usar o gráfico Connection count para identificar tendências e gargalos de conexão e otimizar recursos.

Gráfico Duration per worker

O gráfico Duration per worker mostra a quantidade de tempo que os jobs levaram para executar, agrupados por namespace e action. Você pode usar o gráfico Duration per worker para monitorar a performance dos workers por action e namespace, dando a você uma visão geral da performance do Sidekiq e permitindo identificar e investigar rapidamente picos no tempo de duração.

Gráfico Job status per queue

O gráfico job status per queue com uma prioridade mostra o número de jobs que foram executados, agrupados por seu status resultante, pela fila na qual foram enfileirados. Você pode usar o gráfico Job status per queue para monitorar contagens de erros e performance dos jobs com base na fila, identificar gargalos e otimizar seus background jobs para escalabilidade.

Gráfico Overall job status

O gráfico Overall job status mostra o número de jobs do Sidekiq por status e host Redis. Você pode usar o gráfico Overall job status para monitorar jobs com falha, mortos, em nova tentativa, agendados e enfileirados.

Gráfico Queue latency

O gráfico Queue latency mostra a latência que a fila experimentou no momento da medição. O Sidekiq calcula isso como o tempo desde que o job mais antigo da fila foi enfileirado. Este valor é reportado em milissegundos. Você pode usar o gráfico Queue latency para identificar atrasos no processamento de jobs, detectar congestionamento da fila e entender com que rapidez os background jobs iniciam.

Gráfico Queue length

O gráfico Queue length mostra o comprimento das filas do Sidekiq por fila e host Redis. Você pode usar o gráfico Queue length para monitorar a performance da fila e identificar e resolver gargalos do Sidekiq.

Gráfico Redis memory usage

O gráfico Redis memory usage mostra:

O uso de memória Virtual Memory Size do Redis (sidekiq_memory_usage_rss)
O uso de memória Resident Set Size do Redis (sidekiq_memory_usage_rss)

Você pode usar o gráfico Redis memory usage para monitorar o uso de memória do Sidekiq, melhorar o gerenciamento de recursos e otimizar jobs intensivos em memória.

Gráfico Throughput per worker

O gráfico Throughput per worker mostra o número de jobs que foram executados, agrupados por namespace e action. Você pode usar este gráfico para ver quantos jobs cada classe de worker processa e identificar workers cujo volume muda de forma inesperada.

Gráfico Worker/processes count

O gráfico Worker/processes count mostra o número de workers e processos executados do Sidekiq. Você pode usar o gráfico Worker/processes count para gerenciar a distribuição de carga de trabalho, otimizar a alocação de recursos e identificar problemas de performance.

Configuração de hostname

O AppSignal tenta detectar o hostname da instância Redis que sua instância Sidekiq usa para armazenar suas filas. Se a detecção não for precisa, é possível personalizar a configuração do hostname sobrescrevendo o probe Sidekiq padrão. Primeiro, você precisará sobrescrever o probe Sidekiq padrão registrando um novo probe com o mesmo nome (:sidekiq). Este probe precisará de um hash de configuração, incluindo a chave :hostname, com o novo valor do hostname. Ao especificar a opção de configuração :hostname no minutely probe do Sidekiq, as métricas serão marcadas com o valor de hostname fornecido. O valor da opção de configuração :hostname não é usado para estabelecer uma conexão Redis ou Sidekiq. Por exemplo:

# config/initializers/appsignal.rb ou um arquivo que é carregado no boot

# Gem Ruby 2.11.0 e mais nova
Appsignal::Minutely.probes.register(
  :sidekiq, # Use a mesma chave que o probe Sidekiq padrão para sobrescrevê-lo
  Appsignal::Probes::SidekiqProbe.new(:hostname => "my_sidekiq_hostname")
)

# Gem Ruby 2.10.x e mais antiga
Appsignal::Minutely.probes.register(
  :sidekiq, # Use a mesma chave que o probe Sidekiq padrão para sobrescrevê-lo
  Appsignal::Hooks::SidekiqProbe.new(:hostname => "my_sidekiq_hostname")
)

Na versão 2.11.0 da gem Ruby, a constante SidekiqProbe foi movida para seu próprio módulo. Ao chamar a constante, um aviso será impresso e registrado. Atualize para o novo nome de constante Appsignal::Probes::SidekiqProbe para remover o aviso.

Atributos de span

Somente no modo collector: isso se aplica quando o AppSignal para Ruby é executado no modo collector. Nos demais casos, não tem efeito.

O enqueue e o span do próprio job carregam:

messaging.system — a biblioteca de filas.
messaging.destination.name — a fila na qual o job foi colocado.
messaging.operation.type — se o span é o enqueue ou a execução do job.

Um span de um job que gerou um erro também carrega error.type, a classe do erro.

Distributed tracing

Somente no modo collector: isso se aplica quando o AppSignal para Ruby é executado no modo collector. Nos demais casos, não tem efeito.

Um job roda no mesmo trace do código que o enfileirou. Ele aparece sob a requisição ou o job que o agendou, permitindo rastrear um job lento até o que causou sua execução. O trace é carregado no próprio job, junto com seus outros dados. Leia mais sobre distributed tracing.

Veja também

Batches do Sidekiq: execute jobs em paralelo e depois aja: divide uma unidade de trabalho entre vários jobs e executa um callback quando todos os jobs forem concluídos com sucesso. Explica por que o callback precisa da sua própria classe e como encadear um batch no próximo.

SDKs & telemetria

SDKs de linguagem

Ferramentas de telemetria

Monitoramento Sidekiq para apps Ruby on Rails

Monitoramento Sidekiq para apps Ruby