Bibliothèques de langage
La gem Ruby AppSignal et le package Elixir fournissent une intégration pour leur langage de programmation respectif et les bibliothèques populaires (pour Ruby et Elixir) de leur écosystème, afin de fournir le rapport d’erreurs et des insights de performance. Il est actuellement requis d’utiliser l’une de ces bibliothèques pour intégrer AppSignal dans votre application et collecter les métriques d’hôte depuis son hôte. Lorsque vous installez la gem Ruby AppSignal et le package Elixir dans votre application, une extension native pour le langage de programmation est compilée à côté. Cette extension communique avec l’agent pour traiter efficacement vos données et les envoyer à l’API Push AppSignal. Lorsque vous démarrez votre application avec AppSignal installé, l’agent AppSignal sera démarré en arrière-plan. Il ne démarrera qu’un seul agent par configuration ; si une nouvelle configuration est trouvée, un nouvel agent démarrera et les agents pour les autres versions seront arrêtés.Extension
L’extension AppSignal communique entre le langage de programmation et l’agent AppSignal. Une partie est écrite en Rust et l’autre dans le langage de programmation C. La machine hôte sur laquelle AppSignal est installé doit donc avoir un compilateur C fonctionnel présent. En général, celui-ci est déjà installé sur la machine hôte, mais pour beaucoup d’images Docker, ce n’est souvent pas le cas afin de garder les images petites. Les paquets requis pour votre système d’exploitation sont listés sur notre page systèmes d’exploitation pris en charge. Il y a deux parties à l’extension AppSignal, l’extension C et la bibliothèque statique/dynamique écrite en Rust. L’extension C pour Ruby et la Nif pour Elixir implémenteront l’interface de la bibliothèque AppSignal afin que la bibliothèque de langage AppSignal puisse communiquer avec elle. Une bibliothèque séparée est utilisée afin que l’implémentation puisse être partagée entre les bibliothèques AppSignal. L’extension communique avec l’agent via un socket, dont le pointeur est stocké dans le répertoire de travail de l’agent. Cette communication est unidirectionnelle, l’extension envoie les données enregistrées à l’agent et l’agent les envoie aux serveurs AppSignal.Agent
Une fois démarré par l’extension, l’agent AppSignal continuera à fonctionner en arrière-plan de votre application en tant que processus daemonisé. Il gérera les connexions de plusieurs clients (processus d’application via l’extension) lorsque nécessaire. Par exemple, si vous exécutez à la fois Unicorn (serveur web) et Sidekiq (bibliothèque de tâches en arrière-plan) en même temps, il n’y aura qu’un seul agent AppSignal en cours d’exécution pour les deux processus. Si la connexion à l’agent est perdue, les clients se reconnecteront automatiquement et/ou démarreront un nouvel agent. (Comportement de redémarrage ajouté dans la gem Ruby version2.4.0, le package Elixir version 1.4.0 et Node.js 1.0.0).
Au démarrage, l’agent essaiera de localiser un répertoire de travail approprié dans lequel il peut stocker certains de ses fichiers d’exploitation temporaires. Il doit créer et écrire des fichiers dans le répertoire de travail et créer le fichier appsignal.log avant de pouvoir démarrer correctement. S’il échoue à le faire, il ne démarrera pas correctement et quittera. L’agent nécessite un emplacement pour stocker le fichier appsignal.log car la valeur stdout pour l’option de configuration log (pour Ruby et Elixir) ne s’appliquera pas à l’agent. L’agent ne peut pas communiquer ses logs en retour via le socket avec l’extension.
L’agent lui-même est un processus léger écrit en Rust, qui utilise très peu de ressources. Il ne conserve vos données en mémoire que pour une très courte période jusqu’à ce qu’il les envoie à l’API Push AppSignal, après quoi il vide les données. S’il ne peut pas se connecter à l’API Push AppSignal, il stockera temporairement les données sur le disque, voir répertoire de travail.
Au fil du temps, l’agent recevra des données de surveillance de vos applications et commencera à les agréger. Après un intervalle de transmission de 30 secondes, il enverra les données agrégées à l’API Push AppSignal. Là, elles seront traitées, des incidents et des alertes de détection d’anomalies sont créés, et finalement des notifications vous sont envoyées, à vous, l’utilisateur.
Périodiquement, l’agent lira également les statistiques système de la machine sur laquelle il s’exécute pour collecter les métriques d’hôte. Cela est effectué à l’aide de la bibliothèque probes-rs écrite par AppSignal. Les données des métriques d’hôte sont utilisées pour la fonctionnalité des métriques d’hôte afin de fournir des graphiques et d’afficher les données des métriques d’hôte pour les échantillons à ce moment-là.
Si une requête vers notre API Push a échoué, la charge utile de cette requête est écrite sur le disque dans le répertoire de travail et il essaiera à nouveau d’envoyer la charge utile lors du prochain intervalle de transmission.
Répertoire de travail
Le répertoire de travail est utilisé pour plusieurs choses dont l’agent AppSignal a besoin pour continuer à fonctionner. C’est une partie obligatoire pour pouvoir exécuter l’agent AppSignal. Si aucun emplacement approprié pour le répertoire de travail ne peut être trouvé, l’agent s’arrêtera et l’extension dans votre application se désactivera elle-même. Elle ne signalera plus de données aux serveurs AppSignal. Les responsabilités du répertoire de travail :- Emplacement de secours pour
appsignal.log- Le répertoire de travail fonctionne comme l’emplacement de secours pour le fichier
appsignal.loglorsqu’aucun chemin valide ne peut être détecté et que l’emplacementlog_pathdonné est inutilisable (option de configuration pour Ruby et Elixir). Si aucun emplacement approprié n’est trouvé, comme dans le répertoirelog/de votre projet, il sera stocké dans{working_directory}/appsignal.log. Lisez-en davantage sur les logs AppSignal.
- Le répertoire de travail fonctionne comme l’emplacement de secours pour le fichier
- Stockage du fichier
agent.socket- L’agent AppSignal stocke un fichier socket dans
{working_directory}/agent.socket, qui est utilisé par l’extension AppSignal dans votre application pour communiquer avec l’agent. Chaque fois qu’une transaction AppSignal se termine ou que vous envoyez une métrique personnalisée, ces données sont écrites dans le socket et reçues par l’agent. Il agrégera ensuite ces données et les transmettra à l’API Push AppSignal.
- L’agent AppSignal stocke un fichier socket dans
- Stockage du fichier
agent.lock- L’agent AppSignal stocke un fichier de verrouillage (
agent.lock) pour s’assurer qu’il n’y a qu’une seule instance de l’agent en cours d’exécution avec la configuration de votre application. Si une nouvelle version de l’agent est démarrée, les versions plus anciennes s’arrêteront lorsqu’elles détecteront qu’une version plus récente est en cours d’exécution, permettant à l’agent nouvellement démarré de gérer toutes les données entrantes à partir de ce moment. - L’utilisation d’un seul répertoire de travail, et fichier de verrouillage, pour plusieurs applications s’exécutant sur la même machine peut créer un comportement étrange. Pour cette raison, nous recommandons d’utiliser un emplacement de répertoire de travail par application. Lisez-en davantage sur l’exécution de plusieurs applications sur un seul hôte.
- Si vous supprimez ce fichier, ou tout le répertoire de travail, l’agent s’arrêtera immédiatement.
- L’agent AppSignal stocke un fichier de verrouillage (
- Stockage
payloads- Le répertoire des charges utiles contient les charges utiles mises en cache écrites sur le disque pour lorsque l’agent a des difficultés à se connecter à notre API Push. Pour éviter que l’empreinte mémoire de l’agent n’augmente avec le temps, ces données sont stockées temporairement sur le disque. Cela nous permet de nous assurer que nous ne perdons aucune de vos précieuses données si votre connexion réseau est interrompue pendant un temps limité ou si notre API Push a un petit hoquet. La quantité de charges utiles stockées sur le disque est automatiquement limitée aux quelques dernières charges utiles, donc cela utilisera toujours un petit espace disque.
Emplacement
L’emplacement par défaut du répertoire de travail est/tmp/appsignal. Si vous utilisez une structure de répertoire de style Capistrano, il créera un répertoire nommé appsignal dans app/shared. Sur les déploiements de style Heroku, il créera le répertoire dans /app/tmp. Si aucun de ces chemins n’est détecté, le répertoire AppSignal sera créé à l’emplacement par défaut.
L’emplacement du répertoire de travail peut être personnalisé avec l’option de configuration working_directory_path (Ruby / Elixir). Tout chemin configuré de cette manière aura la priorité sur tout chemin qu’il peut détecter.
Permissions
Par défaut, le répertoire de travail est accessible en écriture pour tout le monde (permissions Unix0666). C’est la valeur par défaut, car au fil du temps, nous avons vu de nombreuses demandes de support qui provenaient du fait que le répertoire de travail existait, mais n’était pas accessible en écriture par l’agent AppSignal. Par exemple : lorsque l’application est démarrée par l’utilisateur de déploiement lors du déploiement de l’application, mais par un autre utilisateur lors d’un redémarrage de l’hôte. Cela donne la propriété du répertoire à l’un des comptes utilisateur, tout en le rendant non accessible en écriture pour l’autre utilisateur.
Il est possible de désactiver les permissions globales de lecture et d’écriture (et de donner au répertoire de travail les permissions Unix 0644) en définissant l’option de configuration files_world_accessible (Ruby / Elixir) sur false pour vos applications.