Zum Hauptinhalt springen
Es gibt keine dummen Fragen. Auf dieser Seite finden Sie Antworten auf die uns am häufigsten gestellten Fragen. Wenn Sie weitere Unterstützung benötigen, besuchen Sie bitte unsere Support-Seite.

​
Inhalt

​
Erste Schritte

​
Ich brauche Hilfe beim Einstieg. Wo fange ich an?

Wenn Sie neu bei AppSignal sind oder mehr über die Konfiguration von AppSignal-Funktionen erfahren möchten, lesen Sie bitte unsere Leitfäden.

​
AppSignal-Bibliotheken

​
Welche Programmiersprachen unterstützt AppSignal?

AppSignal unterstützt die Programmiersprachen Node.js, Ruby und Elixir. Außerdem haben wir JavaScript-Pakete, um clientseitige Fehler in unterstützten Browsern abzufangen.

​
Daten filtern

​
Wie ignoriere ich Aktionen in meiner Anwendung?

Sie können Actions ignorieren, um die Aufzeichnung von Daten für bestimmte Actions, Requests, Hintergrundjobs usw. zu stoppen.

​
Wie ignoriere ich Fehler in meiner Anwendung?

Sie können Fehler ignorieren (basierend auf ihrem Namen), um zu verhindern, dass AppSignal sie meldet und Sie darüber benachrichtigt.

​
Wie filtere ich Daten, die an AppSignal gesendet werden?

Um zu erfahren, wie Sie die an AppSignal gesendeten Daten filtern können, lesen Sie einen der folgenden Leitfäden:

​
Welche Regex-Syntax unterstützt ignore_logs?

ignore_logs unterstützt nur eine begrenzte Teilmenge der Syntax regulärer Ausdrücke: ^ (Anfang der Zeichenkette), $ (Ende der Zeichenkette) und .* (Wildcard). Vollständige Regex-Konstrukte wie Zeichenklassen ([.]) sind nicht gültig und werden stillschweigend ignoriert. Um eine genaue Logzeile zu matchen, verankern Sie sie mit ^ und $. Um ein Präfix zu matchen, verwenden Sie ^ gefolgt vom literalen Text. Um irgendwo in der Nachricht zu matchen, umgeben Sie diese mit .*. Die vollständige Syntaxreferenz finden Sie im Leitfaden zum Ignorieren von Logs.

​
Wie unterdrücke ich Logs, die von appsignal-wrap gesendet werden?

appsignal-wrap leitet standardmäßig stdout und stderr an AppSignal weiter. Die Konfigurationsoption ignore_logs gilt nicht für appsignal-wrap. Um die Ausgabe zu unterdrücken, übergeben Sie --no-stdout und/oder --no-stderr an den Befehl appsignal-wrap: 
appsignal-wrap --no-stdout --no-stderr your-api-key -- your-command
Dies sind reine CLI-Flags und können nicht über Umgebungsvariablen gesetzt werden. Die vollständige Liste der Optionen finden Sie in der appsignal-wrap-Dokumentation.

​
Wie füge ich meiner Anwendung zusätzliche Instrumentation hinzu?

Sie können Ihrer Anwendung zusätzliche Instrumentation hinzufügen, um durch die Messung der Dauer einzelner Ereignisse mehr Einblicke in deren Performance zu erhalten. Erfahren Sie wie, in der Dokumentation für unser Ruby Gem und unser Elixir-Paket.

​
Was ist der Unterschied zwischen setRootName und setName?

setName und setRootName benennen beide Spans um, aber auf verschiedenen Ebenen. setName setzt den Namen eines einzelnen Spans so, wie er in der Performance-Sample-Timeline erscheint, während setRootName den Namen der Root-Transaktion festlegt — das, was Sie in der Performance-Übersicht und der Transaktionsliste sehen. Ein gutes Muster ist, setRootName einmal auf Ihrem äußersten Handler aufzurufen (zum Beispiel `${request.method} ${pattern}`, um einen Titel wie GET /users/:id zu erzeugen), und setName zusammen mit setCategory für innere Spans wie Middleware, Loader und Actions zu verwenden, damit diese als klar beschriftete Ereignisse in der Timeline-Aufschlüsselung erscheinen. Weitere Informationen zur Benennung und zum Hinzufügen von Spans finden Sie im Leitfaden zur Node.js-Instrumentation.

