> ## 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. # Le cycle de vie des données d'application De nombreux composants travaillent ensemble pour acheminer les données des applications sur vos serveurs vers les serveurs d'AppSignal et enfin dans un format lisible sur AppSignal.com. Cette page décrira le processus que les données des applications suivent pour devenir des données d'incidents, des entrées dans des tableaux, des points dans des graphiques, des alertes pour la [détection d'anomalies](/anomaly-detection) et des notifications. AppSignal est éventuellement cohérent. Cela signifie que, bien que nous essayions de minimiser cela, il existe une durée arbitraire entre une requête, une tâche en arrière-plan ou une donnée de métrique enregistrée dans une application et l'affichage de ces données sur AppSignal.com. Les requêtes qui sont envoyées plus tard que d'autres apparaîtront en premier sur AppSignal.com. En décomposant le processus, nous pouvons vous dire pourquoi cela se produit. ## Bibliothèques de langage Les bibliothèques de langage AppSignal ([Ruby](/ruby), [Elixir](/elixir), [JavaScript pour Front-end](/front-end)) collectent les données de transaction et de métriques. Les [transactions](/appsignal/terminology#transactions) sont des requêtes HTTP, des tâches en arrière-plan et d'autres transactions personnalisées. Les données de métriques sont basées sur les données de transaction mais peuvent également être définies à l'aide de nos [métriques personnalisées](/metrics/custom). Chaque requête HTTP entrante, ou tâche en arrière-plan, est encapsulée dans une « transaction ». Cette transaction collecte toute l'instrumentation générée pendant la requête, y compris les événements, les paramètres, les données de session et les tags. Lorsque votre application a servi la requête, la transaction est fermée et envoyée à notre agent puis placée dans une file d'attente. Cette file d'attente est composée de données de transaction et de métriques. L'[agent AppSignal](/appsignal/terminology#agent) transmet ces données de transaction et de métriques dans des charges utiles combinées toutes les 30 secondes à l'[API Push](#push-api). L'intervalle de transmission pour les instances d'application ne se produisent pas tous au même moment exact. Quand exactement l'agent transmet les données dépend du moment dans la minute où l'agent a été démarré. Cela signifie que les données pour la même seconde sur deux instances d'application différentes peuvent arriver à environ 30 secondes d'intervalle, sans inclure les nouvelles tentatives. C'est la raison pour laquelle AppSignal est éventuellement cohérent. Lisez-en davantage sur la façon dont les bibliothèques de langage, notre extension et l'agent fonctionnent ensemble pour acheminer les données de votre application vers les serveurs AppSignal sur la page [Comment nos intégrations fonctionnent](/appsignal/how-appsignal-operates). ## API Push Notre API Push n'a qu'un seul but : recevoir des données des applications et les pousser dans une file d'attente aussi rapidement et efficacement que possible. À partir de là, nos processeurs commencent à traiter les données de transaction et de métriques des applications. ## Traitement Le processeur AppSignal stockera de nouveaux échantillons pour les erreurs et les mesures de performance basés sur les transactions, créera de nouveaux incidents ou mettra à jour les incidents existants, créera des métriques basées sur les données de transaction et traitera les métriques personnalisées. Durant ce processus, nous détectons également les changements dans les métriques spécifiées dans les Déclencheurs de détection d'anomalies pour créer et notifier au sujet d'alertes nouvelles et en cours. Lisez-en davantage sur la façon dont cela est fait dans la section [Détection d'anomalies](#anomaly-detection). Les données traitées sont ensuite stockées dans nos buckets de données. Cela est réparti entre les buckets de métriques par minute et par heure pour votre organisation. Nous stockons les données dans la résolution par minute pendant jusqu'à 12 heures, après quoi elles sont toujours disponibles dans la résolution horaire. Enfin, lorsque tout le traitement est terminé, nous envoyons des [notifications](/application/integrations/) pour les nouvelles erreurs, les nouvelles mesures de performance, les déploiements et les alertes de [détection d'anomalies](#anomaly-detection). ### Détection d'anomalies Lorsque les données de métriques arrivent dans nos processeurs, ou sont créées par nos processeurs, elles ne sont pas immédiatement utilisées pour traiter les Déclencheurs de [détection d'anomalies](/anomaly-detection) pour créer ou mettre à jour les alertes. Les processeurs AppSignal attendent jusqu'à *180 secondes* (3 minutes) avant de traiter les données pour une minute. Ce délai correspond à peu près au même délai maximum \[1] qu'il faut pour que les métriques apparaissent dans les graphiques sur AppSignal.com. Continuez à lire pour comprendre pourquoi ce délai de traitement est présent. #### Transmission des données Comme les données de transaction des bibliothèques de langage, les données de métriques passent par plusieurs systèmes pour aboutir à nos serveurs. Ce processus prend du temps. Notre processeur doit attendre l'intervalle de transmission de l'agent AppSignal après qu'une minute s'est écoulée, avant de pouvoir traiter les données pour cette minute. #### Décalage d'horloge sur les serveurs d'application Lisez-en davantage sur la façon dont AppSignal gère le temps, ce qu'est le décalage d'horloge et comment configurer la synchronisation NTP sur notre [page sur le temps](/support/about-time). #### Traitement des données de métriques Après avoir attendu jusqu'à *180 secondes* (3 minutes), le processeur détermine que toutes les données pour une minute sont présentes, et il commencera à traiter les déclencheurs et à créer ou mettre à jour les alertes. Il regardera *180 secondes* (3 minutes) en arrière depuis l'arrivée des dernières données pour une application. Les données plus anciennes seront ignorées pour le traitement des déclencheurs et des alertes lors de ce cycle de traitement. Lorsque le processeur a terminé de traiter les métriques pour une minute, il commencera à envoyer des notifications peu de temps après pour les alertes nouvelles, en cours et fermées. Étendre ce délai plus longtemps signifierait également que les notifications arrivent plus tard. Réduire ce délai signifierait que nous pourrions manquer des données pour une minute en fournissant des alertes et des notifications sur des données de métriques incomplètes. ## Conclusion Cela peut prendre jusqu'à *90 secondes* pour que les données de transaction et de métriques apparaissent. Il s'agit d'un scénario du pire cas. Si elles ne sont pas apparues après ce délai, quelque chose s'est mal passé quelque part dans le pipeline de transmission ou de traitement. Il faut *180 secondes* (3 minutes) pour que les graphiques de métriques et les alertes de détection d'anomalies soient créés/mis à jour. Nous essayons constamment de minimiser ce temps, mais nous devons équilibrer la quantité de requêtes que notre API Push reçoit et la taille des données de chaque requête avec la vitesse de traitement. Si vous souhaitez en savoir plus sur ce sujet, n'hésitez pas à [nous contacter](mailto:support@appsignal.com) ! ***
\[1] Ce temps ne tient pas compte des nouvelles tentatives de transmission des données depuis les serveurs d'application. Les données dont la transmission a échoué, par exemple parce qu'un serveur a perdu sa connexion Internet, seront retransmises pendant jusqu'à 30 minutes par notre agent. ↩