> ## 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. # Terminologie Bij AppSignal gebruiken we veel technische termen. Lees verder om meer te leren over de taal van AppSignal. Zie de terminologielijst aan de rechterkant van deze pagina. ## 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, zoals `BlogPostsController#create` of `Api::UsersController#index`. Voor background jobs is dit de worker/job-naam, zoals `UserMailer#sign_up_mail`. Actions worden gebruikt om [issues](#issues) te groeperen samen met de [namespace](#namespace) en [error](#errors). ## 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](/metrics/host-metrics)-functie. De agent wordt gestart door de taal-specifieke [library](#libraries) 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](#extension). De transactie-instrumentatiedata die door de agent wordt verzameld, wordt naar de AppSignal-servers verzonden. De [transactie](#transactions)-data wordt verwerkt en gebruikt om events te detecteren waarover gebruikers moeten worden gewaarschuwd. Lees meer over hoe de AppSignal-[agent werkt](/appsignal/how-appsignal-operates) en de [levenscyclus van een AppSignal-request](/appsignal/data-life-cycle). ## 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](#transactions). 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](/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](#markers). De API verschilt van de [Push API](#push-api) wat betreft doel. Terwijl de Push API wordt gebruikt om data naar AppSignal te sturen door de [agent](#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). ## API-sleutel Om verbinding te maken met de AppSignal-[API](#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](https://appsignal.com/users/edit). Deze sleutel moet niet worden verward met de [Push API-sleutel](#push-api-key), die wordt gebruikt door [applicaties](#applications) met een AppSignal-[agent](#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](#libraries) 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](#environments) hebben, zolang elke environment dezelfde naam gebruikt. * "Demo application" - Development * "Demo application" - Production * "Demo application" - Staging * "Demo application" - Test Meerdere applicaties kunnen bestaan in één [organisatie](#organizations). Lees meer over applications in onze [Applications- documentatie](/application). ## 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](#stroopwafels). | | `Appsignal` | De library-naam van onze AppSignal-integraties ([Ruby-integratie](/ruby), [Elixir-integratie](/elixir), [Node.js-integratie](/nodejs/3.x/), [Front-end-integratie](/front-end) etc.). Wordt alleen gebruikt in de codecontext. | | `appsignal` | De pakketnamen van de AppSignal-integraties zoals gepubliceerd op package manager-registries voor de [Ruby-gem](https://rubygems.org/gems/appsignal), [Elixir-package en packages-prefix](https://hex.pm/packages/appsignal)-naam, [Node.js packages-prefix](https://www.npmjs.com/package/@appsignal/nodejs) en [Front-end packages-prefix](https://www.npmjs.com/package/@appsignal/javascript), etc. | ## Blog We hebben een blog op [blog.appsignal.com](https://blog.appsignal.com/)! Op onze blog plaatsen we alles wat relevant is voor AppSignal, zoals nieuwe features, nieuwe grote agent-releases, [Ruby Magic](#ruby-magic)-artikelen en andere mooie verhalen uit onze interne processen. Zoals [hoe u stroopwafels eet](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Changelog We houden een volledige product-changelog bij op [appsignal.com/changelog](https://www.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](#libraries) wat ze in een [applicatie](#applications) 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 een `appsignal.yml`-configuratiebestand. Het gebruik van omgevingsvariabelen wordt ook aanbevolen. Voor de configuratie van de Ruby-agent raden we u aan het [configuratie-onderwerp](/ruby/configuration) 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](https://blog.appsignal.com/2018/03/06/understanding-cpu-statistics.html) 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](https://blog.appsignal.com/elixir-alchemy). ## Environments De meeste [applicaties](#applications) 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](#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](https://www.appsignal.com/tour/errors) op onze tour-pagina. Voor meer informatie over foutafhandeling in Ruby leest u ons onderwerp [Exception handling](/ruby/instrumentation/exception-handling) waarin wordt beschreven hoe u effectief errors kunt bijhouden met AppSignal. Errors worden gerapporteerd als issues. Lees meer over wat [issues](#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](#errors) is een event, en zo ook een [performance-issue](#performance-issues). AppSignal monitort veel events binnen een applicatie en op een server met behulp van [host metrics](#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](#applications). Zie ook [documentatie over instrumentation events](#instrumentation-events). ## Extensie De AppSignal-[libraries](#libraries) en [agent](#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](/appsignal/how-appsignal-operates) en de [levenscyclus van een AppSignal-request](/appsignal/data-life-cycle). ## 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. De totale gecombineerde duur van beide actions is 2000 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](/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](#issues) groeperen we ook de event-duur op groepsnaam, volgens [onze event-naamgeving](/api/event-names), 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](#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](#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](#actions), [namespace](#namespace) en [error](#errors). 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](#actions) worden stilzwijgend genegeerd. De action, [namespace](#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](/ruby)-gem en [Elixir](/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](#agent)" die de libraries gebruiken om met de AppSignal-servers te communiceren. Lees meer over hoe de AppSignal-[agent werkt](/appsignal/how-appsignal-operates) en de [levenscyclus van een AppSignal-request](/appsignal/data-life-cycle). ### 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](#instrumentation) te hoeven toevoegen. Lees meer over welke [Ruby-integraties we bieden](/ruby/integrations). ## 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](/application/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](#samples) 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](/metrics/custom) * [Host metrics](/metrics/host-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](#cpu-usage), 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](https://www.appsignal.com/tour/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](/application/namespaces)-documentatie. ## Notifications AppSignal stuurt notificaties wanneer er een probleem wordt gedetecteerd met een [applicatie](#applications). Deze notificaties kunnen e-mailberichten, Slack-berichten, een PagerDuty-notificatie en meer zijn, afhankelijk van welke [third-party integrations](#third-party-integrations) zijn geconfigureerd. We sturen notificaties over [errors](#errors), [trage requests](#performance-issues) en [Anomaly detection](/anomaly-detection/)-alerts die voorkomen in een applicatie met een AppSignal-[library](#libraries). Zodra een problematisch event wordt gedetecteerd, wordt er een notificatie verzonden om gebruikers te waarschuwen voor een probleem. ## Organizations Organisaties worden gebruikt om [applicaties](#applications) en [gebruikers](#user-account) 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](/support/billing) voor applicaties gebeurt op organisatie- niveau in plaats van per applicatie. [Team management](/organization/team/members) 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](/organization). ## Owners [Organisaties](#organizations) hebben mensen die de organisatie beheren. Deze owners bepalen wie lid is van een organisatie, in welk [team](#teams) ze wel of niet thuishoren en hoe de facturering wordt afgehandeld. Organisatie-owners kunnen alles beheren over een organisatie en de [applicaties](#applications) 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](#errors) die verschijnt. Performance-issues worden gegroepeerd op [action](#actions) en [namespace](#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](#issues) zijn. Lees meer over de [performance-functie](https://www.appsignal.com/tour/performance) op onze tour-pagina. ## Push API De AppSignal "Push API" is het API-endpoint dat door de AppSignal- [agent](#agent) wordt gebruikt om de verzamelde data te verzenden. Dit verschilt van de normale AppSignal-[API](#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](#push-api-key) 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](#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](https://appsignal.com/redirect-to/app?to=info). * **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](/application/configuration), 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](/vector)-integratie. * **Front-end API-sleutel:** Deze sleutel wordt gebruikt door apps die onze [front-end-integratie](/front-end) gebruiken om data te rapporteren en kan worden gevonden in de sectie "Front-end error monitoring". Let op: deze write-only-sleutels moeten niet worden verward met de gebruikersspecifieke [API-sleutel](#api-key) die kan worden gebruikt om te authenticeren bij de [AppSignal API](#api) om data over uw apps op te halen uit ons systeem. ## Response time De response time van een action van een applicatie is de tijd die wordt besteed aan het verwerken van de action. Hoe langer een action duurt om uit te voeren, hoe meer deze kwalificeert als een performance-issue. De duur van deze action wordt weergegeven op AppSignal.com voor performance-issues en in grafieken voor controllers/jobs en op host-niveau. ## Ruby Magic Wist u dat we artikelen schrijven over de magie van Ruby? Dat doen we! Het heet Ruby Magic en u kunt zich ervoor aanmelden op [appsignal.com/ruby-magic](https://blog.appsignal.com/ruby-magic). Een lijst van alle Ruby Magic-artikelen die we tot nu toe hebben geschreven, is te vinden op [onze blog](https://blog.appsignal.com/). ## Samples Wanneer een paginarequest honderd keer achter elkaar traag is, is het niet zo relevant om alle trage requests te zien; een kleinere sample van deze requests vertelt hetzelfde verhaal. In plaats daarvan stuurt de AppSignal-[agent](#agent) slechts een kleine set performance- issues naar de AppSignal-servers. Dit bespaart data die naar de servers wordt verzonden, de data die op de applicatie-host en de AppSignal-servers wordt verwerkt, terwijl nog steeds hetzelfde verhaal over de issues wordt verteld. ## Stroopwafels Ook geschreven als "stroopwaffles". Bij AppSignal houden we van stroopwafels. We hebben er meer dan 25.000 verstuurd naar klanten, vrienden en conferenties. Als u bij een techbedrijf werkt en op kantoor een stroopwafel hebt gehad, is de kans groot dat deze van ons kwam. We hebben een heel artikel geschreven over wat stroopwafels zijn en hoe u ze moet eten. Lees verder om een [stroopwafel- expert](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html) te worden. ## Tags Error- en performance-issue-[samples](#samples) kunnen worden getagd. Door deze samples te taggen is het makkelijker om bepaalde issues te vinden en te identificeren. Door te taggen is het mogelijk om meer [metadata](#metadata) toe te voegen aan een sample die kan worden gebruikt in [link templates](/application/link-templates) om eenvoudig te linken naar de relevante data in uw applicatie. Lees meer over [tagging-requests](/guides/tagging). ## Teams Om leden van [organisaties](#organizations) te beheren, kunnen organisatie-owners teams gebruiken om toegang te geven tot applicaties. [Gebruikers](#user-account) die deel uitmaken van een team kunnen alleen toegang krijgen tot de applicaties waartoe het team waarvan ze deel uitmaken toegang heeft. Als een gebruiker deel uitmaakt van meer dan één team, kan deze gebruiker toegang krijgen tot alle applicaties van alle teams waartoe deze behoort. Teams geven permissiebeheer aan [owners](#owners) van een organisatie om gebruikerstoegang tot applicaties te beperken zonder dat er meerdere organisaties nodig zijn. Lees meer over organisatie-[team management](/organization/team/teams). ## Third-party integrations AppSignal.com biedt verbindingen met andere diensten zoals Slack en PagerDuty om gebruikers effectiever te waarschuwen over gedetecteerde problemen. Deze integraties kunnen worden beheerd via de UI op AppSignal.com op applicatie-per-applicatie-basis. Lees meer over [welke third-party integrations we bieden](/application/integrations/). ## Transactions Transactions worden aangemaakt door de AppSignal-[libraries](#libraries) voor elke gemonitorde webrequest en background job. Binnen deze transaction monitoren de agents op errors en trage code. Een transaction wordt aangemaakt aan het begin van een webrequest of wanneer een background job wordt gestart. Zodra de request of job afgerond is of crasht, wordt de transaction gesloten en naar de [agent](#agent) gestuurd voor verwerking. [Tags](#tags) en [metadata](#metadata) worden op transaction-niveau toegevoegd om verschillen tussen transaction-samples gemakkelijker te identificeren. ## Throughput De throughput van een applicatie is het totale aantal requests dat door een action/job is gestuurd in een bepaald tijdsbestek. De throughput kan per action en host verschillen. Op AppSignal.com wordt de throughput per action weergegeven en in grafieken voor elke host. ## TLS TLS staat voor Transport Layer Security. TLS is een cryptografisch protocol dat veilige verbindingen biedt voor computernetwerken, bijvoorbeeld tussen een server en een webbrowser. ## Queue time Wanneer een server of applicatie druk bezig is met het verwerken van veel requests, kunnen bepaalde requests in de wachtrij worden geplaatst voordat ze worden verwerkt. De tijd die wordt gewacht om te worden verwerkt, wordt "queue time" genoemd. Aangezien queue time de gebruikerservaring bij het gebruik van een applicatie negatief kan beïnvloeden, wordt deze metric door AppSignal bijgehouden voor HTTP-requests en background jobs. Voor background jobs vertegenwoordigt dit de tijd tussen het in de wachtrij plaatsen van de request (door een webrequest) en het oppakken ervan door de background worker (sidekiq). ## Gebruikersaccount Elke gebruiker die AppSignal gebruikt, heeft een gebruikersaccount. Met dit gebruikersaccount kunt u notificatievoorkeuren configureren. Veel gebruikers kunnen behoren tot een of meer organisaties. Geen aparte gebruikers- accounts nodig voor elke organisatie. [Organisaties](#organizations) beheren welke gebruikers toegang hebben tot welke applicaties en wie de facturering als [owner](#owners) kan beheren.