​
Wie betreibe ich mehrere Anwendungen auf einem Host?

Standardmäßig geht AppSignal davon aus, dass eine Anwendung auf einem Host läuft. Wenn Sie mehr als eine Anwendung auf einem Host betreiben, kann es zu unerwartetem Verhalten kommen, z. B. dass Daten für eine andere Anwendung gemeldet werden. Um AppSignal für mehrere Anwendungen auf einem Host zu konfigurieren, muss das AppSignal-Arbeitsverzeichnis konfiguriert werden. Lesen Sie mehr darüber, wie Sie das Arbeitsverzeichnis in unserem Leitfaden zum Betrieb mehrerer Anwendungen auf einem Host konfigurieren.

​
Welche Betriebssysteme unterstützt AppSignal?

Bitte lesen Sie unsere Seite Betriebssysteme für die vollständige Liste der unterstützten Betriebssysteme und aller erforderlichen Pakete.

​
Wie debugge ich ein Problem mit der AppSignal-Integration?

Bitte lesen Sie unseren Debugging-Leitfaden für eine vollständige Anleitung zum Debuggen von Problemen mit der AppSignal-Integration. Sie können auch unsere Seite Bekannte Probleme auf Probleme prüfen, die in Ihrer Version der AppSignal-Integration vorhanden sein könnten.

​
Unterstützt AppSignal Windows?

AppSignal unterstützt Windows nicht, und es gibt keine Pläne, Windows-Unterstützung hinzuzufügen. Wir versuchen jedoch, die AppSignal-Bibliotheken unter Microsoft Windows ohne Fehler oder Build-Probleme installierbar zu halten.

​
Warum schlägt die Installation des AppSignal Ruby Gem mit einem JSON::Fragment-Fehler fehl?

Dieser Fehler tritt bei der Installation von appsignal 4.x mit Ruby 3.0 oder älter auf. Das in AppSignal 4.x als Abhängigkeit gebündelte json-Gem hat JSON::Fragment eingeführt, eine Konstante, die nur in Ruby 3.1 und neuer verfügbar ist. Auf älteren Ruby-Versionen schlägt der Build der nativen Erweiterung fehl mit: 
uninitialized constant JSON::Fragment (NameError)
Die empfohlene Lösung ist, Ruby auf 3.1 oder höher zu aktualisieren, sodass Sie die aktuelle AppSignal-4.x-Version ohne Einschränkungen verwenden können. Wenn Sie Ruby nicht sofort aktualisieren können, können Sie als vorübergehende Lösung auf AppSignal 3.x pinnen: Fügen Sie gem "appsignal", "~> 3.0" zu Ihrem Gemfile hinzu und führen Sie bundle update appsignal aus. AppSignal 3.x funktioniert mit Ruby 2.7 und Ruby 3.0, erhält jedoch keine neuen Funktionen aus der 4.x-Linie, also planen Sie ein Ruby-Upgrade ein, sobald es möglich ist.

​
Wie konfiguriere ich AppSignal in einer Hanami-Anwendung?

AppSignal konfiguriert sich in Hanami nicht automatisch wie in Rails. Verwenden Sie eine Ruby-Konfigurationsdatei (config/appsignal.rb) anstatt der veralteten YAML-Datei (config/appsignal.yml) — das YAML-Format ist veraltet und wird in der nächsten Hauptversion des Gems entfernt. Erstellen Sie config/appsignal.rb mit: 
Appsignal.configure do |config|
  config.activate_if_environment(:development, :staging, :production)
  config.name = "Your App Name"
  config.push_api_key = "your-key-here"
