Puma wurde für Geschwindigkeit und Parallelität entwickelt. Puma ist eine kleine Bibliothek, die einen schnellen und nebenläufigen HTTP-1.1-Server für Ruby-Webanwendungen bereitstellt.
Das AppSignal-Ruby-Gem fügt automatisch einen Listener in den Puma-Server ein; manuelles Setup ist nicht erforderlich.
Puma-Metriken-Plugin
Das AppSignal-Puma-Plugin erfasst Metriken über die Funktionsweise von Puma. Wenn AppSignal Puma-Metriken erkennt, wird ein Magic Dashboard erstellt, mit dem Sie zentrale Metriken visuell überwachen können.
Um die Metrikerfassung zu aktivieren, fügen Sie das AppSignal-Plugin zu Ihrer Puma-Konfiguration hinzu:
# puma.rb (or config/puma.rb)
plugin :appsignal
Der mit dem AppSignal-Agent ausgelieferte StatsD-Server muss aktiv sein, damit
das Puma-Metriken-Plugin funktioniert. Stellen Sie sicher, dass die
Konfigurationsoption enable_statsd nicht auf
false gesetzt ist. Verwendung mit prune_bundler
Wenn Ihre puma.rb-Datei prune_bundler enthält, müssen Sie AppSignal als Runtime-Abhängigkeit hinzufügen.
Um Puma mit prune_bundler zu verwenden, ist Puma Version 4.2.0 oder höher erforderlich.
# puma.rb (or config/puma.rb)
prune_bundler
plugin :appsignal
extra_runtime_dependencies ["appsignal"]
Verwendung mit preload_app!
Wenn Ihre puma.rb-Datei preload_app! enthält, ist eine bestimmte Konfiguration erforderlich, um Metriken aus Minutely-Probes korrekt zu melden. Wenn preload_app! auf true gesetzt ist, laufen die Minutely-Probes im Puma-Primärprozess. Im Primärprozess können die Probes nicht auf dieselben Daten zugreifen wie die App, die in den Puma-Workern läuft, wodurch ungenaue oder gar keine Daten gemeldet werden.
Stoppen Sie in der Puma-Konfigurationsdatei puma.rb die AppSignal-Minutely-Probes im before_fork-Callback, um die Minutely-Probes im Puma-Hauptprozess zu beenden. Starten Sie die Minutely-Probes dann im Worker-Prozess aus dem on_worker_boot-Callback heraus.
# puma.rb or config/puma.rb
# When preload_app! is set
preload_app!
# Add this before_fork callback to stop the minutely probes in the Puma main process
before_fork do
Appsignal::Probes.stop
end
# Add this on_worker_boot callback to start the minutely probes in the Puma worker processes
on_worker_boot do
Appsignal::Probes.start
end
Secrets
Wenn Sie eine Bibliothek wie Rails oder dotenv verwenden, um die Secrets Ihrer App zu verwalten und AppSignal zu konfigurieren, müssen Sie diese in Ihrer Puma-Konfiguration laden.
AppSignal führt einen Hintergrundprozess in Pumas Hauptprozess aus, wenn das Puma-Plugin verwendet wird. Der Rest Ihrer App wird standardmäßig nicht im Hauptprozess von Puma geladen (es sei denn, Sie verwenden preload_app!, was für Ihre App möglicherweise nicht geeignet ist). Ohne zusätzliche Konfiguration kann die AppSignal-Konfiguration nicht geladen werden und AppSignal startet nicht.
In Puma ist kein „on boot”-Hook verfügbar, um zusätzliche Konfiguration im Hauptprozess zu laden. Um Ihre Konfiguration zu laden, fügen Sie sie wie im folgenden Beispiel an den Anfang Ihrer puma.rb-Konfigurationsdatei.
# puma.rb (or config/puma.rb)
plugin :appsignal # Add this plugin
# Rails secrets
# Add this line when using Rails secrets in your `config/appsignal.rb` or `config/appsignal.yml` file.
require "rails"
# Add this section when using dotenv for secrets management
require "dotenv"
Dotenv.load
# or for Rails apps:
require "dotenv/load"
Dotenv.load
# Rest of your Puma config...
Hostname
Diese Probe liest die Konfigurationsoption APPSIGNAL_HOSTNAME aus der Umgebungsvariable für das Hostname-Tag, das allen Metriken hinzugefügt wird. Wenn keine gesetzt ist, versucht sie, ihn automatisch zu erkennen.
Verwenden Sie die Systemumgebungsvariable APPSIGNAL_HOSTNAME, um den Hostnamen zu setzen, wenn Sie den erkannten Hostnamen ändern möchten.
StatsD-Port
Diese Probe liest die Konfigurationsoption APPSIGNAL_STATSD_PORT aus der Umgebungsvariable für die Konfiguration nicht standardmäßiger StatsD-Ports. Wenn die Umgebungsvariable nicht gesetzt ist, wird standardmäßig 8125 verwendet. Für den Puma-Hauptprozess ist die Verwendung der Umgebungsvariable erforderlich; die AppSignal-Dateikonfiguration wird nicht gelesen.
Phased Restart
Die Phased Restarts von Puma
starten den Puma-Hauptprozess nicht neu, was bedeutet, dass auch der AppSignal-Hintergrundprozess
bei einem Phased Restart nicht neu gestartet wird. Wenn Sie Änderungen an der
AppSignal-Konfiguration vorgenommen haben, müssen Sie Ihre Puma-App anschließend vollständig neu starten,
damit die Konfigurationsänderung wirksam wird.
# After changing the AppSignal config, restart using:
pumactl restart
# instead of: pumactl phased-restart
Magic Dashboard
Wenn AppSignal Puma-Metriken empfängt, wird ein Puma Magic Dashboard erstellt, das im Dashboard-Bereich der AppSignal-App verfügbar ist.
Das Puma Magic Dashboard enthält die folgenden Graphen:
| Graph | Metriken | Tags |
|---|
| Connection Backlog | puma_connection_backlog | hostname |
| Pool-Kapazität | puma_pool_capacity | hostname |
| Threads | puma_threads | maxrunning |
| Worker-Info | puma_workers | bootedcountold |
| Name | Beschreibung |
|---|
booted | Gesamtzahl der aktuell gestarteten Worker für diesen Server. |
count | Anzahl der aktuell laufenden Threads für diesen Server. |
hostname | Name des Hosts, von dem die Metrik gemeldet wurde. |
max | Maximale Anzahl konfigurierter Threads für diesen Server. |
old | Anzahl der Worker, die zum jeweiligen Zeitpunkt die vorherige Konfiguration/den vorherigen Code des Servers ausführen. Puma phast diese mit neuen Workern aus. |
running | Anzahl der aktuell laufenden Threads für diesen Server |
Connection-Backlog-Graph
Der Connection-Backlog-Graph zeigt die Anzahl der eingehenden Verbindungen zum Server, die in der Backlog-Warteschlange des Servers darauf warten, bearbeitet zu werden.
Sie können den Connection-Backlog-Graphen verwenden, um zu überwachen, wie viele Anfragen auf ihre Bearbeitung warten, und Puma-Engpässe zu erkennen.
Pool-Kapazität-Graph
Der Pool-Kapazität-Graph zeigt die Anzahl der Puma-Threads, die zum Empfangen von Anfragen verfügbar sind, einschließlich Puma-Threads, die noch gestartet werden müssen.
Sie können den Pool-Kapazität-Graphen verwenden, um die Verfügbarkeit von Puma-Threads zu überwachen und Worker zu optimieren.
Threads-Graph
Der Threads-Graph zeigt Informationen über die von Puma zur Bedienung von Web-Anfragen gestarteten Threads, aggregiert über alle Puma-Worker. Um Web-Anfragen zu bedienen, startet Puma bei Bedarf weitere Threads. Der Graph zeigt Ihnen die Anzahl der laufenden Threads im Verhältnis zur maximal verfügbaren Anzahl an Threads.
Sie können den Threads-Graphen verwenden, um Nachfrage und Angebot der Puma-Threads zu überwachen und Worker zu optimieren.
Worker-Info-Graph
Der Worker-Info-Graph zeigt, wie viele Puma-Worker arbeiten und welche Version Ihrer Website sie verwenden. Die Count-Linie zeigt, wie viele Worker insgesamt arbeiten, während die Booted- und Old-Linien zeigen, wie viele Worker die neue Version und wie viele die alte Version Ihrer Anwendung verwenden.
Sie können den Worker-Info-Graphen verwenden, um den Status und die Performance Ihrer Puma-Worker zu überwachen und zu sehen, wie viele Worker mit einer veralteten Konfiguration Ihrer Anwendung laufen. 