Naar hoofdinhoud gaan
Met AppSignal uptime monitoring kunt u meldingen ontvangen wanneer uw applicatie niet beschikbaar is. We controleren uw applicatie vanuit meerdere regio’s over de hele wereld en we waarschuwen u wanneer uw applicatie niet bereikbaar is vanuit een van deze regio’s. We maken ook grafieken van de prestaties van het endpoint dat u opgeeft vanuit verschillende regio’s over de hele wereld. Schermafbeelding van het uptime monitoring-dashboard

Installatie

Om een nieuwe uptime monitor-check in te stellen, klikt u op de knop “Add uptime monitor” op de Uptime Monitoring-pagina. Geef de volledige URL op (inclusief http:// of https://) van de pagina die u wilt controleren. Onze servers doen elke minuut vanuit meerdere regio’s een verzoek aan deze URL en melden of het verzoek mislukt of als de responsstatuscode niet in het 2xx-bereik valt. Om meldingen te ontvangen wanneer uw applicatie niet beschikbaar is, selecteert u een meldingsmethode. Om te voorkomen dat u meldingen ontvangt bij kleine netwerkhiccups, raden we aan een warm-up-periode voor meldingen van ten minste één minuut in te stellen. U kunt headers instellen die worden meegezonden in de verzoeken die we uitvoeren tegen de door u opgegeven URL. Hiermee kunt u autorisatieheaders instellen om de verzoeken te laten doorgaan.

Hoe het werkt

We pingen uw applicaties vanuit AWS Lambda-workers die vanuit de volgende regio’s worden uitgevoerd: We zullen de opgegeven URL aanvragen vanuit de volgende regio’s:
  • Azië-Pacific (Seoul)
  • Europa (Frankfurt)
  • Noord-Amerika (N. Virginia)
  • Zuid-Amerika (São Paulo)
Er geldt een time-out van 30 seconden voor de verbinding. Als uw server niet binnen die tijd reageert, beschouwen we de applicatie als niet beschikbaar. Houd er rekening mee dat als onze verzoeken aan uw applicatie mislukken vanuit één regio, dit niet noodzakelijk betekent dat uw applicatie niet beschikbaar is. Het kan in plaats daarvan duiden op een netwerkprobleem tussen AWS Lambda en uw endpoint.

User Agent

Onze uptime monitoring-verzoeken aan uw applicatie stellen de User-Agent-header als volgt in, waarbij <version> een versienummer is zoals 1.0:
Shell
AppSignalBot/<version> (+https://appsignal.com)
Hiermee kunt u verzoeken van AppSignal detecteren.

IP-allowlisting

We voeren onze uptime checks uit op een serverless framework en hebben geen controle over welk IP-adres wordt gebruikt om het verzoek aan uw applicatie te doen. Daarom kunnen we geen lijst met IP-adressen verstrekken om toe te voegen aan een allowlist. De te monitoren URL moet publiek bereikbaar zijn vanaf het open internet.

Metrics

Voor elke uptime monitor-check maken we verschillende metrics aan die u kunt gebruiken om uw eigen custom graphs te maken en uw eigen triggers voor anomaliedetectie in te stellen. Deze metrics worden getagd op basis van de region waarvandaan het verzoek is gedaan en de name van de uptime monitor-check. De regiotags zijn asia-pacific, europe, north-america en south-america.

Foutentelling

De uptime_monitor_error_count-metric is een teller die voor een bepaalde minuut wordt ingesteld op nul als het verzoek is gelukt of op één als het verzoek mislukt. Schermafbeelding van het uptime monitoring foutentelling custom metrics-formulier

Endpoint-prestaties

De uptime_monitor_duration-metric is een gauge die de duur van het verzoek voor elke regio bijhoudt. Hiermee kunt u zien of de latency naar uw servers toeneemt. Schermafbeelding van het uptime monitoring performance custom metrics-formulier

Plannen en verzoeken

Als de applicatie die de URL serveert een AppSignal-integratie gebruikt, kan onze uptime monitor veel van de maandelijkse verzoeken van uw plan verbruiken. We raden aan om een speciaal health-check-endpoint in te stellen en AppSignal te configureren om verzoeken aan dat endpoint te negeren, zodat ze niet meetellen voor de limiet van uw plan.

Voorbeeld

Hier is een voorbeeld van een health-check-endpoint in Ruby on Rails. We zorgen ervoor dat we al onze externe services raken, zoals de database en Redis, iets dat misschien niet op de homepage gebeurt, zodat alle services operationeel zijn.
# 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
Vervolgens configureren we AppSignal om verzoeken aan dat endpoint te negeren met de configuratieoptie ignore_actions:
Appsignal.configure do |config|
  config.ignore_actions << "HealthChecksController#show"
end