end
Stellen Sie dann sicher, dass config.ru die Integration nach Hanami lädt: 
require "appsignal"
require "hanami/boot"

Appsignal.load(:hanami)
Appsignal.start

run Hanami.app
Wenn Sie eine bestehende config/appsignal.yml haben, entfernen Sie sie oder fügen Sie einen development-Abschnitt mit active: true hinzu — beide Dateien gleichzeitig zu haben führt zu Konflikten. AppSignal startet in der development-Umgebung standardmäßig nicht; activate_if_environment aktiviert es explizit. Die vollständige Einrichtung finden Sie in der Hanami-Integrationsdokumentation.

​
Warum werden Fehler in Phoenix LiveComponent nicht von AppSignal erfasst?

AppSignal erfasst Phoenix-Fehler durch das Abhören von Phoenix-Telemetry-Events. Wenn ein LiveComponent Form-Events direkt verarbeitet, verwendet Phoenix einen internen Pfad, der diese Telemetry-Events nicht aussendet, sodass der Fehler nie gemeldet wird. Um Fehler aus LiveComponent zu melden, verwenden Sie Appsignal.send_error/2, um sie manuell zu senden: 
rescue e ->
  Appsignal.send_error(e, __STACKTRACE__)
  reraise e, __STACKTRACE__
end
Alternativ können Sie Logik, die eine Exception auslösen kann, aus dem Template der Komponente in deren handle_event/3- oder update/2-Callbacks verschieben, wo Phoenix-Telemetry ausgelöst wird. Diese Lücke wurde Upstream in phoenix_live_view behoben. Ein Update auf die neueste Version ermöglicht es AppSignal, diese Fehler automatisch zu erfassen.

​
Benutzerkonto

​
Wie aktiviere ich die Zwei-Faktor-Authentifizierung (2FA) für die AppSignal-App?

Weitere Informationen zur Aktivierung von 2FA finden Sie auf unserer Seite Zwei-Faktor-Authentifizierung.

​
Warum funktionieren meine Zwei-Faktor-Authentifizierungs- (2FA-) Codes nicht?

Wenn die Codes Ihrer Authenticator-App beim Anmelden abgelehnt werden, ist die häufigste Ursache eine Abweichung der Uhr auf dem Gerät, das sie erzeugt. Zwei-Faktor-Authentifizierungs-Codes sind zeitbasiert (TOTP), daher muss die Uhr des Geräts genau gehen — dies funktioniert häufig nach einem Zeitzonenwechsel nicht mehr. Aktivieren Sie das automatische (Netzwerk-)Datum und die Uhrzeit auf dem Gerät und versuchen Sie es dann mit dem neu generierten Code. Wenn Sie sich weiterhin nicht anmelden können, verwenden Sie einen der fünf Wiederherstellungscodes, die Sie beim Aktivieren von 2FA gespeichert haben, um die Zwei-Faktor-Authentifizierung zu umgehen. Weitere Informationen zu Wiederherstellungscodes finden Sie unter Zwei-Faktor-Authentifizierung.

​
Welche IP-Adressen verwendet AppSignal?

Derzeit verwendet die AppSignal Push API die folgenden IP-Adressen: 
185.191.3.93
185.191.3.94
185.191.3.125
185.191.3.126
Derzeit stammen die AppSignal-Webhooks von den folgenden IP-Adressen: 
185.191.3.107
185.191.3.72
185.191.3.116
185.191.3.84
Wir empfehlen nicht, bestimmte IP-Adressen auf eine Allowlist zu setzen. Sie können sich ändern, und in Zukunft kommen möglicherweise weitere hinzu, zum Beispiel wenn wir unsere Load Balancer rotieren oder schnell Server hinzufügen müssen. Wenn Sie sich dennoch entscheiden, unsere IP-Adressen auf eine Allowlist zu setzen, schreiben Sie bitte unserem Support-Team eine E-Mail, und wir tun unser Bestes, um Sie über bevorstehende Änderungen zu informieren.

