> ## 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.
# Surveillance de la disponibilité
Avec la surveillance de la disponibilité AppSignal, vous pouvez recevoir des alertes lorsque votre application est hors service.
Nous vérifions votre application depuis plusieurs régions à travers le monde, et nous vous alerterons lorsque votre application ne pourra pas être joignable depuis l'une de ces régions. Nous graphons également les performances du point de terminaison que vous fournissez depuis différentes régions du monde.
## Configuration
Pour configurer une nouvelle vérification de moniteur de disponibilité, cliquez sur le bouton « Add uptime monitor » sur la page [Uptime Monitoring](https://appsignal.com/redirect-to/app?to=uptime_monitors).
Fournissez l'URL complète (y compris `http://` ou `https://`) de la page que vous souhaitez vérifier. Nos serveurs effectueront une requête vers cette URL chaque minute depuis plusieurs régions et signaleront si la requête échoue ou si le code de statut de la réponse n'est pas dans la plage `2xx`.
Pour recevoir des notifications lorsque votre application est hors service, sélectionnez une méthode de notification. Pour éviter de recevoir des alertes lors de petites hoquets réseau, nous recommandons de définir une période de mise en route d'alerte d'au moins une minute.
Vous pouvez définir des en-têtes à envoyer dans les requêtes que nous effectuons vers l'URL que vous fournissez. Cela vous permet de définir des en-têtes d'autorisation pour permettre aux requêtes de passer.
## Comment ça fonctionne
Nous pingons vos applications depuis des workers AWS Lambda exécutés depuis les régions suivantes :
Nous demanderons l'URL donnée depuis les régions suivantes :
* Asie-Pacifique (Séoul)
* Europe (Francfort)
* Amérique du Nord (Virginie du Nord)
* Amérique du Sud (São Paulo)
Il y a un délai d'attente de 30 secondes pour la connexion. Si votre serveur ne répond pas dans ce laps de temps, nous considérons que l'application est hors service.
Notez que si nos requêtes vers votre application échouent depuis une seule région, cela ne signifie pas nécessairement que votre application est hors service. Cela pourrait plutôt indiquer un problème de réseau entre AWS Lambda et votre point de terminaison.
### User Agent
Nos requêtes de surveillance de la disponibilité vers votre application définiront l'en-tête `User-Agent` comme suit, où `` est un numéro de version comme `1.0` :
```sh Shell theme={null}
AppSignalBot/ (+https://appsignal.com)
```
Cela vous permet de détecter les requêtes provenant d'AppSignal.
### Liste d'autorisation IP
Nous exécutons nos vérifications de disponibilité sur un framework serverless et n'avons aucun contrôle sur l'adresse IP qui sera utilisée pour effectuer la requête vers votre application. Par conséquent, nous ne pouvons pas fournir une liste d'adresses IP à mettre en liste d'autorisation. L'URL à surveiller doit être publiquement accessible depuis Internet.
## Métriques
Pour chaque vérification de moniteur de disponibilité, nous créons plusieurs métriques que vous pouvez utiliser pour créer vos propres [graphiques personnalisés](/metrics/custom#graphing-custom-metrics) et définir vos propres [déclencheurs de détection d'anomalies](/anomaly-detection#creating-and-configuring-triggers).
Ces métriques seront étiquetées par la **region** depuis laquelle la requête a été effectuée, et le **name** de la vérification du moniteur de disponibilité. Les étiquettes de région sont `asia-pacific`, `europe`, `north-america` et `south-america`.
### Nombre d'erreurs
La métrique `uptime_monitor_error_count` est un compteur qui, pour une minute donnée, sera défini à zéro si la requête a réussi ou à un si la requête échoue.
### Performance du point de terminaison
La métrique `uptime_monitor_duration` est une jauge qui suit la durée de la requête pour chaque région. Cela vous permet de voir si la latence vers vos serveurs augmente.
## Plans et requêtes
Si l'application servant l'URL utilise une intégration AppSignal, notre moniteur de disponibilité peut consommer une grande partie des requêtes mensuelles de votre plan. Nous recommandons de configurer un point de terminaison de health-check dédié et de configurer AppSignal pour ignorer les requêtes vers ce point de terminaison afin qu'elles ne comptent pas dans la limite de votre plan.
### Exemple
Voici un exemple de point de terminaison de health-check dans Ruby on Rails. Nous nous assurons d'atteindre tous nos services externes, tels que la base de données et Redis, ce qui pourrait ne pas se produire sur la page d'accueil, garantissant que tous les services sont opérationnels.
```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
```
Ensuite, nous configurons AppSignal pour ignorer les requêtes vers ce point de terminaison en utilisant [l'option de configuration `ignore_actions`](/ruby/configuration/options#option-ignore_actions) :
```ruby Ruby theme={null}
Appsignal.configure do |config|
config.ignore_actions << "HealthChecksController#show"
end
```
```yaml YAML theme={null}
default: &defaults
ignore_actions:
- HealthChecksController#show
```