Zum Hauptinhalt springen
AppSignal besteht aus vielen verschiedenen Systemen, die zusammenarbeiten. Diese Seite erklärt, welche Systeme Teil der Integrationen sind, die wir für Ruby und Elixir ausliefern, und wie sie zusammenarbeiten.

​
Sprachbibliotheken

Das AppSignal Ruby-Gem und das Elixir-Paket bieten Integration für ihre jeweilige Programmiersprache und beliebte Bibliotheken (für Ruby und Elixir) aus ihrem Ökosystem, um Fehlerberichterstattung und Performance-Einblicke bereitzustellen. Derzeit ist es erforderlich, eine dieser Bibliotheken zu verwenden, um AppSignal in Ihre App zu integrieren und Host-Metriken von seinem Host zu sammeln. Wenn Sie das AppSignal Ruby-Gem und das Elixir-Paket in Ihrer App installieren, wird daneben eine native Erweiterung für die Programmiersprache kompiliert. Diese Erweiterung kommuniziert mit dem Agent, um Ihre Daten effizient zu verarbeiten und an die AppSignal Push-API zu senden. Wenn Sie Ihre Anwendung mit installiertem AppSignal starten, wird der AppSignal Agent im Hintergrund gestartet. Es wird nur ein Agent pro Konfiguration gestartet; wenn eine neue Konfiguration gefunden wird, startet ein neuer Agent, und die Agents für andere Versionen werden heruntergefahren.

​
Erweiterung

Die AppSignal-Erweiterung kommuniziert zwischen der Programmiersprache und dem AppSignal Agent. Ein Teil ist in Rust und der andere in der Programmiersprache C geschrieben. Die Host-Maschine, auf der AppSignal installiert ist, benötigt daher einen funktionierenden C-Compiler. Normalerweise ist dieser bereits auf der Host-Maschine installiert, aber bei vielen Docker-Images ist dies oft nicht der Fall, um die Images klein zu halten. Die erforderlichen Pakete für Ihr Betriebssystem sind auf unserer Seite Unterstützte Betriebssysteme aufgeführt. Die AppSignal-Erweiterung besteht aus zwei Teilen: der C-Erweiterung und der statischen/dynamischen Bibliothek, die in Rust geschrieben ist. Die C-Erweiterung für Ruby und das Nif für Elixir implementieren die AppSignal-Bibliotheksschnittstelle, sodass die AppSignal-Sprachbibliothek damit kommunizieren kann. Eine separate Bibliothek wird verwendet, damit die Implementierung zwischen den AppSignal-Bibliotheken geteilt werden kann. Die Erweiterung kommuniziert mit dem Agent über einen Socket, dessen Zeiger im Arbeitsverzeichnis des Agents gespeichert ist. Diese Kommunikation ist nur einseitig: Die Erweiterung sendet die aufgezeichneten Daten an den Agent, und der Agent sendet sie an die AppSignal-Server.

​
Agent

Sobald er von der Erweiterung gestartet wurde, läuft der AppSignal Agent im Hintergrund Ihrer Anwendung als daemonisierter Prozess weiter. Er verarbeitet Verbindungen von mehreren Clients (App-Prozesse über die Erweiterung), wenn nötig. Zum Beispiel, wenn Sie sowohl Unicorn (Webserver) als auch Sidekiq (Background-Job-Bibliothek) gleichzeitig ausführen, wird für beide Prozesse nur ein AppSignal Agent laufen. Wenn die Verbindung zum Agent verloren geht, verbinden sich Clients automatisch wieder und/oder starten einen neuen Agent. (Restart-Verhalten hinzugefügt in Ruby-Gem-Version 2.4.0, Elixir-Paket-Version 1.4.0 und Node.js 1.0.0.) Beim Booten versucht der Agent, ein geeignetes Arbeitsverzeichnis zu finden, in dem er einige seiner temporären Betriebsdateien speichern kann. Er muss Dateien im Arbeitsverzeichnis erstellen und schreiben und die appsignal.log-Datei erstellen können, bevor er korrekt booten kann. Wenn dies fehlschlägt, bootet er nicht korrekt und beendet sich. Der Agent benötigt einen Ort zum Speichern der appsignal.log-Datei, da der stdout-Wert für die log-Konfigurationsoption (für Ruby und Elixir) nicht für den Agent gilt. Der Agent kann seine Logs nicht über den Socket an die Erweiterung zurückkommunizieren. Der Agent selbst ist ein leichtgewichtiger Prozess, der in Rust geschrieben ist und sehr wenig Ressourcen verwendet. Er hält Ihre Daten nur sehr kurz im Speicher, bis er sie an die AppSignal Push-API sendet, danach werden die Daten geleert. Wenn er sich nicht mit der AppSignal Push-API verbinden kann, speichert er die Daten vorübergehend auf der Festplatte, siehe Arbeitsverzeichnis. Mit der Zeit empfängt der Agent Monitoring-Daten von Ihren Apps und beginnt, sie zu aggregieren. Nach einem 30-Sekunden-Übertragungsintervall überträgt er die aggregierten Daten an die AppSignal Push-API. Dort werden sie verarbeitet, Vorfälle und Anomaly Detection-Warnungen erstellt, und schließlich werden Benachrichtigungen an Sie, den Benutzer, gesendet. Periodisch liest der Agent auch die Systemstatistiken von der Maschine, auf der er läuft, um Host-Metriken zu sammeln. Dies geschieht mit Hilfe der von AppSignal geschriebenen Bibliothek probes-rs. Die Host-Metrikdaten werden für die Host-Metriken-Funktion verwendet, um Grafiken bereitzustellen und Host-Metrikdaten für Samples zu diesem Zeitpunkt anzuzeigen. Wenn eine Anfrage an unsere Push-API fehlgeschlagen ist, wird der Payload dieser Anfrage auf die Festplatte im Arbeitsverzeichnis geschrieben, und er wird im nächsten Übertragungsintervall erneut versuchen, den Payload zu senden.

