> ## 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 Bei AppSignal verwenden wir viele Fachbegriffe. Lesen Sie weiter, um mehr über die Sprache von AppSignal zu erfahren. Sehen Sie die Liste der Terminologie auf der rechten Seite dieser Seite. ## Actions Actions sind der Ort im Code, an dem eine HTTP-Anfrage, ein Background-Job, ein Cronjob oder eine Aufgabe gestartet wird. Für Apps mit Ruby on Rails und Elixirs Phoenix ist dies die Kombination aus Controller und Action, wie z. B. `BlogPostsController#create` oder `Api::UsersController#index`. Für Background-Jobs ist dies der Worker-/Job-Name, wie z. B. `UserMailer#sign_up_mail`. Actions werden zusammen mit dem [Namespace](#namespace) und [Error](#errors) zur Gruppierung von [Issues](#issues) verwendet. ## Agent AppSignal verwendet einen "Agent", um mit den AppSignal-Servern zu kommunizieren und die Hosts zu instrumentieren, auf denen eine Anwendung läuft. Die Host-Daten werden in unserer [Host-Metriken](/metrics/host-metrics)-Funktion verwendet. Der Agent wird von der sprachspezifischen [Bibliothek](#libraries) gestartet und läuft als separater UNIX-Prozess auf dem Host der Anwendung. Die Sprachbibliothek und der Agent kommunizieren miteinander über einen UNIX-Socket mithilfe einer [Erweiterung](#extension). Die vom Agent gesammelten Transaktions-Instrumentierungsdaten werden an die AppSignal-Server gesendet. Die [Transaktions](#transactions)-Daten werden verarbeitet und verwendet, um Ereignisse zu erkennen, die es wert sind, Benutzer zu alarmieren. Lesen Sie mehr darüber, wie der AppSignal-[Agent funktioniert](/appsignal/how-appsignal-operates) und über den [Lebenszyklus einer AppSignal-Anfrage](/appsignal/data-life-cycle). ## Allocations Während einer HTTP-Anfrage oder eines Background-Jobs verwendet eine Anwendung Speicher. Jede Datenstruktur, die geladen wird, und jedes Objekt, das instanziiert wird, beansprucht Speicher. Wenn eine Anfrage oder ein Job viele Daten verarbeitet, kann viel mehr Speicher verwendet werden, als normal ist. Die AppSignal-Integrationsbibliotheken verfolgen Allokationen pro [Transaktion](#transactions). Die Integration verfolgt auch, welcher Teil der Anwendung mehr Speicherobjekte allokiert als andere, sodass sichtbar ist, ob das ORM oder die Template-Bibliothek der Anwendung mehr Speicher beansprucht. Auf AppSignal.com wird die Anzahl der Allokationen als Integer für eine Action, Event-Gruppen und spezifische Events angezeigt. Diese Allokationszahl ist die Anzahl der Objekte, die während einer Action/Gruppe/eines Events im Speicher erstellt wurden. Die Größe des erstellten Objekts wird nicht verfolgt. ## Anomaly Detection Anomaly Detection ist eine AppSignal-Funktion, mit der Benutzer Anomalien in ihren Apps erkennen können. Eine Anomalie könnte z. B. eine erhöhte Fehlerrate oder eine begrenzte Menge an freiem Speicher auf dem Host der App sein. Anomaly Detection funktioniert mit Trigger-Schwellenwertbedingungen, die Alerts erstellen, wenn ihr Schwellenwert erreicht wird. Wenn ein Alert geöffnet wird, sendet AppSignal Benachrichtigungen an die für den jeweiligen Trigger ausgewählten Notifier. Weitere Informationen finden Sie in unserer Dokumentation zu [Anomaly Detection](/anomaly-detection/). ## API Eine API ist eine "Application Programming Interface". Der Begriff API ist weit gefasst und wird auf viele Arten verwendet. Im Kontext unserer Dokumentation beziehen wir uns mit "API" auf die AppSignal HTTP REST API. Die AppSignal API ist eine HTTP REST API, die verwendet werden kann, um Daten von den AppSignal-Servern abzurufen und die vorhandenen Daten mit weiteren Informationen wie [Markers](#markers) zu ergänzen. Die API unterscheidet sich von der [Push-API](#push-api) in ihrem Zweck. Während die Push- API verwendet wird, um Daten vom [Agent](#agent) an AppSignal zu senden, wird die HTTP REST API hauptsächlich verwendet, um Daten von AppSignal abzurufen. Dies ermöglicht es Benutzern, die verfügbaren Daten in anderen Tools zu verwenden. Sie können mehr über unsere API in unserer [API-Dokumentation](/api) lesen. ## API-Schlüssel Um sich mit der AppSignal-[API](#api) zu verbinden, ist es notwendig, authentifiziert zu sein. Jeder Benutzer hat seinen API-Schlüssel zur Authentifizierung bei AppSignal. Ihr API-Schlüssel kann auf Ihrem [Benutzer- profil](https://appsignal.com/users/edit) gefunden werden. Dieser Schlüssel sollte nicht mit dem [Push-API-Schlüssel](#push-api-key) verwechselt werden, der von [Anwendungen](#applications) mit einem installierten AppSignal-[Agent](#agent) verwendet wird. ## Applications Applications (früher bekannt als "Sites", auch als "Apps" bezeichnet) sind Ruby- und Elixir-Anwendungen, die von AppSignal überwacht werden. Nach der Installation der AppSignal-[Bibliothek](#libraries) in einer Anwendung beginnt AppSignal mit der Überwachung dieser Anwendungen. Sobald wir Daten von einer Anwendung empfangen, registrieren wir sie unter dem Anwendungsnamen und der Umgebung, in der sie läuft. Eine Anwendung kann mehrere [Umgebungen](#environments) haben, solange jede Umgebung denselben Namen verwendet. * "Demo-Anwendung" - Development * "Demo-Anwendung" - Production * "Demo-Anwendung" - Staging * "Demo-Anwendung" - Test Mehrere Anwendungen können in einer [Organisation](#organizations) existieren. Lesen Sie mehr über Anwendungen in unserer [Anwendungs- Dokumentation](/application). ## AppSignal vs Appsignal vs appsignal Moment, sind das *drei* verschiedene Schreibweisen des AppSignal-Namens? Ja! Lassen Sie uns das erklären: | Schreibweise | Verwendung | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `AppSignal` | Der Markenname des Unternehmens, der Anwendung und fast aller anderen Dinge im Zusammenhang mit AppSignal. Dies ist die Version, die Sie verwenden sollten, wenn Sie über AppSignal als Marke, Produkt oder Dienst oder [Stroopwafel-Lieferant](#stroopwafels) sprechen. | | `Appsignal` | Der Bibliotheksname unserer AppSignal-Integrationen ([Ruby-Integration](/ruby), [Elixir-Integration](/elixir), [Node.js-Integration](/nodejs/3.x/), [Front-End-Integration](/front-end) usw.). Wird nur im Code-Kontext verwendet. | | `appsignal` | Die AppSignal-Integrationspaketnamen, wie sie in Paketverwaltungs-Registries veröffentlicht sind, für das [Ruby-Gem](https://rubygems.org/gems/appsignal), den [Elixir-Paket- und Paketpräfix-](https://hex.pm/packages/appsignal)-Namen, den [Node.js-Paketpräfix](https://www.npmjs.com/package/@appsignal/nodejs) und den [Front-End-Paketpräfix](https://www.npmjs.com/package/@appsignal/javascript) usw. | ## Blog Wir haben einen Blog unter [blog.appsignal.com](https://blog.appsignal.com/)! In unserem Blog veröffentlichen wir alle Dinge, die für AppSignal relevant sind, wie neue Funktionen, neue große Agent-Releases, [Ruby Magic](#ruby-magic)-Artikel und andere großartige Geschichten aus unserem internen Prozess. Wie zum Beispiel [wie man Stroopwafels isst](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Changelog Wir führen einen vollständigen Produkt-Changelog auf [appsignal.com/changelog](https://www.appsignal.com/changelog). Alle unsere neuen Funktionen, Agent-Releases und anderen Änderungen am Produkt sind in dieser ordentlich organisierten Liste zu finden. Wir haben auch einen kleinen Indikator in unserer oberen Navigation, der Sie benachrichtigt, wenn es einen neuen Eintrag im Changelog gibt. ## Configuration Die Konfiguration ist Teil der Bibliotheken, die in Anwendungen laufen. Sie teilt den AppSignal-[Bibliotheken](#libraries) mit, was in einer [Anwendung](#applications) zu instrumentieren ist, um welche Anwendung es sich handelt und in welcher Umgebung sie läuft. Die AppSignal-Bibliotheken haben mehrere Konfigurationsmethoden. Die häufigste Konfigurationsmethode ist die Verwendung einer `appsignal.yml`-Konfigurationsdatei. Die Verwendung von Umgebungsvariablen wird ebenfalls empfohlen. Für die Konfiguration des Ruby-Agents empfehlen wir Ihnen, das [Konfigurations-Topic](/ruby/configuration) zu lesen, um loszulegen. ## CPU-Auslastung Während des Betriebs einer Anwendung kann die CPU-Auslastung stark variieren. Einige Operationen einer Anwendung können mehr CPU-Zeit anfordern als andere. Andere Faktoren können die CPU-Auslastung ebenfalls beeinflussen. Wenn die überwachte Anwendung nicht der einzige Prozess auf der Host-Maschine ist, können auch andere Prozesse die CPU-Auslastungsmetrik beeinflussen. Wenn zum Beispiel eine auf derselben Maschine laufende Datenbank eine komplizierte Abfrage durchführen muss, fordert sie mehr CPU-Zeit an. Auf AppSignal.com wird die CPU-Auslastung einer Anwendung auf zwei Arten angezeigt. Für eine Action, bei der ein Fehler/Performance-Problem aufgetreten ist, und für Host-Metriken. Auf diese Weise ist es möglich zu sehen, ob die Performance einer Action direkt durch eine ausgelastete CPU beeinflusst wurde oder ob der gesamte Host für längere Zeit betroffen war. Erfahren Sie mehr darüber, was [CPU-Metriken](https://blog.appsignal.com/2018/03/06/understanding-cpu-statistics.html) in unserem Blog bedeuten. ## Cross-Site Request Forgery Cross-Site Request Forgery (CSRF) ist ein Angriff, der einen Endbenutzer dazu zwingt, ungewollte Aktionen in einer Webanwendung auszuführen, in der er authentifiziert ist. Ein Opfer kann auf einen Link klicken, der ihm per E-Mail oder Webchat zugesendet wurde, sodass der Angreifer die Anmeldedaten des Opfers stehlen und verwenden kann. Die Schwere des Angriffs kann je nach Anwendung und Berechtigungsstufe des Opferkontos variieren. Ein Angreifer kann zustandsändernde Aktionen am Konto eines Benutzers vornehmen, z. B. die Anmeldedaten ändern, und kann in schweren Fällen eine gesamte Anwendung kompromittieren, z. B. wenn ein Opfer ein Administrator ist. ## Elixir Alchemy Möchten Sie mehr über Elixir erfahren? In unserer E-Mail-Serie Elixir Alchemy (1x p/Mo) tauchen wir tiefer in Elixir und Erlang ein. Sie können sich hier anmelden: [appsignal.com/elixir-alchemy](https://blog.appsignal.com/elixir-alchemy). ## Environments Die meisten [Anwendungen](#applications) können in verschiedenen Modi ausgeführt werden. Während der Entwicklung einer Anwendung gelten andere Regeln, und Fehler werden normalerweise nicht in Form einer "500 internal server error"-Seite angezeigt, wie sie es in "production" tun. AppSignal versteht ebenfalls das Konzept einer Umgebung und ermöglicht es, unterschiedliche Einstellungen pro Umgebung zu konfigurieren. Für jede Umgebung wird eine separate Anwendung auf AppSignal.com erstellt, die mit eigenen Alarmierungsregeln und [Drittanbieter- Integrationen](#third-party-integrations) konfiguriert werden kann. ## Errors Fehler sind Probleme, die während der Laufzeit einer Anwendung auftreten. Dies kann alles sein, von einem katastrophalen Ausfall, der die Anwendung zum Absturz bringt, bis zu einem einfachen Tippfehler, der eine Fehlerseite verursacht. Sobald ein Fehler in einer Anwendung auftritt, sendet AppSignal einen Alert und zeichnet die Details des Fehlers zur späteren Ansicht auf AppSignal.com auf. Lesen Sie mehr über die [Fehlerfunktion](https://www.appsignal.com/tour/errors) auf unserer Tour-Seite. Um mehr über die Fehlerbehandlung in Ruby zu erfahren, lesen Sie unser [Exception Handling](/ruby/instrumentation/exception-handling)-Thema, das beschreibt, wie Sie Fehler mit AppSignal effektiv verfolgen. Fehler werden als Issues gemeldet. Erfahren Sie mehr darüber, was [Issues](#issues) sind. ## Events Ein Event ist etwas, das passiert ist. Dies ist eine sehr vage Aussage, denn das Konzept eines Events ist etwas sehr Hochrangiges. Ein [Error](#errors) ist ein Event, und ein [Performance-Issue](#performance-issues) ebenfalls. AppSignal überwacht viele Events innerhalb einer Anwendung und auf einem Server mithilfe von [Host- Metriken](#metrics). Durch das Sammeln vieler verschiedener Arten von Events und das Kombinieren der Daten hoffen wir, ein möglichst vollständiges Bild zu liefern, um mehr Einblicke in die Performance von [Anwendungen](#applications) zu gewinnen. Siehe auch [Dokumentation zu Instrumentierungs-Events](#instrumentation-events). ## Extension Die AppSignal-[Bibliotheken](#libraries) und der [Agent](#agent) stehen in ständiger Kommunikation miteinander. Die Bibliotheken senden Daten über einen UNIX-Socket an den Agent. Dazu verwenden die Bibliotheken eine Erweiterung für die Programmiersprache, in der sie geschrieben sind. Diese Erweiterung ist in C und Rust geschrieben und wird installiert, wenn der sprachspezifische Agent installiert wird. Lesen Sie mehr darüber, wie die AppSignal-[Erweiterung funktioniert](/appsignal/how-appsignal-operates) und über den [Lebenszyklus einer AppSignal-Anfrage](/appsignal/data-life-cycle). ## Impact Der Impact einer Action auf eine Anwendung basiert auf ihrer Nutzung im Vergleich zu anderen Actions. Wenn eine Controller-Action oder ein Job mehr Zeit benötigt oder häufiger ausgeführt wird als andere, wächst sein Impact. Zum Beispiel: * Action A wird 1000 Mal ausgelöst mit einer durchschnittlichen Dauer von 0,5 Sekunden. Die kombinierte Dauer beträgt 500 Sekunden. * Action B wird 500 Mal ausgelöst mit einer durchschnittlichen Dauer von 3 Sekunden. Die kombinierte Dauer beträgt 1500 Sekunden. Die gesamte kombinierte Dauer beider Actions beträgt 2000 Sekunden. * Action A hat einen Impact von 25 % (500 / 2000). * Action B hat einen Impact von 75 % (1500 / 2000). ## Instrumentation Instrumentation ist das, was AppSignal antreibt. Ohne sie wüssten wir nichts darüber, was in Anwendungen vor sich geht. Instrumentation sind Hooks innerhalb oder um Frameworks und Bibliotheken, die AppSignal verwendet, um Anwendungscode zu überwachen. Diese Instrumentation meldet Fehler und langsamen Code, der zur Analyse an AppSignal gesendet wird. Sobald ein Problem erkannt wird, wird ein Alert gesendet. Erfahren Sie mehr über [Ruby Instrumentation](/ruby/instrumentation). ## Instrumentation-Events Events sind Codeblöcke, die ausgeführt werden. Dies können Methoden, Funktionen oder kleinere Teile davon sein. Events können verschachtelt werden, um Hierarchien und die Gesamtdauer von Operationen darzustellen. Diese einzelnen Events ermöglichen es zu sehen, welche Teile des Codes langsamer sind als andere. Oben auf den [Issue-Seiten](#issues) gruppieren wir die Event-Dauern auch nach Gruppennamen, gemäß [unserer Event-Benennung](/api/event-names), um Einblicke zu geben, welcher Teil der App am längsten dauert. Einige Arten von Events, die angezeigt werden können, sind Datenbankabfragen, JSON-Parsing, View-Rendering, HTTP-Anfragen, [benutzerdefinierte Instrumentation](#instrumentation) usw. Jedes Event wird auf den Detailseiten von Performance-Issues in der "Performance Timeline" angezeigt. Wenn wir erkennen, dass dasselbe Event mehrmals hintereinander wiederholt wird, markieren wir sie als potenzielle N+1-Events, wie z. B. N+1-Queries. Siehe auch [Instrumentation](#instrumentation). ## Issues Wann immer AppSignal einen neuen Fehler erkennt, wird ein Issue erstellt. Wann immer AppSignal eine neue potenziell langsame Anfrage, einen Background-Job usw. erkennt, wird ein neues Issue erstellt. Dieses Issue wird nach [Action](#actions), [Namespace](#namespace) und [Error](#errors) gruppiert. Error-Issues unterstützen auch Fehler ohne Action, da ein Fehler außerhalb einer Action auftreten kann, z. B. im Framework der App, bevor der eigene Code der App erreicht wird. Performance-Issues ohne [Action](#actions) werden stillschweigend ignoriert. Die Action, der [Namespace](#namespace) und der Fehlertyp sind die Art und Weise, wie wir Issues gruppieren. Wenn ein Fehler eines neuen Typs in derselben Action im selben Namespace auftritt wie ein anderer Error-Issue, wird ein neues Issue für diesen Fehler erstellt. Wenn eine weitere potenziell langsame Anfrage auf einem anderen Endpoint oder Background-Job erkannt wird, wird ein neues Issue für diesen Endpoint/Job erstellt. Pro Issue ist es möglich, Benachrichtigungseinstellungen, Zuweisungen, Status (offen/geschlossen/in Bearbeitung) und Schweregrad zu konfigurieren. ## Libraries AppSignal verwendet sprachspezifische Bibliotheken zur Überwachung von Anwendungen. Derzeit haben wir ein [Ruby](/ruby)-Gem und ein [Elixir](/elixir)- Paket. Diese Bibliotheken enthalten Hooks in Frameworks und Bibliotheken, um Codeblöcke wie Datenbankaufrufe, Dateisystemaufrufe und View- Rendering zu instrumentieren. Jede Bibliothek ist auf die Instrumentation ihrer jeweiligen Sprache spezialisiert. Die meisten AppSignal-Bibliotheken enthalten auch einen "[Agent](#agent)", den die Bibliotheken verwenden, um mit den AppSignal-Servern zu kommunizieren. Lesen Sie mehr darüber, wie der AppSignal-[Agent funktioniert](/appsignal/how-appsignal-operates) und über den [Lebenszyklus einer AppSignal-Anfrage](/appsignal/data-life-cycle). ### Bibliotheksintegrationen AppSignal-Bibliotheken integrieren sich mit einer Vielzahl von verschiedenen Bibliotheken und Frameworks, die für die Programmiersprache spezifisch sind. Das Ruby-Gem integriert sich mit reinem Ruby, Rails, Sinatra und anderen verfügbaren Frameworks. Das Elixir-Paket integriert sich mit reinem Elixir und Phoenix. Diese automatischen Integrationen erleichtern es, mehr Einblicke in Anwendungen zu erhalten, ohne AppSignal-[Instrumentation](#instrumentation) manuell hinzufügen zu müssen. Lesen Sie mehr darüber, welche [Ruby-Integrationen wir anbieten](/ruby/integrations). ## Markers Markers sind kleine Icons, die in Grafiken auf AppSignal.com verwendet werden, um eine Änderung anzuzeigen. Dies kann ein Code-Deploy mit einem "Deploy-Marker" oder ein besonderes Ereignis mit einem "Custom-Marker" sein. Diese Custom-Marker können alles sein, von Skalierungsoperationen, plötzlichen Traffic-Spitzen oder wenn eine Datenbank Probleme hat. Lesen Sie mehr über [Markers](/application/markers). ## Metadaten Metadaten sind Daten, die Informationen über andere Daten geben. Metadaten sind Informationen über einen Fehler oder ein Performance-Issue, die mehr Kontext zu den gesammelten Daten liefern. Indem zusätzliche Metadaten zu einem [Sample](#samples) gesendet werden, ist es einfacher, die Umstände des jeweiligen Problems nachzuvollziehen. Standardmäßig enthalten die Metadaten einer Anfrage den Hostnamen, auf dem das Problem aufgetreten ist, die SCM-Revision, auf der die Anwendung läuft, und die Request-ID der Anfrage, von der das Sample abgeleitet wurde. Sie enthalten auch Daten wie den Anfragepfad und die Anfragemethode für Webanfragen. ## Metrics AppSignal bietet zwei Arten von Metriken. * [Custom Metrics](/metrics/custom) * [Host Metrics](/metrics/host-metrics) Custom Metrics ermöglichen die Erfassung von Daten aus nahezu allem. Mit ein paar Zeilen Code ist es möglich, Daten wie die Anzahl der registrierten Benutzer, Seitenaufrufe, Datenbankgrößen usw. zu verfolgen und zu grafisch darzustellen. Host Metrics beziehen sich auf Daten vom Server, auf dem eine Anwendung läuft. Daten wie [CPU-Auslastung](#cpu-usage), Load Averages, Speichernutzung usw. geben mehr Einblick in Performance-Probleme als nur der Code selbst. Vielleicht geht der Speicherplatz zur Neige und verursacht, dass die Anwendung viel langsamer läuft. Lesen Sie mehr über [Metrics](https://www.appsignal.com/tour/metrics) auf unserer Tour-Seite. ## Namespace Namespaces sind Gruppierungsmechanismen, die von AppSignal verwendet werden, um zwischen verschiedenen Teilen derselben Anwendung zu unterscheiden. Standardmäßig teilt AppSignal eine Anwendung in zwei Namespaces auf: "Web" und "Background". HTTP-Anfragen, die von AppSignal überwacht werden, werden dem "Web"- Namespace hinzugefügt, und Jobs, die von Background-Job-Bibliotheken ausgeführt werden, werden dem "Background"-Namespace hinzugefügt. Es ist auch möglich, Ihre Namespaces so zu konfigurieren, dass sie zwischen Anfragen an eine Anwendung und einem privaten Administrationspanel unterscheiden. Weitere Informationen zu Namespaces finden Sie in unserer [Namespaces](/application/namespaces)-Dokumentation. ## Benachrichtigungen AppSignal sendet Benachrichtigungen, wenn ein Problem mit einer [Anwendung](#applications) erkannt wird. Diese Benachrichtigungen können E-Mail-Nachrichten, Slack-Nachrichten, eine PagerDuty-Benachrichtigung und mehr sein, abhängig davon, welche [Drittanbieter-Integrationen](#third-party-integrations) konfiguriert sind. Wir senden Benachrichtigungen über [Errors](#errors), [Slow Requests](#performance-issues) und [Anomaly Detection](/anomaly-detection/)-Alerts, die in einer Anwendung mit einer AppSignal-[Bibliothek](#libraries) auftreten. Sobald ein problematisches Ereignis erkannt wird, wird eine Benachrichtigung gesendet, um Benutzer auf ein Problem aufmerksam zu machen. ## Organizations Organisationen werden verwendet, um [Anwendungen](#applications) und [Benutzer](#user-account) für ein Unternehmen zu gruppieren. Ein Unternehmen kann viele Benutzer und Kunden haben, die benachrichtigt werden können, wann immer es ein Problem mit ihren Anwendungen gibt. Die [Abrechnung](/support/billing) für Anwendungen erfolgt auf Organisationsebene und nicht pro Anwendung. Die [Team-Verwaltung](/organization/team/members) wird mit Organisationen einfach gemacht. Ganze Teams können in eine Organisation eingeladen werden, sodass keine Anmeldedaten geteilt werden müssen. Lesen Sie mehr über Organisationen in unserer [Organisations- Dokumentation](/organization). ## Owners [Organisationen](#organizations) haben Personen, die die Organisation verwalten. Diese Owners entscheiden, wer Mitglied einer Organisation ist, in welchem [Team](#teams) sie sich befinden oder nicht, und entscheiden, wie die Abrechnung erfolgt. Organisations-Owners können alles über eine Organisation und die dazugehörigen [Anwendungen](#applications) verwalten. Wenn Sie keine Berechtigung haben, etwas anzuzeigen oder zu ändern, bitten Sie den Owner Ihrer Organisation, es für Sie zu ändern oder Ihnen mehr Berechtigungen zu geben. ## Performance-Issues Mit Performance-Monitoring ist es möglich, in einzelne Anfragen einzutauchen und zu sehen, welche Teile einer Anwendung langsam sind. Mit diesen Informationen ist es möglich, Problembereiche zu finden und zu verbessern. Wenn AppSignal eine langsame Webanfrage oder Operation erkennt, sendet es Benachrichtigungen, da langsamer Code genauso schädlich sein kann wie ein erscheinender [Error](#errors). Performance-Issues werden nach [Action](#actions) und [Namespace](#namespace) gruppiert. Auf den Detailseiten von Performance-Issues sind weitere Informationen zu jeder Action verfügbar. Nicht alle Issues sind ein "Issue". Es liegt an Ihnen zu bestimmen, ob eine HTTP-Anfrage von 200ms zu langsam ist. Potenziell langsame Anfragen und Background-Jobs werden als Performance-Issues gemeldet. Erfahren Sie mehr darüber, was [Issues](#issues) sind. Lesen Sie mehr über die [Performance-Funktion](https://www.appsignal.com/tour/performance) auf unserer Tour-Seite. ## Push-API Die AppSignal "Push-API" ist der API-Endpunkt, der vom AppSignal- [Agent](#agent) verwendet wird, um die gesammelten Daten zu senden. Dies unterscheidet sich von der normalen AppSignal-[API](#api), die hauptsächlich zum Lesen von Daten und zum Hinzufügen von mehr Kontext zu den an AppSignal gesendeten Daten verwendet wird. Diese Push-API ist die API, an die Anwendungs-Instrumentation von Anwendungen gesendet wird, die den [Push-API-Schlüssel](#push-api-key) verwenden. ## Push-API-Schlüssel Der "Push-API-Schlüssel" ist ein Nur-Schreib-API-Schlüssel, der von Anwendungen verwendet wird, um sich beim Senden von Daten an die AppSignal-Server zu authentifizieren. Apps melden Daten an die [Push-API](#push-api) und authentifizieren sich mit diesem Schlüssel. Es gibt verschiedene Arten von Push-API-Schlüsseln, die Apps für unterschiedliche Anwendungsfälle verwenden können. Alle Push-API-Schlüssel sind auf der [Push & Deploy-Einstellungsseite](https://appsignal.com/redirect-to/app?to=info) zu finden. * **Push-API-Schlüssel auf Organisationsebene:** Der empfohlene Push-API-Schlüssel für Back-End-Integrationen wie Ruby, Elixir, Node.js, Python und Go. Wir erkennen Apps anhand einer [Kombination aus Push-API-Schlüssel, App-Name und App-Umgebung](/application/configuration) und erstellen Apps anhand dieser Informationen, wenn sie noch nicht existieren. * **Push-API-Schlüssel auf App-Ebene:** Nach der Erstellung wird einer App auch ihr Push-API-Schlüssel auf App-Ebene zugewiesen. Dieser Schlüssel kann verwendet werden, um Daten an eine bestimmte App zu senden, auch wenn die App so konfiguriert ist, dass sie einen anderen App-Namen oder eine andere App-Umgebung verwendet. Dies wird verwendet, wenn Apps ohne Datenverlust zwischen Organisationen verschoben werden oder wenn kein App-Name oder keine App-Umgebung gesetzt werden kann, wie z. B. bei der [Vector](/vector)-Integration. * **Front-End-API-Schlüssel:** Dieser Schlüssel wird von Apps verwendet, die unsere [Front-End-Integration](/front-end) verwenden, um Daten zu melden, und ist im Abschnitt "Front-end error monitoring" zu finden. Hinweis: Diese Nur-Schreib-Schlüssel sollten nicht mit dem benutzerspezifischen [API-Schlüssel](#api-key) verwechselt werden, der zur Authentifizierung an der [AppSignal-API](#api) verwendet werden kann, um Daten über Ihre Apps von unserem System abzurufen. ## Response Time Die Response Time einer Action einer Anwendung ist die Zeit, die für die Verarbeitung der Action aufgewendet wird. Je länger eine Action zur Ausführung braucht, desto mehr qualifiziert sie sich als Performance-Issue. Die Dauer dieser Action wird auf AppSignal.com für Performance-Issues und in Grafiken für Controller/Jobs und auf Host-Ebene angezeigt. ## Ruby Magic Wussten Sie, dass wir Artikel über die Magie von Ruby schreiben? Das tun wir! Es heißt Ruby Magic, und Sie können sich dafür unter [appsignal.com/ruby-magic](https://blog.appsignal.com/ruby-magic) anmelden. Eine Liste aller bisher von uns geschriebenen Ruby Magic-Artikel finden Sie in [unserem Blog](https://blog.appsignal.com/). ## Samples Wenn eine Seitenanfrage hundertmal hintereinander langsam ist, ist es nicht so relevant, alle langsamen Anfragen zu sehen; ein kleineres Sample dieser Anfragen erzählt dieselbe Geschichte. Stattdessen sendet der AppSignal-[Agent](#agent) nur einen kleinen Satz von Performance- Issues an die AppSignal-Server. Dies spart Daten, die an die Server gesendet werden, Daten, die auf dem Anwendungs-Host und den AppSignal-Servern verarbeitet werden, während weiterhin dieselbe Geschichte über die Issues erzählt wird. ## Stroopwafels Auch geschrieben als "stroopwaffles". Bei AppSignal lieben wir Stroopwafels. Wir haben über 25.000 davon an Kunden, Freunde und Konferenzen verschickt. Wenn Sie in einem Tech-Unternehmen arbeiten und im Büro eine Stroopwafel hatten, ist die Wahrscheinlichkeit hoch, dass sie von uns kam. Wir haben einen ganzen Artikel darüber geschrieben, was Stroopwafels sind und wie man sie essen sollte. Lesen Sie weiter, um [Stroopwafel-Experte zu werden](https://blog.appsignal.com/blog/2016/02/01/stroopwafels-and-how-to-eat-them.html). ## Tags Error- und Performance-Issue-[Samples](#samples) können getaggt werden. Durch das Taggen dieser Samples ist es einfacher, bestimmte Issues zu finden und zu identifizieren. Durch das Taggen ist es möglich, mehr [Metadaten](#metadata) zu einem Sample hinzuzufügen, die in [Link-Templates](/application/link-templates) verwendet werden können, um einfach auf die relevanten Daten in Ihrer Anwendung zu verlinken. Lesen Sie mehr über das [Taggen von Anfragen](/guides/tagging). ## Teams Um Mitglieder von [Organisationen](#organizations) zu verwalten, können Organisations-Owners Teams nutzen, um Zugriff auf Anwendungen zu gewähren. [Benutzer](#user-account), die Teil eines Teams sind, können nur auf die Anwendungen zugreifen, auf die das Team, zu dem sie gehören, Zugriff hat. Wenn ein Benutzer Teil von mehr als einem Team ist, kann dieser Benutzer auf alle Anwendungen aller Teams zugreifen, denen er angehört. Teams geben [Owners](#owners) einer Organisation Berechtigungsverwaltung, um den Benutzerzugriff auf Anwendungen einzuschränken, ohne dass mehrere Organisationen benötigt werden. Lesen Sie mehr über die [Team-Verwaltung](/organization/team/teams) der Organisation. ## Drittanbieter-Integrationen AppSignal.com bietet Verbindungen zu anderen Diensten wie Slack und PagerDuty, um Benutzer effektiver über erkannte Probleme zu warnen. Diese Integrationen können über die Benutzeroberfläche auf AppSignal.com auf einer Anwendungs-für-Anwendung-Basis verwaltet werden. Lesen Sie mehr darüber, [welche Drittanbieter-Integrationen wir anbieten](/application/integrations/). ## Transactions Transaktionen werden von den AppSignal-[Bibliotheken](#libraries) für jede überwachte Webanfrage und jeden Background-Job erstellt. Innerhalb dieser Transaktion überwachen die Agents auf Fehler und langsamen Code. Eine Transaktion wird zu Beginn einer Webanfrage oder beim Start eines Background-Jobs erstellt. Sobald die Anfrage oder der Job abgeschlossen ist oder abstürzt, wird die Transaktion geschlossen und an den [Agent](#agent) zur Verarbeitung gesendet. [Tags](#tags) und [Metadaten](#metadata) werden auf Transaktionsebene hinzugefügt, um Unterschiede zwischen Transaktions-Samples leichter zu identifizieren. ## Throughput Der Throughput einer Anwendung ist die Gesamtzahl der über eine Action/einen Job in einem bestimmten Zeitrahmen gesendeten Anfragen. Der Throughput kann je nach Action und Host unterschiedlich sein. Auf AppSignal.com wird der Throughput pro Action angezeigt und in Grafiken für jeden Host dargestellt. ## TLS TLS steht für Transport Layer Security. TLS ist ein kryptografisches Protokoll, das sichere Verbindungen für Computernetzwerke bereitstellt, zum Beispiel zwischen einem Server und einem Webbrowser. ## Queue Time Wenn ein Server oder eine Anwendung mit der Verarbeitung vieler Anfragen beschäftigt ist, können bestimmte Anfragen in eine Warteschlange gestellt werden, bevor sie verarbeitet werden. Die Wartezeit auf die Verarbeitung wird als "Queue Time" bezeichnet. Da die Queue Time die Erfahrung der Benutzer mit einer Anwendung negativ beeinflussen kann, wird diese Metrik von AppSignal für HTTP-Anfragen und Background-Jobs verfolgt. Für die Background-Jobs stellt dies die Zeit zwischen dem Einreihen der Anfrage in die Warteschlange (durch eine Webanfrage) und dem Aufgreifen durch den Background-Worker (Sidekiq) dar. ## Benutzerkonto Jeder Benutzer, der AppSignal verwendet, hat ein Benutzerkonto. Mit diesem Benutzerkonto können Sie Benachrichtigungseinstellungen konfigurieren. Viele Benutzer können zu einer oder mehreren Organisationen gehören. Es sind keine separaten Benutzerkonten für jede Organisation erforderlich. [Organisationen](#organizations) verwalten, welche Benutzer auf welche Anwendungen zugreifen können und wer die Abrechnung als [Owner](#owners) verwalten kann.