> ## 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.
# Uptime-Monitoring
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.
## Einrichtung
Um eine neue Uptime-Monitor-Prüfung einzurichten, klicken Sie auf der Seite [Uptime Monitoring](https://appsignal.com/redirect-to/app?to=uptime_monitors) 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 `` eine Versionsnummer wie `1.0` ist:
```sh Shell theme={null}
AppSignalBot/ (+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](/metrics/custom#graphing-custom-metrics) zu erstellen und Ihre eigenen [Trigger zur Anomalieerkennung](/anomaly-detection#creating-and-configuring-triggers) 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.
### 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.
## 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.
```ruby Ruby theme={null}
# routes.rb
resource :health_check, :only => :show
```
```ruby Ruby theme={null}
# 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`](/ruby/configuration/options#option-ignore_actions) verwenden:
```ruby Ruby theme={null}
Appsignal.configure do |config|
config.ignore_actions << "HealthChecksController#show"
end
```
```yaml YAML theme={null}
default: &defaults
ignore_actions:
- HealthChecksController#show
```