​
Fehler & Performance

​
Warum wird mein Performance-Issue immer als „Closed” markiert?

Der Open- oder Closed-Status eines Issues wird durch seine Benachrichtigungseinstellungen bestimmt, nicht dadurch, ob das zugrunde liegende Problem immer noch auftritt. AppSignal markiert ein Issue als Open, wenn es eine Benachrichtigung dafür sendet. Performance-Issues verwenden standardmäßig die Einstellung „Never Notify”, sodass keine Benachrichtigung gesendet wird — weshalb sie als Closed bleiben. Damit ein Performance-Issue bei neuen Vorkommen geöffnet wird, ändern Sie seine Benachrichtigungseinstellung, entweder pro Issue oder durch Aktualisieren Ihrer organisationsweiten Standardeinstellung. Wie das konfiguriert wird, erfahren Sie unter Benachrichtigungseinstellungen.

​
Wie sehe ich Fehleranzahlen pro Namespace?

Um Fehleranzahlen pro Namespace zu sehen, erstellen Sie ein Number-Chart, das die Metrik transaction_exception_count verwendet (AppSignals Zählung der in einer Anwendung aufgezeichneten Fehler), gefiltert nach dem namespace-Tag:
  1. Öffnen Sie die Anwendung, die Sie messen möchten, gehen Sie zu Dashboards und fügen Sie ein neues Chart hinzu.
  2. Wählen Sie den Tab Number aus.
  3. Setzen Sie die Metrik auf transaction_exception_count.
  4. Fügen Sie den Tag namespace hinzu und geben Sie den Namespace-Namen ein (zum Beispiel web oder background).
  5. Setzen Sie den Aggregationstyp auf Total value.
  6. Erstellen Sie das Chart.
Das Chart zeigt die Gesamtfehleranzahl für diesen Namespace über den von Ihnen beim Anzeigen ausgewählten Zeitraum. AppSignal speichert Fehlerdaten separat pro Anwendung, sodass es keine einzige Summe über alle Anwendungen gibt — erstellen Sie ein Chart pro Namespace pro Anwendung und addieren Sie die Zahlen selbst, wenn Sie eine Gesamtsumme benötigen.

​
Wie lange werden Uptime-Monitoring-Daten aufbewahrt?

Uptime-Monitoring speichert minütliche Metriken für 30 Tage und stündliche Metriken für 5 Jahre. Um tägliche Uptime-Trends über einen längeren Zeitraum — zum Beispiel ein ganzes Jahr — anzuzeigen, verwenden Sie die Datumsauswahl in der Ansicht Uptime-Monitoring, um einen benutzerdefinierten Datumsbereich zu wählen.

​
Wie finde ich die Ursache langsamer API-Requests?

Beginnen Sie unter Performance → Slow API requests. Requests sind nach Impact sortiert — die Kombination aus Dauer und Häufigkeit — sodass die obersten Einträge die wahrscheinlichsten Verursacher sind. Bei Auswahl eines Requests werden dessen mittlere Dauer, Antwortzeit-Diagramm, Throughput und die Liste der Actions, die ihn enthalten, angezeigt. Für Datenbankabfragen prüfen Sie Performance → Slow queries. Jede Query ist nach Impact sortiert, und bei Auswahl wird angezeigt, welche Actions sie auslösen. Um N+1-Queries zu finden, öffnen Sie Performance → Issue list. Actions, die mit dem Tag N+1 markiert sind, enthalten wiederholte Datenbankaufrufe. Öffnen Sie ein Sample und betrachten Sie die Performance-Timeline — Events, die mit x2, x5 usw. markiert sind, weisen auf dieselbe Query hin, die innerhalb eines einzelnen Requests wiederholt wird. Eine geführte Anleitung finden Sie unter Langsame Datenbankabfragen finden und Langsame HTTP-Requests finden.