Taalbibliotheken
De AppSignal Ruby-gem en Elixir-package bieden integratie voor hun respectievelijke programmeertaal en populaire libraries (voor Ruby en Elixir) uit het ecosysteem, om foutrapportage en performance-inzichten te bieden. Het is momenteel vereist om een van deze libraries te gebruiken om AppSignal in uw app te integreren en host metrics van zijn host te verzamelen. Wanneer u de AppSignal Ruby-gem en het Elixir-package in uw app installeert, wordt naast deze een native extensie voor de programmeertaal gecompileerd. Deze extensie communiceert met de agent om uw data efficiënt te verwerken en naar de Push API van AppSignal te sturen. Wanneer u uw applicatie opstart met AppSignal geïnstalleerd, wordt de AppSignal-agent op de achtergrond gestart. Hij start slechts één agent per configuratie; als er een nieuwe configuratie wordt gevonden, start er een nieuwe agent en worden de agents voor andere versies afgesloten.Extensie
De AppSignal-extensie communiceert tussen de programmeertaal en de AppSignal-agent. Een deel is geschreven in Rust en het andere deel in de programmeertaal C. De host-machine waarop AppSignal is geïnstalleerd, moet daarom een werkende C-compiler hebben. Meestal is deze al geïnstalleerd op de host-machine, maar bij veel Docker-images is dit vaak niet het geval om de images klein te houden. De vereiste packages voor uw besturingssysteem staan vermeld op onze pagina ondersteunde besturingssystemen. De AppSignal-extensie bestaat uit twee delen: de C-extensie en de statische/dynamische library geschreven in Rust. De C-extensie voor Ruby en de Nif voor Elixir implementeren de AppSignal-library-interface zodat de AppSignal-taalbibliotheek ermee kan communiceren. Er wordt een aparte library gebruikt zodat de implementatie kan worden gedeeld tussen AppSignal-bibliotheken. De extensie communiceert met de agent via een socket, waarvan de pointer wordt opgeslagen in de werkmap van de agent. Deze communicatie is eenrichtingsverkeer; de extensie stuurt de geregistreerde data naar de agent en de agent stuurt deze naar de AppSignal-servers.Agent
Eenmaal gestart door de extensie blijft de AppSignal-agent op de achtergrond van uw applicatie draaien als een daemonized proces. Hij handelt verbindingen af van meerdere clients (app-processen via de extensie) wanneer dat nodig is. Als u bijvoorbeeld zowel Unicorn (webserver) als Sidekiq (background job-library) tegelijk gebruikt, draait er voor beide processen slechts één AppSignal-agent. Als de verbinding met de agent verloren gaat, maken clients automatisch opnieuw verbinding en/of starten een nieuwe agent. (Herstartgedrag toegevoegd in Ruby-gem versie2.4.0, Elixir-package versie 1.4.0 en Node.js 1.0.0).
Bij het opstarten probeert de agent een geschikte werkmap te vinden waarin hij enkele van zijn tijdelijke werkbestanden kan opslaan. Hij moet bestanden in de werkmap kunnen maken en schrijven en het bestand appsignal.log aanmaken voordat hij correct kan opstarten. Lukt dit niet, dan start hij niet correct op en sluit hij af. De agent heeft een locatie nodig om het bestand appsignal.log op te slaan, aangezien de waarde stdout voor de configuratieoptie log (voor Ruby en Elixir) niet van toepassing is op de agent. De agent kan zijn logs niet terugcommuniceren over de socket met de extensie.
De agent zelf is een lichtgewicht proces geschreven in Rust, dat zeer weinig resources gebruikt. Hij houdt uw data slechts zeer kort in het geheugen totdat hij deze naar de AppSignal Push API stuurt, waarna hij de data flusht. Als hij geen verbinding kan maken met de AppSignal Push API, slaat hij de data tijdelijk op schijf op, zie werkmap.
Na verloop van tijd ontvangt de agent monitoringdata van uw apps en begint deze te aggregeren. Na een verzendinterval van 30 seconden pusht hij de geaggregeerde data naar de AppSignal Push API. Hier wordt deze verwerkt, worden incidenten en Anomaly detection-alerts aangemaakt en worden uiteindelijk notificaties naar u, de gebruiker, gestuurd.
Periodiek leest de agent ook de systeemstats van de machine waarop hij draait om host metrics te verzamelen. Dit wordt gedaan met behulp van de probes-rs-library geschreven door AppSignal. De host metrics-data wordt gebruikt voor de host metrics-functie om grafieken te bieden en host metrics-data voor samples op dat moment weer te geven.
Als een request naar onze Push API is mislukt, wordt de payload van die request naar schijf geschreven in de werkmap en wordt er bij het volgende verzendinterval opnieuw geprobeerd om de payload te verzenden.
Werkmap
De werkmap wordt gebruikt voor verschillende zaken die de AppSignal-agent nodig heeft om te blijven functioneren. Het is een vereist onderdeel om de AppSignal-agent te kunnen draaien. Als er geen geschikte plek voor de werkmap kan worden gevonden, sluit de agent af en zal de extensie in uw app zichzelf uitschakelen. Hij zal geen data meer rapporteren aan de AppSignal-servers. De verantwoordelijkheden van de werkmap:- Fallback-locatie voor
appsignal.log- De werkmap fungeert als fallback-locatie voor het bestand
appsignal.logwanneer geen geldig pad kan worden gedetecteerd en de opgegevenlog_path-locatie onbruikbaar is (configuratieoptie voor Ruby en Elixir). Als er geen geschikte locatie wordt gevonden, zoals in de maplog/van uw project, wordt het opgeslagen in{working_directory}/appsignal.log. Lees meer over de AppSignal-logs.
- De werkmap fungeert als fallback-locatie voor het bestand
- Opslag van bestand
agent.socket- De AppSignal-agent slaat een socket-bestand op in
{working_directory}/agent.socket, dat door de AppSignal-extensie in uw applicatie wordt gebruikt om met de agent te communiceren. Wanneer een AppSignal-transactie wordt voltooid of u een custom metric stuurt, wordt deze data naar de socket geschreven en door de agent ontvangen. Hij aggregeert deze data en verzendt deze vervolgens naar de AppSignal Push API.
- De AppSignal-agent slaat een socket-bestand op in
- Opslag van bestand
agent.lock- De AppSignal-agent slaat een lock-bestand (
agent.lock) op om ervoor te zorgen dat er slechts één instantie van de agent draait met de configuratie van uw app. Als er een nieuwe versie van de agent wordt gestart, sluiten oudere versies af wanneer ze detecteren dat er een nieuwere versie draait, zodat de nieuw gestarte agent vanaf dat moment alle inkomende data kan afhandelen. - Het gebruik van één werkmap en lock-bestand voor meerdere apps die op dezelfde machine draaien, kan vreemd gedrag veroorzaken. Daarom raden we aan om één werkmap-locatie per app te gebruiken. Lees meer over meerdere applicaties draaien op één host.
- Als u dit bestand of de hele werkmap verwijdert, sluit de agent onmiddellijk af.
- De AppSignal-agent slaat een lock-bestand (
- Opslag van
payloads- De payloads-map bevat gecachte payloads die naar schijf zijn geschreven voor wanneer de agent moeite heeft om verbinding te maken met onze Push API. Om te voorkomen dat de geheugenvoetafdruk van de agent in de loop van de tijd toeneemt, wordt deze data tijdelijk op schijf opgeslagen. Hiermee zorgen we ervoor dat we geen van uw kostbare data verliezen als uw netwerkverbinding korte tijd uitvalt of als onze Push API een kleine hapering heeft. De hoeveelheid payloads die op schijf wordt opgeslagen, is automatisch beperkt tot de laatste paar payloads, zodat dit altijd weinig schijfruimte in beslag neemt.
Locatie
De standaardlocatie van de werkmap is/tmp/appsignal. Als u een Capistrano-achtige mapstructuur gebruikt, wordt er een map met de naam appsignal aangemaakt in app/shared. Bij deployments in Heroku-stijl wordt de map aangemaakt in /app/tmp. Als geen van deze paden wordt gedetecteerd, wordt de AppSignal-map op de standaardlocatie aangemaakt.
De locatie van de werkmap kan worden aangepast met de configuratieoptie working_directory_path (Ruby / Elixir). Een pad dat op deze manier wordt geconfigureerd, heeft voorrang op elk pad dat kan worden gedetecteerd.
Rechten
Standaard is de werkmap voor iedereen beschrijfbaar (Unix-permissies0666). Dit is de standaardwaarde, omdat we in de loop van de tijd veel supportverzoeken hebben gezien die voortkwamen uit het bestaan van de werkmap, terwijl deze niet beschrijfbaar was door de AppSignal-agent. Bijvoorbeeld: wanneer de app wordt gestart door de deploy-gebruiker bij deployment van de app, maar door een andere gebruiker bij een herstart van de host. Dit geeft het eigendom van de map aan een van de gebruikersaccounts, terwijl het voor de andere gebruiker onbeschrijfbaar wordt.
Het is mogelijk om de globale lees- en schrijfrechten uit te schakelen (en de werkmap Unix-permissies 0644 te geven) door de configuratieoptie files_world_accessible (Ruby / Elixir) op false te zetten voor uw apps.