Minutely probes zijn een mechanisme om periodiek custom metrics naar AppSignal te sturen. Dit is een systeem dat standaard in de AppSignal Ruby gem is opgenomen. Aan het begin van elke minuut worden de minutely probes één voor één getriggerd om metrics te verzamelen en vervolgens gepauzeerd tot de volgende minuut.
Standaard schakelt de AppSignal Ruby gem probes in voor libraries die voor uw app worden gedetecteerd.
Let op: In AppSignal Ruby gem 3.7.0 en lager gebruikt u de
module Appsignal::Minutely.probes om probes te registreren, in plaats van de nieuwe
API Appsignal::Probes.
Gebruik
De minutely probes stellen de AppSignal Ruby gem in staat om standaard custom metrics te verzamelen voor integraties en app-specifieke metrics door uw eigen probe aan te maken.
Meerdere instances
Eenmaal geactiveerd, draait het minutely-probes-systeem op elke instance van een app. Dit betekent dat als een probe metrics rapporteert zonder een onderscheidende tag, globale metrics overschreven kunnen worden door metrics op instance-niveau. Bijvoorbeeld, er is een probe die bijhoudt hoe groot de lokale background-job-queue van een app is. De queue-database draait lokaal op de instance en de queue-groottes kunnen sterk variëren. Elke instance van een app rapporteert verschillende metric-waarden voor dezelfde metric en tags, waardoor de metric-waarde elke minuut wordt overschreven door die van de laatst rapporterende instance.
Om dit te verhelpen, raden we aan uw metrics te taggen met de hostname of iets anders unieks voor elke instance. Bijvoorbeeld, de Sidekiq-probe tagt metrics standaard met de Redis-hostname.
Als alternatief kunt u minutely probes uitschakelen voor alle instances behalve één, waarop het minutely-probes-proces draait. We raden aan de APPSIGNAL_ENABLE_MINUTELY_PROBES omgevingsvariabele te gebruiken om dit alleen op de gekozen instance in te schakelen.
Configuratie
De minutely probes worden geconfigureerd met de enable_minutely_probes config-optie.
Probes aanmaken
Als u meer custom metrics van uw app wilt tracken dan onze standaardprobes die met onze integraties worden meegeleverd, kunt u uw eigen probe(s) toevoegen.
Een AppSignal minutely probe kan een van drie dingen zijn. Welke van de drie types u voor uw klasse gebruikt, hangt af van de use-case.
Lambda probe
Het eenvoudigste probe-type om te registreren. Als u geen afhankelijkheden heeft voor uw probe, heeft deze methode de voorkeur.
# 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)
Class probe
Een class probe is een lazy geïnitialiseerde probe. Hij wordt pas gestart als de minutely probes worden gestart. Hij wordt geïnitialiseerd aan het begin van de minutely-probes-thread en blijft geïnitialiseerd zolang uw app draait.
Deze methode is nuttig wanneer u enable_minutely_probes niet voor elke omgeving heeft ingeschakeld en niet wilt dat deze standaard geïnitialiseerd wordt.
# 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
)
Geïnitialiseerde class probe
Deze methode is het meest nuttig voor het overschrijven van standaardprobes. De AppSignal Ruby gem levert standaard enkele probes voor integraties. Deze standaardprobes registreren probes als een class, zodat ze niet worden geïnitialiseerd wanneer ze overschreven worden. Wanneer de standaardconfiguratie van de probe niet past bij uw use-case, kunt u een standaardprobe overschrijven met uw eigen configuratie.
Merk op dat we geen klasse als probe registreren, maar een instance van de klasse met .new en een config-object meegeven, bv. 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")
)
Probes registreren
Probes kunnen worden geregistreerd met de register-methode op de module Appsignal::Probes.
Deze methode accepteert twee argumenten.
# 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)
Rails-apps
We raden aan om uw probes in een Rails-initializer te registreren, zoals: config/initializers/my_probe.rb.
Vereisten voor afhankelijkheden
Een probe moet niet altijd standaard aan de lijst van probes worden toegevoegd. Soms is een afhankelijkheid vereist om de probe correct te laten werken. Deze afhankelijkheidscontrole wordt gebruikt in probes die in de gem worden meegeleverd, maar kan ook in uw eigen probes worden gebruikt.
Door een class-methode genaamd dependencies_present? toe te voegen, kan voorafgaand aan het starten van de probe een controle worden uitgevoerd of deze gestart moet worden. Dit werkt zowel op class probes als geïnitialiseerde class probes. Voor het laatste scenario mag er geen aanroep van deze afhankelijkheid plaatsvinden in de initialize-methode van de probe, omdat deze al geïnitialiseerd is.
# 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")
)
Standaardprobes overschrijven
AppSignal levert standaardprobes voor bepaalde integraties. Als deze probe om welke reden dan ook niet goed werkt of aanvullende configuratie voor uw use-case vereist, kunt u de standaardprobe overschrijven door de probe-klasse te initialiseren met uw eigen configuratie.
Voorbeeld van het overschrijven van de 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 zelf instellen.)
Het overschrijven van probes logt een debugbericht in het appsignal.log-bestand, wat kan helpen om te detecteren of een probe correct overschreven is.
Probes uitschrijven
Om eerder geregistreerde probes uit te schrijven, inclusief de standaardprobes, gebruikt u de methode Appsignal::Probes.unregister. Roep de unregister-methode aan met de naam van de probe om deze uit te schrijven.
Appsignal::Probes.unregister(
:probe_name # Use the same key as used in `Probes.register` to unregister it
)
