Sprachbibliotheken
Die AppSignal-Sprachbibliotheken (Ruby, Elixir, JavaScript für Frontend) sammeln Transaktions- und Metrikdaten. Transaktionen sind HTTP-Anfragen, Background-Jobs und andere benutzerdefinierte Transaktionen. Metrikdaten basieren auf den Transaktionsdaten, können aber auch mit unseren Custom Metrics gesetzt werden. Jede eingehende HTTP-Anfrage oder jeder Background-Job wird in eine “Transaktion” eingebettet. Diese Transaktion sammelt alle Instrumentierungen, die während der Anfrage generiert werden, dazu gehören Events, Parameter, Session-Daten und Tags. Wenn Ihre App die Anfrage bearbeitet hat, wird die Transaktion geschlossen und an unseren Agent gesendet und in eine Warteschlange gestellt. Diese Warteschlange besteht aus Transaktions- und Metrikdaten. Der AppSignal Agent überträgt diese Transaktions- und Metrikdaten in kombinierten Payloads alle 30 Sekunden an die Push-API. Das Übertragungsintervall für App-Instanzen findet nicht alle zur exakt gleichen Zeit statt. Wann genau der Agent Daten überträgt, basiert darauf, wann innerhalb einer Minute der Agent gestartet wurde. Das bedeutet, dass Daten für dieselbe Sekunde auf zwei verschiedenen App-Instanzen etwa 30 Sekunden auseinander ankommen können, ohne Wiederholungen mit einzubeziehen. Das ist der Grund, warum AppSignal eventuell konsistent ist. Lesen Sie mehr darüber, wie die Sprachbibliotheken, unsere Erweiterung und der Agent zusammenarbeiten, um die Daten von Ihrer App zu den AppSignal-Servern zu bringen, auf der Seite Wie unsere Integrationen funktionieren.Push-API
Unsere Push-API hat nur einen Zweck: Daten von Apps zu empfangen und sie so schnell und effizient wie möglich in eine Warteschlange zu stellen. Von hier aus beginnen unsere Prozessoren, die Transaktions- und Metrikdaten von den Apps zu verarbeiten.Verarbeitung
Der AppSignal-Prozessor speichert neue Samples für Fehler- und Performance-Messungen basierend auf den Transaktionen, erstellt neue Vorfälle oder aktualisiert bestehende Vorfälle, erstellt Metriken basierend auf den Transaktionsdaten und verarbeitet benutzerdefinierte Metriken. Während dieses Prozesses erkennen wir auch Änderungen in Metriken, die in Anomaly Detection Triggern angegeben sind, um neue und laufende Warnungen zu erstellen und darüber zu benachrichtigen. Lesen Sie mehr darüber, wie dies geschieht, im Abschnitt Anomaly Detection. Die verarbeiteten Daten werden dann in unseren Daten-Buckets gespeichert. Dies ist zwischen minütlichen und stündlichen Metrik-Buckets für Ihre Organisation aufgeteilt. Wir speichern Daten in der minütlichen Auflösung bis zu 12 Stunden, danach sind sie weiterhin in der stündlichen Auflösung verfügbar. Schließlich, wenn die gesamte Verarbeitung abgeschlossen ist, senden wir Benachrichtigungen für neue Fehler, neue Performance-Messungen, Deploys und Anomaly Detection-Warnungen aus.Anomaly Detection
Wenn Metrikdaten in unseren Prozessoren ankommen oder von unseren Prozessoren erstellt werden, werden sie nicht sofort verwendet, um Anomaly Detection-Trigger zu verarbeiten, um Warnungen zu erstellen oder zu aktualisieren. Die AppSignal-Prozessoren warten bis zu 180 Sekunden (3 Minuten), bevor sie Daten für eine Minute verarbeiten. Diese Verzögerung entspricht etwa der gleichen maximalen Verzögerung [1], die es dauert, bis Metriken in Grafiken auf AppSignal.com erscheinen. Lesen Sie weiter, um zu erfahren, warum diese Verarbeitungsverzögerung besteht.Übertragung der Daten
Wie Transaktionsdaten von Sprachbibliotheken durchlaufen Metrikdaten mehrere Systeme, um auf unseren Servern anzukommen. Dieser Prozess braucht Zeit. Unser Prozessor muss nach Ablauf einer Minute auf das Übertragungsintervall des AppSignal Agents warten, bevor er Daten für diese Minute verarbeiten kann.Uhrenabweichung auf App-Servern
Lesen Sie mehr darüber, wie AppSignal mit Zeit umgeht, was Uhrenabweichung ist und wie Sie die NTP-Synchronisation einrichten, auf unserer Seite Über Zeit.Verarbeitung von Metrikdaten
Nach einer Wartezeit von bis zu 180 Sekunden (3 Minuten) stellt der Prozessor fest, dass alle Daten für eine Minute vorhanden sind, und beginnt mit der Verarbeitung von Triggern und der Erstellung oder Aktualisierung von Warnungen. Er schaut 180 Sekunden (3 Minuten) zurück, seit die letzten Daten für eine Anwendung angekommen sind. Daten, die älter sind, werden für die Verarbeitung von Triggern und Warnungen in diesem Verarbeitungstakt ignoriert. Wenn der Prozessor die Verarbeitung der Metriken für eine Minute abgeschlossen hat, beginnt er kurz danach, Benachrichtigungen für neue, laufende und geschlossene Warnungen zu senden. Diese Verzögerung weiter zu verlängern, würde auch bedeuten, dass Benachrichtigungen später ankommen. Diese Verzögerung zu verkürzen, würde bedeuten, dass wir Daten für eine Minute verpassen könnten, sodass Warnungen und Benachrichtigungen über unvollständige Metrikdaten bereitgestellt würden.Fazit
Es kann bis zu 90 Sekunden dauern, bis Transaktions- und Metrikdaten erscheinen. Dies ist ein Worst-Case-Szenario. Wenn sie nach dieser Zeit nicht erschienen sind, ist irgendwo in der Übertragungs- oder Verarbeitungspipeline etwas schiefgelaufen. Es dauert 180 Sekunden (3 Minuten), bis Metrikgrafiken und Anomaly Detection-Warnungen erstellt/aktualisiert werden. Wir versuchen ständig, diese Zeit zu minimieren, müssen aber die Anzahl der Anfragen, die unsere Push-API empfängt, und die Datengröße jeder Anfrage mit der Verarbeitungsgeschwindigkeit abwägen. Wenn Sie mehr über dieses Thema erfahren möchten, zögern Sie nicht, uns zu kontaktieren![1] Diese Zeit berücksichtigt keine Wiederholungen der Datenübertragung von App-Servern. Daten, deren Übertragung fehlgeschlagen ist, z. B. weil ein Server seine Internetverbindung verloren hat, werden von unserem Agent bis zu 30 Minuten lang wiederholt. ↩