O Puma foi construído para velocidade e paralelismo. O Puma é uma pequena biblioteca que fornece um servidor HTTP 1.1 rápido e concorrente para aplicações web Ruby.
A gem AppSignal Ruby insere automaticamente um listener no servidor Puma; nenhuma configuração manual é necessária.
Plugin de métricas do Puma
O plugin do AppSignal para o Puma irá coletar métricas sobre como o Puma está operando. Quando o AppSignal detecta métricas do Puma, ele criará um Magic Dashboard, permitindo que você monitore métricas principais visualmente.
Para habilitar a coleta de métricas, adicione o plugin AppSignal à sua configuração do Puma:
# puma.rb (ou config/puma.rb)
plugin :appsignal
O servidor StatsD incluído no AppSignal Agent deve estar ativo para que o
plugin de métricas do Puma funcione. Certifique-se de que a opção de
configuração enable_statsd
não esteja definida como false. puma.rb inclui prune_bundler, você deve adicionar o AppSignal como uma dependência de runtime.
Para usar o Puma com prune_bundler, é necessária a versão 4.2.0 ou superior do Puma.
# puma.rb (ou config/puma.rb)
prune_bundler
plugin :appsignal
extra_runtime_dependencies ["appsignal"]
puma.rb inclui preload_app!, alguma configuração é necessária para reportar corretamente as métricas dos minutely probes. Quando preload_app! é true, os minutely probes são executados no processo primary do Puma. No processo primary, os probes não conseguem acessar os mesmos dados que o app rodando nos workers do Puma pode, reportando dados imprecisos ou nenhum dado.
No arquivo de configuração puma.rb do Puma, pare os minutely probes do AppSignal no callback before_fork para parar os minutely probes no processo principal do Puma. Em seguida, inicie os minutely probes no processo worker a partir do callback on_worker_boot.
# puma.rb ou config/puma.rb
# Quando preload_app! está definido
preload_app!
# Adicione este callback before_fork para parar os minutely probes no processo principal do Puma
before_fork do
Appsignal::Probes.stop
end
# Adicione este callback on_worker_boot para iniciar os minutely probes nos processos worker do Puma
on_worker_boot do
Appsignal::Probes.start
end
Secrets
Se você usa uma biblioteca como Rails ou dotenv para gerenciar os secrets do seu app e configurar o AppSignal, você precisará carregá-los na sua configuração do Puma.
O AppSignal executa um processo em background no processo principal do Puma quando se usa o plugin do Puma. O resto do seu app não é carregado por padrão no processo principal do Puma (a menos que você use preload_app!, que pode não ser adequado para o seu app). Sem configuração adicional, a config do AppSignal falhará ao carregar, e o AppSignal não iniciará.
Nenhum hook “on boot” está disponível no Puma para carregar sua configuração extra no processo principal. Para carregar sua configuração, adicione-a à raiz do seu arquivo de configuração puma.rb, como no exemplo abaixo.
# puma.rb (ou config/puma.rb)
plugin :appsignal # Adicione este plugin
# Secrets do Rails
# Adicione esta linha ao usar secrets do Rails no seu arquivo `config/appsignal.rb` ou `config/appsignal.yml`.
require "rails"
# Adicione esta seção ao usar dotenv para gerenciamento de secrets
require "dotenv"
Dotenv.load
# ou para apps Rails:
require "dotenv/load"
Dotenv.load
# Resto da sua configuração do Puma...
Hostname
Este probe escuta a opção de configuração APPSIGNAL_HOSTNAME da variável de
ambiente para a tag hostname
adicionada a todas as suas métricas. Se nenhuma for definida, ele tentará detectá-la automaticamente.
Use a variável de ambiente do sistema APPSIGNAL_HOSTNAME para definir o hostname caso
queira alterar o hostname detectado.
Porta do StatsD
Este probe escuta a opção de configuração APPSIGNAL_STATSD_PORT da variável de ambiente para a configuração de portas StatsD não padrão. Se a variável de ambiente não estiver definida, o padrão é 8125. Para o processo principal do Puma, é necessário usar a variável de ambiente; ele não lerá a configuração de arquivo do AppSignal.
Phased restart
Phased restarts do Puma
não reiniciam o processo principal do Puma, o que significa que o processo em background do AppSignal
também não é reiniciado em um phased restart. Se você fez alterações na
config do AppSignal, será necessário reiniciar completamente seu app Puma depois para
que a mudança de configuração tenha efeito.
# Após alterar a config do AppSignal, reinicie usando:
pumactl restart
# em vez de: pumactl phased-restart
Magic dashboard
Quando o AppSignal recebe métricas do Puma, ele criará um magic dashboard do Puma, disponível na seção de dashboard do app AppSignal.
O magic dashboard do Puma terá os seguintes gráficos:
| Gráfico | Métricas | Tags |
|---|
| Connection backlog | puma_connection_backlog | hostname |
| Pool capacity | puma_pool_capacity | hostname |
| Threads | puma_threads | maxrunning |
| Worker info | puma_workers | bootedcountold |
| Nome | Descrição |
|---|
booted | Número total de workers atualmente inicializados para este servidor. |
count | Número de threads atualmente em execução para este servidor. |
hostname | Nome do host do qual a métrica foi reportada. |
max | Número máximo de threads configuradas para este servidor. |
old | Número de workers executando a configuração/código anterior do servidor no momento. O Puma irá desativá-los gradualmente conforme novos workers iniciam. |
running | Número de threads atualmente em execução para este servidor |
Gráfico Connection backlog
O gráfico Connection backlog mostra a quantidade de conexões de entrada para o servidor que estão aguardando para serem atendidas na fila de backlog do servidor.
Você pode usar o gráfico Connection backlog para monitorar quantas requisições estão aguardando para serem tratadas e identificar gargalos do Puma.
Gráfico Pool capacity
O gráfico Pool capacity mostra a quantidade de threads do Puma disponíveis para receber requisições, incluindo threads do Puma que ainda não foram criadas.
Você pode usar o gráfico Pool capacity para monitorar a disponibilidade das threads do Puma e otimizar os workers.
Gráfico Threads
O gráfico Threads mostra informações sobre as threads criadas pelo Puma para atender requisições web, agregadas em todos os workers do Puma. Para atender requisições web, o Puma criará mais threads quando necessário. O gráfico mostrará a quantidade de threads em execução em comparação ao número máximo disponível de threads.
Você pode usar o gráfico Threads para monitorar a demanda e a oferta de threads do Puma e otimizar os workers.
Gráfico Worker info
O gráfico Worker info mostra quantos workers do Puma estão funcionando e qual versão do seu site eles estão usando. A linha count mostra quantos workers estão funcionando no total, enquanto as linhas booted e old mostram quantos workers estão usando a nova versão e quantos workers estão usando a versão antiga da sua aplicação.
Você pode usar o gráfico worker info para monitorar o status e a performance dos seus workers do Puma e ver quantos workers estão rodando em uma configuração desatualizada da sua aplicação. 