Puma a été conçu pour la vitesse et le parallélisme. Puma est une petite bibliothèque qui fournit un serveur HTTP 1.1 rapide et concurrent pour les applications web Ruby.
La gem AppSignal Ruby insère automatiquement un listener dans le serveur Puma ; aucune configuration manuelle n’est requise.
Plugin de métriques Puma
Le plugin AppSignal pour Puma collectera des métriques sur le fonctionnement de Puma. Lorsqu’AppSignal détecte des métriques Puma, il créera un Magic Dashboard vous permettant de surveiller visuellement les métriques principales.
Pour activer la collecte de métriques, ajoutez le plugin AppSignal à votre configuration Puma :
# puma.rb (or config/puma.rb)
plugin :appsignal
Le serveur StatsD intégré à l’agent AppSignal doit être actif pour que le
plugin de métriques Puma fonctionne. Assurez-vous que l’option de
configuration enable_statsd
n’est pas définie sur false. Utilisation avec prune_bundler
Si votre fichier puma.rb inclut prune_bundler, vous devez ajouter AppSignal comme dépendance d’exécution.
Pour utiliser Puma avec prune_bundler, Puma version 4.2.0 ou supérieure est requise.
# puma.rb (or config/puma.rb)
prune_bundler
plugin :appsignal
extra_runtime_dependencies ["appsignal"]
Utilisation avec preload_app!
Si votre fichier puma.rb inclut preload_app!, une certaine configuration est requise pour rapporter correctement les métriques des sondes minute par minute. Lorsque preload_app! est défini sur true, les sondes minute par minute s’exécutent dans le processus principal de Puma. Dans le processus principal, les sondes ne peuvent pas accéder aux mêmes données que l’application s’exécutant dans les workers Puma, ce qui entraîne le signalement de données inexactes ou aucune donnée.
Dans le fichier de configuration puma.rb, arrêtez les sondes minute par minute AppSignal dans le callback before_fork pour arrêter les sondes dans le processus principal Puma. Démarrez ensuite les sondes minute par minute dans le processus worker à partir du callback on_worker_boot.
# 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
Si vous utilisez une bibliothèque telle que Rails ou dotenv pour gérer les secrets de votre application et configurer AppSignal, vous devrez les charger dans votre configuration Puma.
AppSignal exécute un processus en arrière-plan dans le processus principal de Puma lors de l’utilisation du plugin Puma. Le reste de votre application n’est pas chargé par défaut dans le processus principal de Puma (sauf si vous utilisez preload_app!, ce qui peut ne pas convenir à votre application). Sans configuration supplémentaire, la configuration AppSignal ne se chargera pas et AppSignal ne démarrera pas.
Aucun hook « on boot » n’est disponible dans Puma pour charger votre configuration supplémentaire dans le processus principal. Pour charger votre configuration, ajoutez-la à la racine de votre fichier de configuration puma.rb, comme dans l’exemple ci-dessous.
# 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...
Nom d’hôte
Cette sonde écoute l’option de configuration APPSIGNAL_HOSTNAME provenant de la variable
d’environnement pour le tag hostname
ajouté à toutes ses métriques. Si aucune n’est définie, elle tentera de la détecter automatiquement.
Utilisez la variable d’environnement système APPSIGNAL_HOSTNAME pour définir le nom d’hôte si vous
souhaitez modifier le nom d’hôte détecté.
Port StatsD
Cette sonde écoute l’option de configuration APPSIGNAL_STATSD_PORT provenant de la variable d’environnement pour la configuration des ports StatsD non par défaut. Si la variable d’environnement n’est pas définie, elle prend par défaut la valeur 8125. Pour le processus principal Puma, il est nécessaire d’utiliser la variable d’environnement ; elle ne lira pas la configuration du fichier AppSignal.
Redémarrage par phases
Les redémarrages par phases de Puma
ne redémarrent pas le processus Puma principal, ce qui signifie que le processus AppSignal en arrière-plan
n’est pas non plus redémarré lors d’un redémarrage par phases. Si vous avez apporté des modifications à la
configuration AppSignal, vous devrez redémarrer entièrement votre application Puma par la suite pour que
la modification de configuration prenne effet.
# After changing the AppSignal config, restart using:
pumactl restart
# instead of: pumactl phased-restart
Magic dashboard
Lorsqu’AppSignal reçoit des métriques Puma, il créera un magic dashboard Puma, disponible dans la section dashboard de l’application AppSignal.
Le magic dashboard Puma contiendra les graphiques suivants :
| Graphique | Métriques | Tags |
|---|
| Connection backlog | puma_connection_backlog | hostname |
| Pool capacity | puma_pool_capacity | hostname |
| Threads | puma_threads | maxrunning |
| Worker info | puma_workers | bootedcountold |
| Nom | Description |
|---|
booted | Nombre total de workers actuellement démarrés pour ce serveur. |
count | Nombre de threads en cours d’exécution pour ce serveur. |
hostname | Nom de l’hôte depuis lequel la métrique a été signalée. |
max | Nombre maximum de threads configurés pour ce serveur. |
old | Nombre de workers exécutant la configuration/le code précédent du serveur à un moment donné. Puma les éliminera progressivement à mesure que de nouveaux workers démarrent. |
running | Nombre de threads en cours d’exécution pour ce serveur |
Graphique Connection backlog
Le graphique Connection backlog montre le nombre de connexions entrantes au serveur qui attendent d’être servies dans la file d’attente backlog du serveur.
Vous pouvez utiliser le graphique Connection backlog pour surveiller le nombre de requêtes en attente de traitement et repérer les goulots d’étranglement Puma.
Graphique Pool capacity
Le graphique Pool capacity montre le nombre de threads Puma disponibles pour recevoir des requêtes, y compris les threads Puma qui n’ont pas encore été créés.
Vous pouvez utiliser le graphique Pool capacity pour surveiller la disponibilité des threads Puma et optimiser les workers.
Graphique Threads
Le graphique Threads affiche des informations sur les threads créés par Puma pour servir les requêtes web, agrégés sur l’ensemble des workers Puma. Pour servir les requêtes web, Puma créera plus de threads selon les besoins. Le graphique vous montrera le nombre de threads en cours d’exécution par rapport au nombre maximal de threads disponibles.
Vous pouvez utiliser le graphique Threads pour surveiller la demande et l’offre de threads Puma et optimiser les workers.
Graphique Worker info
Le graphique Worker info montre combien de workers Puma fonctionnent et quelle version de votre site web ils utilisent. La ligne count montre combien de workers fonctionnent au total, tandis que les lignes booted et old indiquent combien de workers utilisent la nouvelle version et combien utilisent l’ancienne version de votre application.
Vous pouvez utiliser le graphique worker info pour surveiller l’état et les performances de vos workers Puma et voir combien de workers fonctionnent sur une configuration obsolète de votre application. 