Minutely probes são um mecanismo para enviar métricas personalizadas periodicamente para o AppSignal. Esse é um sistema incluído na gem AppSignal para Ruby por padrão. No início de cada minuto, as minutely probes são acionadas uma a uma para coletar métricas e então são suspensas até o próximo minuto.
Por padrão, a gem AppSignal para Ruby habilita probes para bibliotecas detectadas no seu app.
Nota: Na gem AppSignal para Ruby 3.7.0 e versões anteriores, use o
módulo Appsignal::Minutely.probes para registrar probes, em vez da nova
API Appsignal::Probes.
Uso
As minutely probes permitem que a gem AppSignal para Ruby colete métricas personalizadas por padrão para integrações e métricas específicas do app criando sua própria probe.
Múltiplas instâncias
Uma vez ativado, o sistema de minutely probes roda em cada instância de um app. Isso significa que se uma probe reportar métricas sem algum tipo de tag diferenciadora, métricas globais podem ser sobrescritas por métricas em nível de instância. Por exemplo, há uma probe que rastreia o tamanho da fila local de background jobs de um app. O banco de dados de fila roda localmente na instância e os tamanhos da fila podem variar muito. Cada instância de um app reporta valores de métrica diferentes para a mesma métrica e tags, sobrescrevendo o valor da métrica a cada minuto com os da última instância que reportou.
Para remediar isso, sugerimos marcar com tags suas métricas com o hostname ou algo único para cada instância. Por exemplo, a Sidekiq probe marca as métricas com o hostname do Redis por padrão.
Alternativamente, você pode desabilitar minutely probes para todas as instâncias, exceto uma, na qual o processo de minutely probes é executado. Sugerimos usar a variável de ambiente APPSIGNAL_ENABLE_MINUTELY_PROBES para habilitá-lo apenas na instância de sua escolha.
Configuração
As minutely probes são configuradas usando a opção de configuração enable_minutely_probes.
Criando probes
Se você quiser rastrear mais métricas personalizadas do seu app além das probes padrão que vêm com nossas integrações, você pode adicionar suas próprias probes.
Uma minutely probe do AppSignal pode ser uma de três coisas. Qual dos três tipos usar para sua classe depende do caso de uso.
Probe Lambda
O tipo de probe mais simples para registrar. Se você não tem dependências para sua probe, este é o método preferido.
# config/initializers/appsignal.rb or a file that's loaded on boot
Appsignal::Probes.register(:my_probe, lambda do
Appsignal.set_gauge("database_size", 10)
end)
Probe de classe
Uma probe de classe é uma probe inicializada de forma lazy. Ela só será iniciada se as minutely probes forem iniciadas. Será inicializada no início da thread de minutely probes e permanecerá inicializada enquanto seu app estiver rodando.
Este método é útil quando você não tem enable_minutely_probes habilitado para todos os ambientes e não quer que seja inicializado por padrão.
# config/initializers/appsignal.rb or a file that's loaded on boot
# Creating a probe using a Ruby class
class BackgroundJobLibraryProbe
def initialize
# This is only called when the minutely probe gets initialized
require "background_job_library"
@connection = BackgroundJobLibrary.connection
end
def call
stats = @connection.fetch_queue_stats
Appsignal.set_gauge "background_job_library_queue_length", stats.queue_length
Appsignal.set_gauge "background_job_library_processed_jobs", stats.processed_jobs
end
end
# Registering a Class probe
Appsignal::Probes.register(
:background_job_library_probe,
BackgroundJobLibraryProbe
)
Probe de classe inicializada
Este método é mais útil para sobrescrever probes padrão. A gem AppSignal para Ruby vem com algumas probes para integrações por padrão. Essas probes padrão registram probes como uma classe, então elas não serão inicializadas quando sobrescritas. Quando a configuração padrão da probe não se adequa ao seu caso de uso, você pode sobrescrever uma probe padrão com sua própria configuração.
Note que não registramos uma classe como uma probe, mas uma instância da classe usando .new e passamos um objeto de configuração, ex.: BackgroundJobLibraryProbe.new(<config>).
# config/initializers/appsignal.rb or a file that's loaded on boot
require "background_job_library"
# Creating a probe using a Ruby class
class BackgroundJobLibraryProbe
def initialize(config)
@connection = BackgroundJobLibrary.connection(config)
end
def call
stats = @connection.fetch_queue_stats
Appsignal.set_gauge "background_job_library_queue_length", stats.queue_length
Appsignal.set_gauge "background_job_library_processed_jobs", stats.processed_jobs
end
end
# Registering an initialized Class probe
Appsignal::Probes.register(
:background_job_library_probe,
BackgroundJobLibraryProbe.new(:database => "redis://localhost:6379")
)
Registrando probes
Probes podem ser registradas com o método register no módulo Appsignal::Probes.
Este método aceita dois argumentos.
# config/initializers/appsignal.rb or a file that's loaded on boot
Appsignal::Probes.register(:my_probe, lambda do
Appsignal.set_gauge("database_size", 10)
end)
Apps Rails
Recomendamos registrar suas probes em um initializer do Rails, como: config/initializers/my_probe.rb.
Requisitos de dependências
Nem sempre uma probe deve ser adicionada à lista de probes por padrão. Alguma dependência pode ser necessária para que a probe funcione corretamente. Essa verificação de dependência é usada em probes incluídas na gem, mas também pode ser usada em suas próprias probes.
Ao adicionar um método de classe chamado dependencies_present?, uma verificação pode ser realizada antes de iniciar a probe para saber se ela deve ser iniciada ou não. Isso funciona tanto em probes de classe quanto em probes de classe inicializada. Para este último cenário, não deve haver chamada à dita dependência no método initialize da probe, pois ela já está inicializada.
# config/initializers/appsignal.rb or a file that's loaded on boot
require "background_job_library"
# Creating a probe using a Ruby class
class BackgroundJobLibraryProbe
def self.dependencies_present?
# Only start the probe if the BackgroundJobLibrary version is higher or
# equal to 1.0.0.
Gem::Version.new(BackgroundJobLibrary::Version) >= Gem::Version.new("1.0.0")
end
def initialize(config = {})
@config = config
end
def call
stats = connection.fetch_queue_stats
Appsignal.set_gauge "background_job_library_queue_length", stats.queue_length
Appsignal.set_gauge "background_job_library_processed_jobs", stats.processed_jobs
end
private
def connection
@connection ||= BackgroundJobLibrary.connection(@config)
end
end
# Registering a Class probe with a `dependencies_present?` check
Appsignal::Probes.register(
:background_job_library_probe,
BackgroundJobLibraryProbe
)
# Also works for initialized probes
Appsignal::Probes.register(
:background_job_library_probe,
BackgroundJobLibraryProbe.new(:url => "schema://my_connection_url:9090")
)
Sobrescrevendo probes padrão
O AppSignal vem com probes padrão para certas integrações. Se por algum motivo essa probe não funcionar corretamente ou requerer alguma configuração adicional para o seu caso de uso, você pode sobrescrever a probe padrão inicializando a classe da probe com sua própria configuração.
Exemplo sobrescrevendo a Sidekiq probe.
# config/initializers/appsignal.rb or a file that's loaded on boot
Appsignal::Probes.register(
:sidekiq, # Use the same key as the default Sidekiq probe to override it
Appsignal::Probes::SidekiqProbe.new(:hostname => ENV["REDIS_URL"])
)
REDIS_URL você mesmo.)
Sobrescrever probes registrará uma mensagem de debug no arquivo appsignal.log, o que pode ajudar a detectar se uma probe foi corretamente sobrescrita.
Desregistrar probes
Para desregistrar probes previamente registradas, incluindo as probes padrão, use o método Appsignal::Probes.unregister. Chame o método unregister com o nome da probe para desregistrá-la.
Appsignal::Probes.unregister(
:probe_name # Use the same key as used in `Probes.register` to unregister it
)
