> ## 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.

# Wie AppSignal-Integrationen funktionieren

AppSignal besteht aus vielen verschiedenen Systemen, die zusammenarbeiten. Diese Seite erklärt, welche Systeme Teil der Integrationen sind, die wir für [Ruby](/ruby) und [Elixir](/elixir) ausliefern, und wie sie zusammenarbeiten.

* [Sprachbibliotheken](#language-libraries)
* [Erweiterung](#extension)
* [Agent](#agent)
  * [Arbeitsverzeichnis](#working-directory)
    * [Speicherort](#location)
    * [Berechtigungen](#permissions)

## Sprachbibliotheken

Das AppSignal [Ruby-Gem](https://rubygems.org/gems/appsignal) und das [Elixir-Paket](https://hex.pm/packages/appsignal) bieten Integration für ihre jeweilige Programmiersprache und beliebte Bibliotheken (für [Ruby](/ruby/integrations) und [Elixir](/elixir/integrations)) 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](/metrics/host-metrics) von seinem Host zu sammeln.

Wenn Sie das AppSignal Ruby-Gem und das Elixir-Paket in Ihrer App installieren, wird daneben eine native [Erweiterung](#extension) für die Programmiersprache kompiliert. Diese Erweiterung kommuniziert mit dem [Agent](#agent), um Ihre Daten effizient zu verarbeiten und an die AppSignal [Push-API](/appsignal/terminology#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](https://en.wikipedia.org/wiki/C_%28programming_language%29). 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](/support/operating-systems) aufgeführt.

Die AppSignal-Erweiterung besteht aus zwei Teilen: der C-Erweiterung und der statischen/dynamischen Bibliothek, die in [Rust](https://www.rust-lang.org/en-US/) geschrieben ist. Die C-Erweiterung für [Ruby](https://github.com/appsignal/appsignal-ruby/blob/main/ext/appsignal_extension.c) und das [Nif](/elixir/why-nif) für [Elixir](https://github.com/appsignal/appsignal-elixir/blob/develop/c_src/appsignal_extension.c) implementieren die AppSignal-Bibliotheksschnittstelle, sodass die AppSignal-Sprachbibliothek damit kommunizieren kann. Eine separate Bibliothek wird verwendet, damit die Implementierung zwischen den AppSignal-[Bibliotheken](#language-libraries) geteilt werden kann.

Die Erweiterung kommuniziert mit dem Agent über einen Socket, dessen Zeiger im [Arbeitsverzeichnis](#working-directory) 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](#extension) 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](#extension)), 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](#working-directory) 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](/ruby/configuration/options#option-log) und [Elixir](/elixir/configuration/options#option-log)) 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](https://www.rust-lang.org/en-US/) 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](#working-directory).

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](/metrics/host-metrics) zu sammeln. Dies geschieht mit Hilfe der von AppSignal geschriebenen Bibliothek [probes-rs](https://github.com/appsignal/probes-rs). Die Host-Metrikdaten werden für die Host-Metriken-Funktion verwendet, um Grafiken bereitzustellen und Host-Metrikdaten für [Samples](/appsignal/terminology#samples) zu diesem Zeitpunkt anzuzeigen.

Wenn eine Anfrage an unsere [Push-API](/appsignal/terminology#push-api) fehlgeschlagen ist, wird der Payload dieser Anfrage auf die Festplatte im [Arbeitsverzeichnis](#working-directory) 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](/ruby/configuration/options#option-log_path) und [Elixir](/elixir/configuration/options#option-log_path)). 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](/support/debugging#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](/application/#running-multiple-applications-on-one-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](http://capistranorb.com/)-Stil verwenden, wird ein Verzeichnis namens `appsignal` in `app/shared` erstellt. Bei Deployments im [Heroku](https://heroku.com)-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](/ruby/configuration/options#option-working_directory_path) / [Elixir](/elixir/configuration/options#option-working_directory_path)) 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](/ruby/configuration/options#option-files_world_accessible) / [Elixir](/elixir/configuration/options#option-files_world_accessible)) für Ihre Apps auf `false` setzen.
