Actions
Les actions sont l’endroit dans le code où une requête HTTP, une tâche en arrière-plan, une tâche cron ou une tâche est démarrée. Pour les applications Ruby on Rails et Phoenix d’Elixir, il s’agit de la combinaison contrôleur et action, telle queBlogPostsController#create ou Api::UsersController#index. Pour les tâches en arrière-plan, il s’agira du nom du worker/job, tel que UserMailer#sign_up_mail.
Les actions sont utilisées pour regrouper les issues avec le namespace et l’erreur.
Agent
AppSignal utilise un « agent » pour communiquer avec les serveurs AppSignal et instrumenter les hôtes sur lesquels une application s’exécute. Les données d’hôte sont utilisées dans notre fonctionnalité métriques d’hôte. L’agent est démarré par la bibliothèque spécifique au langage et s’exécute en tant que processus UNIX séparé sur l’hôte de l’application. La bibliothèque de langage et l’agent communiquent entre eux via un socket UNIX en utilisant une extension. Les données d’instrumentation de transaction collectées par l’agent sont envoyées aux serveurs AppSignal. Les données de transaction sont traitées et utilisées pour détecter les événements méritant d’alerter les utilisateurs. Lisez-en davantage sur la façon dont l’agent AppSignal fonctionne et le cycle de vie d’une requête AppSignal.Allocations
Pendant une requête HTTP ou une tâche en arrière-plan, une application utilise de la mémoire. Chaque structure de données chargée et objet instancié occupe de la mémoire. Lorsqu’une requête ou une tâche gère beaucoup de données, beaucoup plus de mémoire peut être utilisée que ce qui est normal. Les bibliothèques d’intégration AppSignal suivent les allocations par transaction. L’intégration suit également quelle partie de l’application alloue plus d’objets en mémoire que d’autres, il est donc possible de voir si l’ORM de l’application ou la bibliothèque de templates prend plus de mémoire. Sur AppSignal.com, le nombre d’allocations est affiché sous forme d’entier pour une action, des groupes d’événements et des événements spécifiques. Ce nombre d’allocations correspond au nombre d’objets qui ont été créés en mémoire pendant une action/un groupe/un événement. La taille de l’objet créé n’est pas suivie.Détection d’anomalies
La détection d’anomalies est une fonctionnalité d’AppSignal qui permet aux utilisateurs de détecter les anomalies dans leurs applications. Une anomalie peut être quelque chose comme un taux d’erreur accru ou une quantité limitée de mémoire libre sur l’hôte de l’application. La détection d’anomalies fonctionne avec des conditions de seuil de déclencheur qui créent des alertes lorsque leur seuil est atteint. Lorsqu’une alerte est ouverte, AppSignal enverra des notifications à tous les notificateurs sélectionnés pour le déclencheur spécifique. Consultez notre documentation sur la détection d’anomalies pour plus d’informations.API
Une API est une « Application Programming Interface ». Le terme API est large et est utilisé de nombreuses manières. Dans le contexte de notre documentation, nous faisons référence à l’API REST HTTP AppSignal lorsque nous utilisons « API ». L’API AppSignal est une API REST HTTP qui peut être utilisée pour récupérer des données des serveurs AppSignal et enrichir les données existantes avec plus d’informations telles que les marqueurs. L’API diffère de l’API Push dans son objectif. Alors que l’API Push est utilisée pour envoyer des données à AppSignal par l’agent, l’API HTTP REST est principalement utilisée pour récupérer des données depuis AppSignal. Cela permet aux utilisateurs d’utiliser les données disponibles dans d’autres outils. Vous pouvez en savoir plus sur notre API dans notre documentation API.Clé API
Pour se connecter à l’API AppSignal, il est nécessaire d’être authentifié. Chaque utilisateur a sa clé API pour s’authentifier auprès d’AppSignal. Votre clé API peut être trouvée sur votre profil utilisateur. Cette clé ne doit pas être confondue avec la clé API Push qui est utilisée par les applications avec un agent AppSignal installé.Applications
Les applications (auparavant connues sous le nom de « sites », également appelées « apps ») sont des applications Ruby et Elixir surveillées par AppSignal. Après avoir installé la bibliothèque AppSignal dans une application, AppSignal commence à surveiller ces applications. Une fois que nous recevons des données d’une application, nous l’enregistrons en utilisant le nom de l’application et l’environnement dans lequel elle s’exécute. Une application peut avoir plusieurs environnements tant que chaque environnement utilise le même nom.- « Application de démo » - Développement
- « Application de démo » - Production
- « Application de démo » - Staging
- « Application de démo » - Test
AppSignal vs Appsignal vs appsignal
Attendez, ce sont trois casses différentes du nom AppSignal ? Oui ! Expliquons :| Casse | Utilisation |
|---|---|
AppSignal | Le nom de marque de l’entreprise, de l’application et presque tout le reste relatif à AppSignal. C’est la version que vous devriez utiliser lorsque vous parlez d’AppSignal en tant que marque, produit ou service ou fournisseur de stroopwaffles. |
Appsignal | Le nom de bibliothèque de nos intégrations AppSignal (intégration Ruby, intégration Elixir, intégration Node.js, intégration Front-end, etc.). Utilisé uniquement dans le contexte du code. |
appsignal | Les noms de packages d’intégration AppSignal tels que publiés dans les registres de gestionnaires de paquets pour la gem Ruby, le préfixe du package Elixir et des packages, le préfixe des packages Node.js et le préfixe des packages Front-end, etc. |
Blog
Nous avons un blog à blog.appsignal.com ! Sur notre blog, nous publions tout ce qui concerne AppSignal, comme les nouvelles fonctionnalités, les nouvelles versions majeures de l’agent, les articles Ruby Magic et d’autres histoires impressionnantes de notre processus interne. Comme comment manger des stroopwafels.Changelog
Nous tenons un changelog produit complet sur appsignal.com/changelog. Toutes nos nouvelles fonctionnalités, versions de l’agent et autres changements du produit peuvent être trouvés dans cette liste soigneusement organisée. Nous avons également un petit indicateur dans notre navigation supérieure qui vous notifie s’il y a une nouvelle entrée dans le changelog.Configuration
La configuration fait partie des bibliothèques s’exécutant dans les applications. Elle indique aux bibliothèques AppSignal ce qu’il faut instrumenter dans une application, de quelle application il s’agit et dans quel environnement elle s’exécute. Les bibliothèques AppSignal ont plusieurs méthodes de configuration. La méthode de configuration la plus courante est l’utilisation d’un fichier de configurationappsignal.yml.
L’utilisation des variables d’environnement est également recommandée.
Pour la configuration de l’agent Ruby, nous vous recommandons de lire le sujet
configuration pour commencer.
Utilisation du CPU
Pendant le fonctionnement d’une application, l’utilisation du CPU peut varier énormément. Certaines opérations d’une application peuvent demander plus de temps CPU que d’autres. D’autres facteurs peuvent également affecter l’utilisation du CPU. Si l’application surveillée n’est pas le seul processus sur la machine hôte, d’autres processus peuvent également affecter la métrique d’utilisation du CPU. Par exemple, si une base de données s’exécutant sur la même machine doit effectuer une requête compliquée, elle demandera plus de temps CPU. Sur AppSignal.com, l’utilisation du CPU d’une application est affichée de deux manières. Pour une action où une erreur/un problème de performance s’est produit et pour les métriques d’hôte. De cette manière, il est possible de voir si la performance d’une action a été directement affectée par un CPU occupé ou si tout l’hôte a été affecté pendant des périodes plus longues. Apprenez-en davantage sur ce que signifient les métriques CPU sur notre blog.Cross-Site Request Forgery
Le Cross-Site Request Forgery (CSRF) est une attaque qui force un utilisateur final à exécuter des actions indésirables sur une application web où il est authentifié. Une victime peut cliquer sur un lien qui lui a été envoyé par e-mail ou messagerie web, permettant à l’attaquant de voler et d’utiliser les identifiants de la victime. La gravité de l’attaque peut varier en fonction de l’application et de l’accès autorisé du compte de la victime. Un attaquant peut être en mesure de faire des actions modifiant l’état du compte d’un utilisateur, comme changer ses identifiants de connexion, et peut compromettre toute une application dans les cas graves, par exemple lorsque la victime est un administrateur.Elixir Alchemy
Vous voulez en savoir plus sur Elixir ? Dans notre série d’e-mails Elixir Alchemy (1x p/mois), nous plongeons plus profondément dans Elixir et Erlang. Vous pouvez vous inscrire ici : appsignal.com/elixir-alchemy.Environnements
La plupart des applications peuvent être exécutées dans différents modes. Pendant le développement d’une application, d’autres règles s’appliquent et les erreurs ne sont généralement pas affichées sous la forme d’une page « 500 internal server error » comme elles le sont en « production ». AppSignal comprend également le concept d’environnement permettant à différents paramètres d’être configurés par environnement. Pour chaque environnement, une application distincte est créée sur AppSignal.com pour être configurée avec son propre ensemble de règles d’alerte et d’intégrations tierces.Erreurs
Les erreurs sont des problèmes qui surviennent pendant l’exécution d’une application. Cela peut être n’importe quoi, allant d’une défaillance catastrophique provoquant le plantage de l’application à une simple faute de frappe provoquant une page d’erreur. Une fois qu’une erreur se produit dans une application, AppSignal envoie une alerte et enregistre les détails de l’erreur pour une consultation ultérieure sur AppSignal.com. Lisez-en davantage sur la fonctionnalité d’erreurs sur notre page de visite. Pour en savoir plus sur la gestion des erreurs en Ruby, lisez notre sujet Gestion des exceptions décrivant comment suivre efficacement les erreurs avec AppSignal. Les erreurs sont signalées comme des issues. En savoir plus sur ce que sont les issues.Événements
Un événement est quelque chose qui s’est passé. C’est une déclaration très vague parce que le concept d’événement est quelque chose de très haut niveau. Une erreur est un événement, et un problème de performance en est un également. AppSignal surveille de nombreux événements à l’intérieur d’une application et sur un serveur en utilisant les métriques d’hôte. En collectant de nombreux types d’événements différents et en combinant les données, nous espérons fournir une image aussi complète que possible pour obtenir plus d’informations sur la performance des applications. Voir aussi documentation sur les événements d’instrumentation.Extension
Les bibliothèques AppSignal et l’agent sont en communication constante entre eux. Les bibliothèques envoient les données à l’agent via un socket UNIX. Pour ce faire, les bibliothèques utilisent une extension pour le langage de programmation dans lequel elles sont écrites. Cette extension est écrite en C et Rust, et installée lorsque l’agent spécifique au langage est installé. Lisez-en davantage sur la façon dont l’extension AppSignal fonctionne et le cycle de vie d’une requête AppSignal.Impact
L’impact d’une action sur une application est basé sur son utilisation comparée à d’autres actions. Quand une action de contrôleur ou une tâche prend plus de temps ou est exécutée plus souvent que d’autres, son impact grandit. Par exemple :- L’action A est déclenchée 1000 fois avec une durée moyenne de 0,5 seconde. La durée combinée est de 500 secondes.
- L’action B est déclenchée 500 fois avec une durée moyenne de 3 secondes. La durée combinée est de 1500 secondes.
- L’action A a un impact de 25 % (500 / 2000).
- L’action B a un impact de 75 % (1500 / 2000).
Instrumentation
L’instrumentation est ce qui alimente AppSignal. Sans elle, nous ne saurions rien sur ce qui se passe à l’intérieur des applications. L’instrumentation consiste en des hooks à l’intérieur ou autour des frameworks et bibliothèques qu’AppSignal utilise pour surveiller le code d’application. Cette instrumentation rapporte les erreurs et le code lent qui sont envoyés à AppSignal pour analyse. Une fois qu’un problème est détecté, une alerte est envoyée. Apprenez-en davantage sur l’instrumentation Ruby.Événements d’instrumentation
Les événements sont des blocs de code qui sont exécutés. Ceux-ci peuvent être des méthodes, des fonctions ou des parties plus petites de l’une ou l’autre. Les événements peuvent être imbriqués pour montrer la hiérarchie et la durée totale des opérations. Ces événements individuels permettent de voir quelles parties du code sont plus lentes que d’autres. En haut des pages d’issues, nous groupons également les durées d’événements par nom de groupe, en suivant notre dénomination d’événements, pour donner des aperçus sur quelle partie de l’application prend le plus de temps. Certains types d’événements qui peuvent être affichés sont les requêtes de base de données, l’analyse JSON, le rendu de vues, les requêtes HTTP, l’instrumentation personnalisée, etc. Chaque événement est affiché sur les pages de détail des problèmes de performance dans la « chronologie de performance ». Si nous détectons que le même événement est répété plus d’une fois successivement, nous les marquerons comme des événements N+1 potentiels, tels que des requêtes N+1. Voir aussi instrumentation.Issues
Chaque fois qu’AppSignal détecte une nouvelle erreur, une issue est créée. Chaque fois qu’AppSignal détecte une nouvelle requête potentiellement lente, une tâche en arrière-plan, etc., une nouvelle issue est créée. Cette issue est groupée par action, namespace et erreur. Les issues d’erreur prennent également en charge les erreurs sans action, car une erreur peut survenir en dehors d’une action, par exemple dans le framework de l’application avant d’atteindre le propre code de l’application. Les issues de performance sans action sont silencieusement ignorées. L’action, le namespace et le type d’erreur sont la façon dont nous groupons les issues. Si une erreur d’un nouveau type se produit sur la même action dans le même namespace qu’une autre issue d’erreur, une nouvelle issue sera créée pour cette erreur. Si une autre requête potentiellement lente est détectée sur un autre endpoint ou une autre tâche en arrière-plan, une nouvelle issue sera créée pour ce endpoint/cette tâche. Par issue, il est possible de configurer les paramètres de notification, l’assignation, l’état (ouvert/fermé/en cours), et la gravité.Bibliothèques
AppSignal utilise des bibliothèques spécifiques au langage pour surveiller les applications. Nous avons actuellement une gem Ruby et un package Elixir. Ces bibliothèques incluent des hooks dans les frameworks et bibliothèques pour instrumenter des blocs de code tels que les appels à la base de données, les appels au système de fichiers et le rendu de vues. Chaque bibliothèque est spécialisée dans l’instrumentation de son langage cible. La plupart des bibliothèques AppSignal incluent également un « agent » que les bibliothèques utilisent pour communiquer avec les serveurs AppSignal. Lisez-en davantage sur la façon dont l’agent AppSignal fonctionne et le cycle de vie d’une requête AppSignal.Intégrations de bibliothèques
Les bibliothèques AppSignal s’intègrent à diverses bibliothèques et frameworks différents spécifiques au langage de programmation. La gem Ruby s’intègre avec Ruby pur, Rails, Sinatra et d’autres frameworks disponibles. Le package Elixir s’intègre avec Elixir pur et Phoenix. Ces intégrations automatiques facilitent l’obtention d’un meilleur aperçu des applications sans avoir à ajouter manuellement de l’instrumentation AppSignal. Lisez-en davantage sur les intégrations Ruby que nous offrons.Marqueurs
Les marqueurs sont de petites icônes utilisées dans les graphiques sur AppSignal.com pour indiquer un changement. Cela peut être un déploiement de code utilisant un « marqueur de déploiement » ou un événement spécial avec un « marqueur personnalisé ». Ces marqueurs personnalisés peuvent être n’importe quoi, des opérations de mise à l’échelle, des pics soudains de trafic ou lorsqu’une base de données rencontre des problèmes. Lisez-en davantage sur les marqueurs.Métadonnées
Les métadonnées sont des données qui donnent des informations sur d’autres données. Les métadonnées sont des informations sur une erreur ou un problème de performance qui fournissent plus de contexte aux données collectées. En envoyant des métadonnées supplémentaires sur un échantillon, il est plus facile de retrouver les circonstances entourant le problème particulier. Par défaut, les métadonnées d’une requête incluent le nom d’hôte sur lequel le problème s’est produit, la révision SCM sur laquelle l’application s’exécute, et l’ID de requête de la requête à partir de laquelle l’échantillon a été dérivé. Elles incluent également des données telles que le chemin de requête et la méthode de requête pour les requêtes web.Métriques
AppSignal fournit deux types de métriques. Les métriques personnalisées permettent la collecte de données à partir de presque n’importe quoi. Avec quelques lignes de code, il est possible de suivre et de représenter graphiquement des données telles que le nombre d’utilisateurs enregistrés, les visites d’une page, les tailles de bases de données, etc. Les métriques d’hôte concernent les données du serveur sur lequel une application s’exécute. Des données telles que l’utilisation du CPU, les charges moyennes, l’utilisation de la mémoire, etc., donnent plus d’informations sur les problèmes de performance que le code lui-même. Peut-être l’espace disque est-il en train de s’épuiser, ce qui ralentit considérablement l’application. Lisez-en davantage sur les métriques sur notre page de visite.Namespace
Les namespaces sont des mécanismes de regroupement utilisés par AppSignal pour différencier les différentes parties de la même application. Par défaut, AppSignal divise une application en deux namespaces : « Web » et « Background ». Les requêtes HTTP surveillées par AppSignal seront ajoutées au namespace « Web » et les tâches effectuées par les bibliothèques de tâches en arrière-plan sont ajoutées au namespace « Background ». Il est également possible de configurer vos namespaces pour différencier les requêtes sur une application et un panneau d’administration privé. Pour plus d’informations sur les namespaces, veuillez consulter notre documentation sur les namespaces.Notifications
AppSignal envoie des notifications chaque fois qu’un problème est détecté avec une application. Ces notifications peuvent être des messages e-mail, des messages Slack, une notification PagerDuty, et plus encore selon les intégrations tierces configurées. Nous envoyons des notifications sur les erreurs, les requêtes lentes et les alertes de détection d’anomalies qui surviennent dans une application utilisant une bibliothèque AppSignal. Une fois qu’un événement problématique est détecté, une notification est envoyée pour alerter les utilisateurs d’un problème.Organisations
Les organisations sont utilisées pour regrouper les applications et les utilisateurs pour une entreprise. Une entreprise peut avoir de nombreux utilisateurs et clients qui peuvent être notifiés chaque fois qu’il y a un problème avec leurs applications. La facturation pour les applications est effectuée au niveau de l’organisation plutôt que par application. La gestion d’équipe est facilitée grâce aux organisations. Des équipes entières peuvent être invitées à une organisation, il n’est donc pas nécessaire de partager les détails de connexion. Lisez-en davantage sur les organisations dans notre documentation Organisations.Propriétaires
Les organisations ont des personnes qui gèrent l’organisation. Ces propriétaires décident qui est membre d’une organisation, à quelle équipe ils appartiennent ou non, et décident de la façon dont la facturation est effectuée. Les propriétaires d’organisation peuvent gérer tout ce qui concerne une organisation et les applications qui lui appartiennent. Si vous n’avez pas la permission de voir ou de modifier quelque chose, demandez au propriétaire de votre organisation de le modifier pour vous ou de vous donner plus de permissions.Problèmes de performance
L’utilisation du monitoring de performance permet de plonger dans les requêtes individuelles et de voir quelles parties d’une application sont lentes. En utilisant ces informations, il est possible de trouver et d’améliorer les zones problématiques. Lorsqu’AppSignal détecte une requête web ou une opération lente, il enverra des notifications, car le code lent peut être aussi dommageable qu’une erreur apparaissant. Les problèmes de performance sont groupés par action et namespace. Sur les pages de détail des problèmes de performance, plus d’informations sont disponibles sur chaque action. Toutes les issues ne sont pas des « issues ». C’est à vous de déterminer si une requête HTTP de 200 ms est trop lente. Les requêtes potentiellement lentes et les tâches en arrière-plan sont signalées comme problèmes de performance. En savoir plus sur ce que sont les issues. Lisez-en davantage sur la fonctionnalité de performance sur notre page de visite.API Push
L’« API Push » d’AppSignal est l’endpoint API utilisé par l’agent AppSignal pour envoyer les données collectées. Ceci est différent de l’API AppSignal normale qui est principalement utilisée pour lire les données et ajouter plus de contexte aux données envoyées à AppSignal. Cette API Push est l’API où l’instrumentation des applications est envoyée depuis les applications utilisant la clé API Push.Clé API Push
La « clé API Push » est une clé API en écriture seule utilisée par les applications pour s’authentifier lors de l’envoi de données aux serveurs AppSignal. Les applications rapportent les données à l’API Push et s’authentifient à l’aide de cette clé. Il existe plusieurs types de clés API Push que les applications peuvent utiliser pour différents cas d’usage. Toutes les clés API Push peuvent être trouvées sur la page des paramètres Push & deploy.- Clé API Push au niveau de l’organisation : La clé API Push recommandée pour les intégrations back-end, comme Ruby, Elixir, Node.js, Python et Go. Nous reconnaissons les applications par une combinaison de la clé API Push, du nom de l’application et de l’environnement de l’application, et créons les applications à l’aide de ces informations si elles n’existent pas encore.
- Clé API Push au niveau de l’app : Après création, une application reçoit également sa clé API Push au niveau de l’app. Cette clé peut être utilisée pour envoyer des données à une application spécifique, même si l’application est configurée pour utiliser un nom d’app ou un environnement d’app différent. Ceci est utilisé lors du déplacement d’apps entre organisations sans perte de données, ou lorsqu’aucun nom d’app ou environnement d’app ne peut être défini, comme pour l’intégration Vector.
- Clé API Front-end : Cette clé est utilisée par les applications utilisant notre intégration front-end pour rapporter les données et peut être trouvée dans la section « Front-end error monitoring ».