> ## Documentation Index > Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt > Use this file to discover all available pages before exploring further. # Terminologie Chez AppSignal, nous utilisons de nombreux termes techniques. Lisez la suite pour en apprendre davantage sur le langage d'AppSignal. Consultez la liste de la terminologie sur le côté droit de cette page. ## 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 que `BlogPostsController#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](#issues) avec le [namespace](#namespace) et l'[erreur](#errors). ## 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](/metrics/host-metrics). L'agent est démarré par la [bibliothèque](#libraries) 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](#extension). Les données d'instrumentation de transaction collectées par l'agent sont envoyées aux serveurs AppSignal. Les données de [transaction](#transactions) 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](/appsignal/how-appsignal-operates) et le [cycle de vie d'une requête AppSignal](/appsignal/data-life-cycle). ## 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](#transactions). 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](/anomaly-detection/) 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](#markers). L'API diffère de l'[API Push](#push-api) dans son objectif. Alors que l'API Push est utilisée pour envoyer des données à AppSignal par l'[agent](#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](/api). ## Clé API Pour se connecter à l'[API](#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](https://appsignal.com/users/edit). Cette clé ne doit pas être confondue avec la [clé API Push](#push-api-key) qui est utilisée par les [applications](#applications) avec un [agent](#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](#libraries) 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](#environments) 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 Plusieurs applications peuvent exister dans une [organisation](#organizations). Lisez-en davantage sur les applications dans notre [documentation Applications](/application). ## 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](#stroopwafels). | | `Appsignal` | Le nom de bibliothèque de nos intégrations AppSignal ([intégration Ruby](/ruby), [intégration Elixir](/elixir), [intégration Node.js](/nodejs/3.x/), [intégration Front-end](/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](https://rubygems.org/gems/appsignal), le préfixe du [package Elixir et des packages](https://hex.pm/packages/appsignal), le préfixe des [packages Node.js](https://www.npmjs.com/package/@appsignal/nodejs) et le préfixe des [packages Front-end](https://www.npmjs.com/package/@appsignal/javascript), etc. | ## Blog Nous avons un blog à [blog.appsignal.com](https://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](#ruby-magic) et d'autres histoires impressionnantes de notre processus interne. Comme [comment manger des stroopwafels](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Changelog Nous tenons un changelog produit complet sur [appsignal.com/changelog](https://www.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](#libraries) AppSignal ce qu'il faut instrumenter dans une [application](#applications), 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 configuration `appsignal.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](/ruby/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](https://blog.appsignal.com/2018/03/06/understanding-cpu-statistics.html) 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](https://blog.appsignal.com/elixir-alchemy). ## Environnements La plupart des [applications](#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](#third-party-integrations). ## 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](https://www.appsignal.com/tour/errors) sur notre page de visite. Pour en savoir plus sur la gestion des erreurs en Ruby, lisez notre sujet [Gestion des exceptions](/ruby/instrumentation/exception-handling) 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](#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](#errors) est un événement, et un [problème de performance](#performance-issues) 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](#metrics). 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](#applications). Voir aussi [documentation sur les événements d'instrumentation](#instrumentation-events). ## Extension Les [bibliothèques](#libraries) AppSignal et l'[agent](#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](/appsignal/how-appsignal-operates) et le [cycle de vie d'une requête AppSignal](/appsignal/data-life-cycle). ## 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. La durée totale combinée des deux actions est de 2000 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](/ruby/instrumentation). ## É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](#issues), nous groupons également les durées d'événements par nom de groupe, en suivant [notre dénomination d'événements](/api/event-names), 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](#instrumentation), 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](#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](#actions), [namespace](#namespace) et [erreur](#errors). 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](#actions) sont silencieusement ignorées. L'action, le [namespace](#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](/ruby) et un package [Elixir](/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](#agent) » que les bibliothèques utilisent pour communiquer avec les serveurs AppSignal. Lisez-en davantage sur la façon dont l'[agent AppSignal fonctionne](/appsignal/how-appsignal-operates) et le [cycle de vie d'une requête AppSignal](/appsignal/data-life-cycle). ### 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](#instrumentation) AppSignal. Lisez-en davantage sur les [intégrations Ruby que nous offrons](/ruby/integrations). ## 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](/application/markers). ## 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](#samples), 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. * [Métriques personnalisées](/metrics/custom) * [Métriques d'hôte](/metrics/host-metrics) 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](#cpu-usage), 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](https://www.appsignal.com/tour/metrics) 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](/application/namespaces). ## Notifications AppSignal envoie des notifications chaque fois qu'un problème est détecté avec une [application](#applications). Ces notifications peuvent être des messages e-mail, des messages Slack, une notification PagerDuty, et plus encore selon les [intégrations tierces](#third-party-integrations) configurées. Nous envoyons des notifications sur les [erreurs](#errors), les [requêtes lentes](#performance-issues) et les alertes de [détection d'anomalies](/anomaly-detection/) qui surviennent dans une application utilisant une [bibliothèque](#libraries) 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](#applications) et les [utilisateurs](#user-account) 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](/support/billing) pour les applications est effectuée au niveau de l'organisation plutôt que par application. La [gestion d'équipe](/organization/team/members) 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](/organization). ## Propriétaires Les [organisations](#organizations) ont des personnes qui gèrent l'organisation. Ces propriétaires décident qui est membre d'une organisation, à quelle [équipe](#teams) 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](#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](#errors) apparaissant. Les problèmes de performance sont groupés par [action](#actions) et [namespace](#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](#issues). Lisez-en davantage sur la [fonctionnalité de performance](https://www.appsignal.com/tour/performance) sur notre page de visite. ## API Push L'« API Push » d'AppSignal est l'endpoint API utilisé par l'[agent](#agent) AppSignal pour envoyer les données collectées. Ceci est différent de l'[API](#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](#push-api-key). ## 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](#push-api) 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](https://appsignal.com/redirect-to/app?to=info). * **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](/application/configuration), 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](/vector). * **Clé API Front-end :** Cette clé est utilisée par les applications utilisant notre [intégration front-end](/front-end) pour rapporter les données et peut être trouvée dans la section « Front-end error monitoring ». Note : Ces clés en écriture seule ne doivent pas être confondues avec la [clé API](#api-key) spécifique à l'utilisateur qui peut être utilisée pour s'authentifier sur l'[API AppSignal](#api) pour récupérer des données sur vos applications depuis notre système. ## Temps de réponse Le temps de réponse de l'action d'une application est le temps passé à traiter l'action. Plus une action met de temps à s'exécuter, plus elle se qualifie comme problème de performance. La durée de cette action est affichée sur AppSignal.com pour les problèmes de performance et dans les graphiques pour les contrôleurs/tâches et au niveau de l'hôte. ## Ruby Magic Saviez-vous que nous écrivons des articles sur la magie qu'est Ruby ? Oui ! Cela s'appelle Ruby Magic et vous pouvez vous y inscrire sur [appsignal.com/ruby-magic](https://blog.appsignal.com/ruby-magic). Une liste de tous les articles Ruby Magic que nous avons écrits jusqu'à présent peut être trouvée sur [notre blog](https://blog.appsignal.com/). ## Échantillons Quand une page est lente cent fois de suite, il n'est pas aussi pertinent de voir toutes les requêtes lentes, un échantillon plus petit de ces requêtes raconte la même histoire. Au lieu de cela, l'[agent](#agent) AppSignal n'envoie qu'un petit ensemble de problèmes de performance aux serveurs AppSignal. Cela économise les données envoyées aux serveurs, les données traitées sur l'hôte de l'application et les serveurs AppSignal, tout en racontant toujours la même histoire sur les problèmes. ## Stroopwafels Aussi écrit « stroopwaffles ». Chez AppSignal, nous adorons les stroopwafels. Nous en avons expédié plus de 25 000 à des clients, des amis et des conférences. Si vous travaillez dans une entreprise tech et avez eu un stroopwafel au bureau, il y a des chances qu'il vienne de nous. Nous avons écrit tout un article sur ce que sont les stroopwafels et comment vous devriez les manger. Lisez la suite pour [devenir un expert en stroopwafels](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Tags Les [échantillons](#samples) d'erreurs et de problèmes de performance peuvent être tagués. En taguant ces échantillons, il est plus facile de trouver et d'identifier certaines issues. En taguant, il est possible d'ajouter plus de [métadonnées](#metadata) à un échantillon qui peut être utilisé dans les [modèles de liens](/application/link-templates) pour facilement créer un lien vers les données pertinentes dans votre application. Lisez-en davantage sur le [tagging des requêtes](/guides/tagging). ## Équipes Pour gérer les membres des [organisations](#organizations), les propriétaires d'organisations peuvent utiliser les équipes pour donner accès aux applications. Les [utilisateurs](#user-account) qui sont membres d'une équipe ne peuvent accéder qu'aux applications auxquelles l'équipe à laquelle ils appartiennent a accès. Si un utilisateur fait partie de plusieurs équipes, cet utilisateur peut accéder à toutes les applications de toutes les équipes auxquelles il appartient. Les équipes donnent une gestion des permissions aux [propriétaires](#owners) d'une organisation pour limiter l'accès des utilisateurs aux applications sans nécessiter plusieurs organisations. Lisez-en davantage sur la [gestion d'équipe](/organization/team/teams) d'organisation. ## Intégrations tierces AppSignal.com fournit des connexions avec d'autres services tels que Slack et PagerDuty pour alerter plus efficacement les utilisateurs des problèmes détectés. Ces intégrations peuvent être gérées via l'interface utilisateur sur AppSignal.com sur une base application par application. Lisez-en davantage sur [quelles intégrations tierces nous offrons](/application/integrations/). ## Transactions Les transactions sont créées par les [bibliothèques](#libraries) AppSignal pour chaque requête web surveillée et tâche en arrière-plan. Au sein de cette transaction, les agents surveillent les erreurs et le code lent. Une transaction est créée au début d'une requête web ou lorsqu'une tâche en arrière-plan est démarrée. Une fois que la requête ou la tâche se termine ou plante, la transaction est fermée et envoyée à l'[agent](#agent) pour traitement. Les [tags](#tags) et les [métadonnées](#metadata) sont ajoutés au niveau de la transaction pour plus facilement identifier les différences entre les échantillons de transactions. ## Throughput Le throughput d'une application est le nombre total de requêtes envoyées à travers une action/tâche dans un laps de temps donné. Le throughput peut différer par action et par hôte. Sur AppSignal.com, le throughput est affiché par action et affiché dans les graphiques pour chaque hôte. ## TLS TLS signifie Transport Layer Security. TLS est un protocole cryptographique qui fournit des connexions sécurisées pour les réseaux informatiques, par exemple, entre un serveur et un navigateur web. ## Temps d'attente en file Lorsqu'un serveur ou une application est occupé à traiter de nombreuses requêtes, certaines requêtes peuvent être mises en file d'attente avant d'être traitées. Le temps d'attente avant d'être traité est appelé « temps d'attente en file ». Étant donné que le temps d'attente en file peut affecter négativement l'expérience utilisateur lors de l'utilisation d'une application, cette métrique est suivie par AppSignal pour les requêtes HTTP et les tâches en arrière-plan. Pour les tâches en arrière-plan, ceci représente le temps entre la mise en file de la requête (par une requête web) et sa prise en charge par le worker en arrière-plan (sidekiq). ## Compte utilisateur Chaque utilisateur d'AppSignal a un compte utilisateur. Avec ce compte utilisateur, vous pouvez configurer les préférences de notification. De nombreux utilisateurs peuvent appartenir à une ou plusieurs organisations. Pas besoin de comptes utilisateur séparés pour chaque organisation. Les [organisations](#organizations) gèrent quels utilisateurs peuvent accéder à quelles applications et qui peut gérer la facturation en tant que [propriétaire](#owners).