Surveillance de la disponibilité - AppSignal Documentation

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.

Capture d'écran du tableau de bord de surveillance de la disponibilité

Configuration

Pour configurer une nouvelle vérification de moniteur de disponibilité, cliquez sur le bouton « Add uptime monitor » sur la page Uptime Monitoring. 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ù <version> est un numéro de version comme 1.0 :

Shell

AppSignalBot/<version> (+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 et définir vos propres déclencheurs de détection d’anomalies. 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.

Capture d'écran du formulaire de métriques personnalisées de performance de surveillance de la disponibilité

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.

# 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

Ensuite, nous configurons AppSignal pour ignorer les requêtes vers ce point de terminaison en utilisant l’option de configuration ignore_actions :

Appsignal.configure do |config|
  config.ignore_actions << "HealthChecksController#show"
end

​Configuration

​Comment ça fonctionne

​User Agent

​Liste d’autorisation IP

​Métriques

​Nombre d’erreurs

​Performance du point de terminaison

​Plans et requêtes

​Exemple