Zum Hauptinhalt springen
Mit dem Uptime-Monitoring von AppSignal können Sie Benachrichtigungen erhalten, wenn Ihre Anwendung ausgefallen ist. Wir überprüfen Ihre Anwendung von mehreren Regionen weltweit, und wir benachrichtigen Sie, wenn Ihre Anwendung von keiner dieser Regionen aus erreicht werden kann. Wir stellen außerdem die Performance des von Ihnen angegebenen Endpunkts aus verschiedenen Regionen weltweit grafisch dar. Screenshot des Uptime-Monitoring-Dashboards

​
Einrichtung

Um eine neue Uptime-Monitor-Prüfung einzurichten, klicken Sie auf der Seite Uptime Monitoring auf die Schaltfläche „Add uptime monitor”. Geben Sie die vollständige URL (einschließlich http:// oder https://) der Seite an, die Sie überprüfen möchten. Unsere Server stellen jede Minute eine Anfrage an diese URL aus mehreren Regionen und melden, wenn die Anfrage fehlschlägt oder der Antwortstatuscode nicht im Bereich 2xx liegt. Um Benachrichtigungen zu erhalten, wenn Ihre Anwendung ausgefallen ist, wählen Sie eine Benachrichtigungsmethode aus. Um zu vermeiden, dass Sie bei kleinen Netzwerkproblemen Benachrichtigungen erhalten, empfehlen wir, eine Alert-Warmup-Periode von mindestens einer Minute einzustellen. Sie können Header festlegen, die in den Anfragen gesendet werden, die wir an die von Ihnen angegebene URL stellen. Damit können Sie Autorisierungs-Header festlegen, damit die Anfragen durchgehen.

​
So funktioniert es

Wir pingen Ihre Anwendungen von AWS-Lambda-Workern, die aus den folgenden Regionen ausgeführt werden: Wir fordern die angegebene URL aus den folgenden Regionen an:
  • Asia-Pacific (Seoul)
  • Europe (Frankfurt)
  • North America (N. Virginia)
  • South America (São Paulo)
Es gibt ein Verbindungs-Timeout von 30 Sekunden. Wenn Ihr Server nicht innerhalb dieses Zeitraums antwortet, betrachten wir die Anwendung als ausgefallen. Beachten Sie, dass, wenn unsere Anfragen an Ihre Anwendung aus einer einzelnen Region fehlschlagen, dies nicht unbedingt bedeutet, dass Ihre Anwendung ausgefallen ist. Es könnte stattdessen auf ein Netzwerkproblem zwischen AWS Lambda und Ihrem Endpunkt hinweisen.

​
User Agent

Unsere Uptime-Monitoring-Anfragen an Ihre Anwendung setzen den User-Agent-Header wie folgt, wobei <version> eine Versionsnummer wie 1.0 ist:
Shell
AppSignalBot/<version> (+https://appsignal.com)
Damit können Sie erkennen, welche Anfragen von AppSignal kommen.

​
IP-Allowlisting

Wir führen unsere Uptime-Prüfungen auf einem Serverless-Framework aus und haben keine Kontrolle darüber, welche IP-Adresse verwendet wird, um die Anfrage an Ihre Anwendung zu stellen. Daher können wir keine Liste von IP-Adressen zum Allowlisting bereitstellen. Die zu überwachende URL muss vom offenen Internet aus öffentlich erreichbar sein.

​
Metriken

Für jede Uptime-Monitor-Prüfung erstellen wir mehrere Metriken, die Sie verwenden können, um Ihre eigenen benutzerdefinierten Graphen zu erstellen und Ihre eigenen Trigger zur Anomalieerkennung festzulegen. Diese Metriken werden mit der Region, aus der die Anfrage gestellt wurde, und dem Namen der Uptime-Monitor-Prüfung getaggt. Die Regions-Tags sind asia-pacific, europe, north-america und south-america.

​
Fehleranzahl

Die uptime_monitor_error_count-Metrik ist ein Counter, der für eine bestimmte Minute auf Null gesetzt wird, wenn die Anfrage erfolgreich war, oder auf eins, wenn die Anfrage fehlschlägt. Screenshot des Formulars für benutzerdefinierte Metriken für die Uptime-Monitoring-Fehleranzahl

​
Endpoint-Performance

Die uptime_monitor_duration-Metrik ist ein Gauge, der die Dauer der Anfrage für jede Region verfolgt. Damit können Sie sehen, ob die Latenz zu Ihren Servern zunimmt. Screenshot des Formulars für benutzerdefinierte Metriken für die Uptime-Monitoring-Performance

​
Pläne und Anfragen

Wenn die Anwendung, die die URL bereitstellt, eine AppSignal-Integration verwendet, kann unser Uptime-Monitor viele der monatlichen Anfragen Ihres Plans verbrauchen. Wir empfehlen, einen dedizierten Health-Check-Endpunkt einzurichten und AppSignal so zu konfigurieren, dass Anfragen an diesen Endpunkt ignoriert werden, damit sie nicht zum Limit Ihres Plans zählen.

​
Beispiel

Hier ist ein Beispiel für einen Health-Check-Endpunkt in Ruby on Rails. Wir stellen sicher, dass wir alle unsere externen Dienste wie die Datenbank und Redis ansprechen, etwas, das auf der Homepage möglicherweise nicht geschieht, um sicherzustellen, dass alle Dienste betriebsbereit sind. 
# routes.rb
resource :health_check, :only => :show

# health_checks_controller.rb
class HealthChecksController < ApplicationController
  def show
    # Check MongoDB
    Account.mongo_client.command(:getLastError => 1)
    # Check Redis
    Redis.new.ping
    head 200
  rescue Mongo::Error, Redis::CannotConnectError
    head 503
  end
end
Dann konfigurieren wir AppSignal so, dass Anfragen an diesen Endpunkt ignoriert werden, indem wir die Konfigurationsoption ignore_actions verwenden: 
Appsignal.configure do |config|
  config.ignore_actions << "HealthChecksController#show"
end