​
Arbeitsverzeichnis

Das Arbeitsverzeichnis wird für mehrere Dinge verwendet, die der AppSignal Agent benötigt, um weiterzulaufen. Es ist ein erforderlicher Bestandteil, um den AppSignal Agent ausführen zu können. Wenn kein geeigneter Ort für das Arbeitsverzeichnis gefunden werden kann, wird der Agent heruntergefahren und die Erweiterung in Ihrer App deaktiviert sich selbst. Sie meldet dann keine Daten mehr an die AppSignal-Server. Die Verantwortlichkeiten des Arbeitsverzeichnisses:
  • Fallback-Speicherort für appsignal.log
    • Das Arbeitsverzeichnis dient als Fallback-Speicherort für die appsignal.log-Datei, wenn kein gültiger Pfad erkannt werden kann und der angegebene log_path-Speicherort nicht verwendbar ist (Konfigurationsoption für Ruby und Elixir). Wenn kein geeigneter Speicherort gefunden wird, wie z. B. im Verzeichnis log/ Ihres Projekts, wird sie in {working_directory}/appsignal.log gespeichert. Lesen Sie mehr über die AppSignal-Logs.
  • agent.socket-Dateispeicherung
    • Der AppSignal Agent speichert eine Socket-Datei in {working_directory}/agent.socket, die von der AppSignal-Erweiterung in Ihrer Anwendung zur Kommunikation mit dem Agent verwendet wird. Immer wenn eine AppSignal-Transaktion endet oder Sie eine benutzerdefinierte Metrik senden, werden diese Daten in den Socket geschrieben und vom Agent empfangen. Er aggregiert diese Daten dann und überträgt sie an die AppSignal Push-API.
  • agent.lock-Dateispeicherung
    • Der AppSignal Agent speichert eine Lock-Datei (agent.lock), um sicherzustellen, dass nur eine Instanz des Agents mit Ihrer App-Konfiguration läuft. Wenn eine neue Version des Agents gestartet wird, werden ältere Versionen heruntergefahren, wenn sie erkennen, dass eine neuere Version läuft, sodass der neu gestartete Agent ab diesem Zeitpunkt alle eingehenden Daten verarbeiten kann.
    • Die Verwendung eines Arbeitsverzeichnisses und einer Lock-Datei für mehrere Apps, die auf derselben Maschine laufen, kann zu seltsamem Verhalten führen. Aus diesem Grund empfehlen wir, ein Arbeitsverzeichnis pro App zu verwenden. Lesen Sie mehr über das Ausführen mehrerer Anwendungen auf einem Host.
    • Wenn Sie diese Datei oder das gesamte Arbeitsverzeichnis löschen, wird der Agent sofort heruntergefahren.
  • payloads-Speicherung
    • Das payloads-Verzeichnis enthält zwischengespeicherte Payloads, die auf die Festplatte geschrieben wurden, wenn der Agent Probleme hat, sich mit unserer Push-API zu verbinden. Um zu vermeiden, dass der Speicherbedarf des Agents im Laufe der Zeit ansteigt, werden diese Daten vorübergehend auf der Festplatte gespeichert. Dadurch stellen wir sicher, dass keine Ihrer wertvollen Daten verloren gehen, wenn Ihre Netzwerkverbindung für eine begrenzte Zeit ausfällt oder unsere Push-API einen kleinen Schluckauf hat. Die Anzahl der auf der Festplatte gespeicherten Payloads ist automatisch auf die letzten paar Payloads begrenzt, sodass dies immer wenig Speicherplatz verbraucht.

​
Speicherort

Der Standard-Speicherort des Arbeitsverzeichnisses ist /tmp/appsignal. Wenn Sie eine Verzeichnisstruktur im Capistrano-Stil verwenden, wird ein Verzeichnis namens appsignal in app/shared erstellt. Bei Deployments im Heroku-Stil wird das Verzeichnis in /app/tmp erstellt. Wenn keiner dieser Pfade erkannt wird, wird das AppSignal-Verzeichnis am Standard-Speicherort erstellt. Der Speicherort des Arbeitsverzeichnisses kann mit der Konfigurationsoption working_directory_path (Ruby / Elixir) angepasst werden. Jeder auf diese Weise konfigurierte Pfad hat Vorrang vor jedem erkennbaren Pfad.

​
Berechtigungen

Standardmäßig ist das Arbeitsverzeichnis für jeden beschreibbar (Unix-Berechtigungen 0666). Dies ist die Standardeinstellung, weil wir im Laufe der Zeit viele Support-Anfragen erhalten haben, die daher rührten, dass das Arbeitsverzeichnis zwar existierte, aber nicht vom AppSignal Agent beschreibbar war. Zum Beispiel: wenn die App beim Deployment der App vom Deploy-Benutzer gestartet wird, aber bei einem Host-Neustart von einem anderen Benutzer. Dies gibt einem der Benutzerkonten die Verzeichnis-Eigentümerschaft und macht es für den anderen Benutzer nicht beschreibbar. Es ist möglich, die globalen Lese- und Schreibberechtigungen zu deaktivieren (und dem Arbeitsverzeichnis Unix-Berechtigungen 0644 zu geben), indem Sie die Konfigurationsoption files_world_accessible (Ruby / Elixir) für Ihre Apps auf false setzen.