Actions
Actions zijn de locatie in de code waar een HTTP-request, background job, cron job of taak wordt gestart. Voor Ruby on Rails- en Phoenix-apps in Elixir is dit de combinatie van controller en action, zoalsBlogPostsController#create of Api::UsersController#index. Voor background jobs is dit de worker/job-naam, zoals UserMailer#sign_up_mail.
Actions worden gebruikt om issues te groeperen samen met de namespace en error.
Agent
AppSignal gebruikt een “agent” om met de AppSignal-servers te communiceren en de hosts waarop een applicatie draait te instrumenteren. De hostdata wordt gebruikt in onze host metrics-functie. De agent wordt gestart door de taal-specifieke library en draait als een apart UNIX-proces op de host van de applicatie. De taalbibliotheek en agent communiceren met elkaar via een UNIX-socket met behulp van een extensie. De transactie-instrumentatiedata die door de agent wordt verzameld, wordt naar de AppSignal-servers verzonden. De transactie-data wordt verwerkt en gebruikt om events te detecteren waarover gebruikers moeten worden gewaarschuwd. Lees meer over hoe de AppSignal-agent werkt en de levenscyclus van een AppSignal-request.Allocations
Tijdens een HTTP-request of een background job gebruikt een applicatie geheugen. Elke datastructuur die wordt geladen en elk object dat wordt geïnstantieerd, neemt geheugen in beslag. Wanneer een request of job veel data verwerkt, kan er veel meer geheugen worden gebruikt dan normaal. De AppSignal-integratiebibliotheken houden allocaties bij per transactie. De integratie houdt ook bij welk deel van de applicatie meer geheugenobjecten alloceert dan andere, zodat het mogelijk is om te zien of de ORM of template-library van de applicatie meer geheugen in beslag neemt. Op AppSignal.com wordt het aantal allocaties weergegeven als een geheel getal voor een action, event-groepen en specifieke events. Dit allocatienummer is het aantal objecten dat in het geheugen is aangemaakt tijdens een action/groep/event. De grootte van het aangemaakte object wordt niet bijgehouden.Anomaly detection
Anomaly detection is een AppSignal-functie waarmee gebruikers afwijkingen in hun apps kunnen detecteren. Een afwijking kan iets zijn zoals een verhoogde foutpercentage of een beperkte hoeveelheid vrij geheugen op de host van de app. Anomaly detection werkt met trigger-drempelwaarden die alerts aanmaken wanneer hun drempelwaarde is bereikt. Wanneer een alert wordt geopend, stuurt AppSignal notificaties naar de notifiers die zijn geselecteerd voor de specifieke trigger. Zie onze documentatie over Anomaly detection voor meer informatie.API
Een API is een “Application Programming Interface”. De term API is breed en wordt op veel manieren gebruikt. In de context van onze documentatie verwijzen we naar de AppSignal HTTP REST API bij het gebruik van “API”. De AppSignal-API is een HTTP REST API die kan worden gebruikt om data op te halen van de AppSignal-servers en bestaande data uit te breiden met meer informatie zoals Markers. De API verschilt van de Push API wat betreft doel. Terwijl de Push API wordt gebruikt om data naar AppSignal te sturen door de agent, wordt de HTTP REST API voornamelijk gebruikt om data op te halen uit AppSignal. Hiermee kunnen gebruikers de beschikbare data in andere tooling gebruiken. U kunt meer lezen over onze API in onze API-documentatie.API-sleutel
Om verbinding te maken met de AppSignal-API is het noodzakelijk geauthenticeerd te zijn. Elke gebruiker heeft zijn eigen API-sleutel om zich te authenticeren bij AppSignal. Uw API-sleutel kunt u vinden op uw gebruikers- profiel. Deze sleutel moet niet worden verward met de Push API-sleutel, die wordt gebruikt door applicaties met een AppSignal-agent geïnstalleerd.Applications
Applications (voorheen bekend als “sites”, ook wel “apps” genoemd) zijn Ruby- en Elixir-applicaties die worden gemonitord door AppSignal. Na installatie van de AppSignal-library in een applicatie begint AppSignal deze applicaties te monitoren. Zodra we data van een applicatie ontvangen, registreren we deze met de applicatienaam en de omgeving waarin deze draait. Een applicatie kan meerdere environments hebben, zolang elke environment dezelfde naam gebruikt.- “Demo application” - Development
- “Demo application” - Production
- “Demo application” - Staging
- “Demo application” - Test
AppSignal vs Appsignal vs appsignal
Wacht, zijn er drie verschillende schrijfwijzen van de naam AppSignal? Ja! Laten we uitleggen:| Schrijfwijze | Gebruik |
|---|---|
AppSignal | De merknaam van het bedrijf, de applicatie en bijna al het andere dat met AppSignal te maken heeft. Dit is de versie die u moet gebruiken bij het praten over AppSignal als merk, product of dienst of stroopwafel-leverancier. |
Appsignal | De library-naam van onze AppSignal-integraties (Ruby-integratie, Elixir-integratie, Node.js-integratie, Front-end-integratie etc.). Wordt alleen gebruikt in de codecontext. |
appsignal | De pakketnamen van de AppSignal-integraties zoals gepubliceerd op package manager-registries voor de Ruby-gem, Elixir-package en packages-prefix-naam, Node.js packages-prefix en Front-end packages-prefix, etc. |
Blog
We hebben een blog op blog.appsignal.com! Op onze blog plaatsen we alles wat relevant is voor AppSignal, zoals nieuwe features, nieuwe grote agent-releases, Ruby Magic-artikelen en andere mooie verhalen uit onze interne processen. Zoals hoe u stroopwafels eet.Changelog
We houden een volledige product-changelog bij op appsignal.com/changelog. Alle nieuwe features, agent-releases en andere wijzigingen aan het product zijn te vinden in deze netjes georganiseerde lijst. We hebben ook een kleine indicator in onze top-navigatie die u laat weten of er een nieuwe vermelding in de changelog is.Configuratie
De configuratie maakt deel uit van de libraries die in applicaties draaien. Deze vertelt de AppSignal-libraries wat ze in een applicatie moeten instrumenteren, welke applicatie het is en in welke environment deze draait. De AppSignal-libraries hebben meerdere configuratiemethoden. De meest gebruikte methode is het gebruik van eenappsignal.yml-configuratiebestand.
Het gebruik van omgevingsvariabelen wordt ook aanbevolen.
Voor de configuratie van de Ruby-agent raden we u aan het
configuratie-onderwerp te lezen om aan de slag te gaan.
CPU-gebruik
Tijdens het draaien van een applicatie kan het CPU-gebruik sterk variëren. Sommige operaties van een applicatie kunnen meer CPU-tijd vragen dan andere. Andere factoren kunnen ook van invloed zijn op het CPU-gebruik. Als de gemonitorde applicatie niet het enige proces op de host-machine is, kunnen andere processen ook de CPU-gebruiksmetric beïnvloeden. Als een database die op dezelfde machine draait bijvoorbeeld een complexe query moet uitvoeren, vraagt deze meer CPU-tijd. Op AppSignal.com wordt het CPU-gebruik van een applicatie op twee manieren weergegeven. Voor een action waar een fout/performance-probleem optrad en voor host metrics. Op deze manier is het mogelijk om te zien of de performance van een action direct werd beïnvloed door een drukke CPU of dat de hele host gedurende langere perioden werd beïnvloed. Lees meer over wat CPU-metrics betekenen op onze blog.Cross-Site Request Forgery
Cross-Site Request Forgery (CSRF) is een aanval die een eindgebruiker dwingt om ongewenste acties uit te voeren op een webapplicatie waar deze is geauthenticeerd. Een slachtoffer kan op een link klikken die via e-mail of webchat naar hem is gestuurd, waardoor de aanvaller de inloggegevens van het slachtoffer kan stelen en gebruiken. De ernst van de aanval kan variëren afhankelijk van de applicatie en de autorisatie-toegang van het account van het slachtoffer. Een aanvaller kan in staat zijn om status-wijzigende acties uit te voeren op een account van een gebruiker, zoals het wijzigen van de inloggegevens, en kan in ernstige gevallen een hele applicatie compromitteren, bijvoorbeeld wanneer een slachtoffer een beheerder is.Elixir Alchemy
Wilt u meer leren over Elixir? In onze e-mailserie Elixir Alchemy (1x p/m) duiken we dieper in Elixir en Erlang. U kunt zich hier aanmelden: appsignal.com/elixir-alchemy.Environments
De meeste applicaties kunnen in verschillende modes worden gedraaid. Tijdens de development van een applicatie gelden andere regels en worden errors meestal niet weergegeven in de vorm van een “500 internal server error”-pagina zoals in “production”. AppSignal begrijpt ook het concept van een environment, waardoor verschillende instellingen per environment kunnen worden geconfigureerd. Voor elke environment wordt een aparte applicatie aangemaakt op AppSignal.com om te worden geconfigureerd met zijn eigen set alert-regels en third-party integrations.Errors
Errors zijn problemen die optreden tijdens het draaien van een applicatie. Dit kan van alles zijn, van een catastrofale fout die ervoor zorgt dat de applicatie crasht tot een simpele typefout die een foutpagina veroorzaakt. Zodra er een error optreedt in een applicatie, stuurt AppSignal een alert en registreert de details van de error om later te bekijken op AppSignal.com. Lees meer over de errors-functie op onze tour-pagina. Voor meer informatie over foutafhandeling in Ruby leest u ons onderwerp Exception handling waarin wordt beschreven hoe u effectief errors kunt bijhouden met AppSignal. Errors worden gerapporteerd als issues. Lees meer over wat issues zijn.Events
Een event is iets dat is gebeurd. Dit is een zeer vage uitspraak omdat het concept van een event iets is op een zeer hoog niveau. Een error is een event, en zo ook een performance-issue. AppSignal monitort veel events binnen een applicatie en op een server met behulp van host metrics. Door veel verschillende soorten events te verzamelen en de data te combineren, hopen we een zo compleet mogelijk beeld te bieden om meer inzicht te krijgen in de performance van applicaties. Zie ook documentatie over instrumentation events.Extensie
De AppSignal-libraries en agent staan voortdurend met elkaar in verbinding. De libraries sturen data naar de agent via een UNIX-socket. Daarvoor gebruiken de libraries een extensie voor de programmeertaal waarin ze zijn geschreven. Deze extensie is geschreven in C en Rust, en wordt geïnstalleerd wanneer de taal-specifieke agent wordt geïnstalleerd. Lees meer over hoe de AppSignal-extensie werkt en de levenscyclus van een AppSignal-request.Impact
De impact van een action op een applicatie is gebaseerd op het gebruik ervan in vergelijking met andere actions. Wanneer een controller-action of job meer tijd in beslag neemt of vaker wordt uitgevoerd dan andere, groeit de impact ervan. Bijvoorbeeld:- Action A wordt 1000 keer geactiveerd met een gemiddelde duur van 0,5 seconde. De gecombineerde duur is 500 seconden.
- Action B wordt 500 keer geactiveerd met een gemiddelde duur van 3 seconden. De gecombineerde duur is 1500 seconden.
- Action A heeft een impact van 25% (500 / 2000).
- Action B heeft een impact van 75% (1500 / 2000).
Instrumentation
Instrumentation is wat AppSignal aandrijft. Zonder dit zouden we niets weten over wat er binnen applicaties gebeurt. Instrumentation zijn hooks binnen of rond frameworks en libraries die AppSignal gebruikt om applicatiecode te monitoren. Deze instrumentation rapporteert errors en trage code, die naar AppSignal worden gestuurd voor analyse. Zodra een probleem wordt gedetecteerd, wordt er een alert verzonden. Lees meer over Ruby instrumentation.Instrumentation events
Events zijn codeblokken die worden uitgevoerd. Dit kunnen methodes, functies of kleinere onderdelen daarvan zijn. Events kunnen worden genest om hiërarchie en de totale duur van bewerkingen te tonen. Deze individuele events maken het mogelijk te zien welke delen van de code trager zijn dan andere. Bovenaan issue-pagina’s groeperen we ook de event-duur op groepsnaam, volgens onze event-naamgeving, om inzicht te geven in welk deel van de app het langst duurt. Enkele soorten events die kunnen worden weergegeven zijn database-query’s, JSON parsing, view-rendering, HTTP-requests, custom instrumentation, enz. Elk event wordt weergegeven op de detailpagina van performance-issues in de “performance timeline”. Als we detecteren dat hetzelfde event meer dan eens achter elkaar wordt herhaald, markeren we deze als mogelijke N+1-events, zoals N+1-query’s. Zie ook instrumentation.Issues
Wanneer AppSignal een nieuwe error detecteert, wordt er een issue aangemaakt. Wanneer AppSignal een nieuwe mogelijk trage request, background job, enz. detecteert, wordt er een nieuwe issue aangemaakt. Deze issue wordt gegroepeerd op action, namespace en error. Error-issues ondersteunen ook errors zonder action, aangezien een error kan optreden buiten een action, zoals in het framework van de app voordat de eigen code van de app wordt bereikt. Performance-issues zonder een action worden stilzwijgend genegeerd. De action, namespace en het error-type zijn de manier waarop we issues groeperen. Als een error van een nieuw type optreedt op dezelfde action in dezelfde namespace als een andere error-issue, wordt er voor die error een nieuwe issue aangemaakt. Als er een andere mogelijke trage request wordt gedetecteerd op een ander endpoint of background job, wordt er voor dat endpoint/die job een nieuwe issue aangemaakt. Per issue is het mogelijk om notificatie-instellingen, toewijzing, status (open/gesloten/in uitvoering) en ernst te configureren.Libraries
AppSignal gebruikt taal-specifieke libraries om applicaties te monitoren. Momenteel hebben we een Ruby-gem en Elixir- package. Deze libraries bevatten hooks in frameworks en libraries om codeblokken te instrumenteren, zoals databaseaanroepen, bestandssysteemaanroepen en view- rendering. Elke library is gespecialiseerd in de instrumentation van zijn doeltaal. De meeste AppSignal-libraries bevatten ook een “agent” die de libraries gebruiken om met de AppSignal-servers te communiceren. Lees meer over hoe de AppSignal-agent werkt en de levenscyclus van een AppSignal-request.Library-integraties
AppSignal-libraries integreren met een verscheidenheid aan verschillende libraries en frameworks die specifiek zijn voor de programmeertaal. De Ruby-gem integreert met pure Ruby, Rails, Sinatra en andere beschikbare frameworks. Het Elixir-package integreert met pure Elixir en Phoenix. Deze automatische integraties maken het eenvoudiger om meer inzicht te krijgen in applicaties zonder handmatig AppSignal-instrumentation te hoeven toevoegen. Lees meer over welke Ruby-integraties we bieden.Markers
Markers zijn kleine icoontjes die in grafieken op AppSignal.com worden gebruikt om een wijziging aan te geven. Dit kan een code deploy zijn met een “Deploy marker” of een speciaal event met een “Custom marker”. Deze custom markers kunnen van alles zijn, van scaling-operaties, plotselinge piek in verkeer of wanneer een database problemen ondervindt. Lees meer over markers.Metadata
Metadata is data die informatie geeft over andere data. Metadata is informatie over een error of performance-issue die meer context biedt aan de verzamelde data. Door extra metadata te versturen op een sample is het makkelijker om de omstandigheden rondom het specifieke issue te achterhalen. Standaard bevat de metadata van een request de hostname waarop het issue zich voordeed, de SCM-revisie waarop de applicatie draait, en het request-ID van de request waarvan de sample is afgeleid. Het bevat ook data zoals het request-pad en de request-methode voor webrequests.Metrics
AppSignal biedt twee soorten metrics. Custom metrics maken het mogelijk om data te verzamelen van vrijwel alles. Met een paar regels code is het mogelijk om data bij te houden en in grafieken weer te geven, zoals het aantal geregistreerde gebruikers, paginabezoeken, databasegrootten, enz. Host metrics gaan over data van de server waarop een applicatie draait. Data zoals CPU-gebruik, load averages, geheugengebruik, enz. geven meer inzicht in performance-problemen dan alleen de code zelf. Misschien raakt de schijfruimte op, waardoor de applicatie veel trager draait. Lees meer over metrics op onze tour-pagina.Namespace
Namespaces zijn groeperingsmechanismen die door AppSignal worden gebruikt om onderscheid te maken tussen verschillende delen van dezelfde applicatie. Standaard splitst AppSignal een applicatie op in twee namespaces: “Web” en “Background”. HTTP-requests die door AppSignal worden gemonitord, worden toegevoegd aan de “Web”- namespace en jobs die worden uitgevoerd door background job-libraries worden toegevoegd aan de “Background”-namespace. Het is ook mogelijk om uw namespaces te configureren om onderscheid te maken tussen requests op een applicatie en een privé-administratiepaneel. Voor meer informatie over namespaces, zie onze namespaces-documentatie.Notifications
AppSignal stuurt notificaties wanneer er een probleem wordt gedetecteerd met een applicatie. Deze notificaties kunnen e-mailberichten, Slack-berichten, een PagerDuty-notificatie en meer zijn, afhankelijk van welke third-party integrations zijn geconfigureerd. We sturen notificaties over errors, trage requests en Anomaly detection-alerts die voorkomen in een applicatie met een AppSignal-library. Zodra een problematisch event wordt gedetecteerd, wordt er een notificatie verzonden om gebruikers te waarschuwen voor een probleem.Organizations
Organisaties worden gebruikt om applicaties en gebruikers voor een bedrijf te groeperen. Een bedrijf kan veel gebruikers en klanten hebben die kunnen worden gewaarschuwd] wanneer er een probleem is met hun applicaties. Facturering voor applicaties gebeurt op organisatie- niveau in plaats van per applicatie. Team management wordt eenvoudig gemaakt met organisaties. Hele teams kunnen worden uitgenodigd voor een organisatie, zodat er geen inloggegevens hoeven te worden gedeeld. Lees meer over organisaties in onze Organisatie- documentatie.Owners
Organisaties hebben mensen die de organisatie beheren. Deze owners bepalen wie lid is van een organisatie, in welk team ze wel of niet thuishoren en hoe de facturering wordt afgehandeld. Organisatie-owners kunnen alles beheren over een organisatie en de applicaties die erbij horen. Als u geen toestemming hebt om iets te bekijken of te wijzigen, vraag dan de owner van uw organisatie om het voor u te wijzigen of u meer toestemming te geven.Performance issues
Met performance monitoring is het mogelijk om diep te duiken in individuele requests en te zien welke delen van een applicatie traag zijn. Met deze informatie is het mogelijk om probleemgebieden te vinden en te verbeteren. Wanneer AppSignal een trage webrequest of operation detecteert, worden er notificaties verzonden, omdat trage code net zo schadelijk kan zijn als een error die verschijnt. Performance-issues worden gegroepeerd op action en namespace. Op de detailpagina’s van performance-issues is meer informatie beschikbaar over elke action. Niet alle issues zijn een “issue”. Het is aan u om te bepalen of een HTTP-request van 200ms te traag is. Mogelijke trage requests en background jobs worden gerapporteerd als performance-issues. Lees meer over wat issues zijn. Lees meer over de performance-functie op onze tour-pagina.Push API
De AppSignal “Push API” is het API-endpoint dat door de AppSignal- agent wordt gebruikt om de verzamelde data te verzenden. Dit verschilt van de normale AppSignal-API die voornamelijk wordt gebruikt om data te lezen en meer context toe te voegen aan de data die naar AppSignal wordt verzonden. Deze Push API is de API waarnaar applicatie-instrumentation wordt verzonden vanuit applicaties die de Push API-sleutel gebruiken.Push API-sleutel
De “Push API-sleutel” is een write-only API-sleutel die door applicaties wordt gebruikt om zichzelf te authenticeren bij het versturen van data naar de AppSignal-servers. Apps rapporteren data aan de Push API en authenticeren zich met deze sleutel. Er zijn verschillende soorten Push API-sleutels die apps kunnen gebruiken voor verschillende use cases. Alle Push API-sleutels zijn te vinden op de Push & deploy-instellingenpagina.- Organisatie-level Push API-sleutel: De aanbevolen Push API-sleutel voor back-end-integraties, zoals Ruby, Elixir, Node.js, Python en Go. We herkennen apps op basis van een combinatie van de Push API-sleutel, app-naam en app-environment, en maken apps aan met deze informatie als deze nog niet bestaat.
- App-level Push API-sleutel: Na aanmaak krijgt een app ook zijn app-level Push API-sleutel toegewezen. Deze sleutel kan worden gebruikt om data naar een specifieke app te sturen, zelfs als de app is geconfigureerd om een andere app-naam of app-environment te gebruiken. Dit wordt gebruikt bij het verplaatsen van apps tussen organisaties zonder dataverlies, of wanneer er geen app-naam of app-environment kan worden ingesteld, zoals bij de Vector-integratie.
- Front-end API-sleutel: Deze sleutel wordt gebruikt door apps die onze front-end-integratie gebruiken om data te rapporteren en kan worden gevonden in de sectie “Front-end error monitoring”.