Patroon voor eindpuntstatusbewaking

Functionele controles implementeren in een toepassing die externe hulpprogramma's met regelmatige intervallen kunnen benaderen via beschikbaar gestelde eindpunten. Dit kan helpen om te controleren of toepassingen en services goed worden uitgevoerd.

Context en probleem

Het is raadzaam, en vaak een organisatorische vereiste, om webtoepassingen en back-endservices te controleren, zodat ze beschikbaar zijn en goed functioneren. Soms is het echter moeilijker om services te bewaken die in de cloud worden uitgevoerd dan om on-premises services te bewaken. U hebt bijvoorbeeld geen volledige controle over de hostomgeving en de services zijn meestal afhankelijk van andere services die door platformleveranciers en anderen worden geleverd.

Er zijn talloze factoren die van invloed zijn op toepassingen die in de cloud worden gehost, zoals netwerklatentie, de prestaties en beschikbaarheid van de onderliggende berekenings- en opslagsystemen en de netwerkbandbreedte daartussen. De service kan volledig of gedeeltelijk mislukken vanwege een van deze factoren. Daarom moet u op gezette tijden controleren of de service goed functioneert met het oog op het vereiste niveau van beschikbaarheid, wat deel kan uitmaken van uw serviceovereenkomst (SLA).

Oplossing

Implementeer statuscontrole door verzoeken te sturen naar een eindpunt van de toepassing. De toepassing moet de vereiste controles uitvoeren en een indicatie van de status retourneren.

In een statuscontrole worden doorgaans twee factoren gecombineerd:

• De controles (indien van toepassing) uitgevoerd door de toepassing of service als reactie op de aanvraag voor het eindpunt van de statusverificatie.
• Analyse van de resultaten door het hulpprogramma of framework dat de statusverificatie uitvoert.

De responscode geeft de status van de toepassing aan en desgewenst ook van onderdelen of services die door de toepassing worden gebruikt. De controle op latentie of reactietijd wordt uitgevoerd door het hulpprogramma of framework. De afbeelding bevat een overzicht van het patroon.

Enkele andere controles die kunnen worden uitgevoerd door de code voor statuscontrole in de toepassing:

• Cloud-opslag of een database controleren op beschikbaarheid en reactietijd.
• Controleren van andere resources of services die zich in de toepassing of ergens anders bevinden, maar wel door de toepassing worden gebruikt.

Er zijn services en hulpprogramma's beschikbaar die webtoepassingen controleren door een aanvraag naar een configureerbare verzameling eindpunten te sturen en de resultaten te evalueren aan de hand van een verzameling configureerbare regels. Het is betrekkelijk eenvoudig een service-eindpunt te maken met als enig doel het uitvoeren van enkele functionele tests op het systeem.

Controles die vaak door de controleprogramma's worden uitgevoerd zijn onder andere:

• Valideren van de responscode. Zo geeft een HTTP-respons van 200 (OK) aan dat de toepassing zonder fouten heeft gereageerd. Het controlesysteem kan ook andere responscodes controleren om uitgebreidere resultaten te leveren.
• De inhoud van de respons controleren op fouten, ook wanneer de statuscode 200 (OK) wordt geretourneerd. Hiermee kunnen fouten worden opgespoord die slechts op een deel van de geretourneerde webpagina- of servicerespons invloed hebben. Dat kan bijvoorbeeld het controleren van de titel van een pagina zijn of zoeken naar een specifieke woordgroep die aangeeft dat de juiste pagina is geretourneerd.
• Meten van de reactietijd, die een combinatie aangeeft van de netwerklatentie en de tijd die de toepassing nodig had om de aanvraag uit te voeren. Een toenemende waarde kan duiden op een opkomend probleem met de toepassing of het netwerk.
• Controleren van resources of services die zich buiten de toepassing bevinden, zoals een netwerk voor contentlevering dat door de toepassing wordt gebruikt om content uit globale caches te leveren.
• Controleren op de vervaldatum van SSL-certificaten.
• Meten van de reactietijd van een DNS-zoekactie voor de URL van de toepassing om DNS-latentie en DNS-fouten te meten.
• Valideren van de URL die wordt geretourneerd door de DNS-zoekactie om te controleren op juiste vermeldingen. Dit kan helpen om omleiding van schadelijke aanvragen via een geslaagde aanval op de DNS-server te voorkomen.

Het kan ook handig zijn om deze controles uit te voeren vanaf verschillende on-premises of gehoste locaties om reactietijden te meten en vergelijken. In het ideale geval zou u toepassingen moeten controleren vanaf locaties die zich dicht bij klanten bevinden om een nauwkeurig beeld van de prestaties van elke locatie te krijgen. De resultaten bieden niet alleen een krachtiger controlemechanisme, maar u kunt er ook mee bepalen wat de beste implementatielocatie voor de toepassing is en of deze in meer dan één datacenter moet worden geïmplementeerd.

Er moeten ook tests ook worden uitgevoerd voor alle service-instanties waarvan klanten gebruikmaken om ervoor te zorgen dat de toepassing voor alle klanten correct functioneert. Als bijvoorbeeld de opslag voor de klant over meer dan één opslagaccount verspreid is, moet het controleproces al deze accounts nalopen.

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

Het valideren van het antwoord. Is bijvoorbeeld slechts één 200 (OK)-statuscode voldoende om te controleren of de toepassing goed functioneert? Dit is weliswaar de meest eenvoudige meting van de beschikbaarheid van toepassingen en tevens de minimale implementatie van dit patroon, maar het geeft slechts weinig informatie over de bewerkingen, trends en mogelijk aanstaande problemen in de toepassing.

Het aantal eindpunten dat voor een toepassing beschikbaar wordt gesteld. Een van de manieren is ten minste één eindpunt beschikbaar stellen voor de kernservices waarvan de toepassing gebruikmaakt en een andere voor services met lagere prioriteit, zodat aan elk controleresultaat verschillende niveaus van belangrijkheid kunnen worden toegewezen. U zou ook meer eindpunten beschikbaar kunnen stellen, bijvoorbeeld een voor elke kernservice, om de controle verder te verfijnen. Een statuscontrole kan bijvoorbeeld betrekking hebben op een database, opslag en externe geocoderingservice waarvan een toepassing gebruikmaakt, waarbij elk een ander niveau van beschikbaarheid en reactietijd vereist. De toepassing kan nog steeds in orde zijn als de geocoderingservice of een andere achtergrondtaak enkele minuten niet beschikbaar is.

Hiermee wordt bepaald of hetzelfde eindpunt voor bewaking moet worden gebruikt als voor algemene toegang, maar voor een specifiek pad dat is ontworpen voor statuscontrole, bijvoorbeeld /health op het eindpunt voor algemene toegang. Hierdoor kunnen sommige functionele tests in de toepassing worden uitgevoerd door de controleprogramma's, zoals een nieuwe gebruikersregistratie toevoegen, aanmelding en een testorder plaatsen, terwijl ook kan worden gecontroleerd of het eindpunt voor algemene toegang beschikbaar is.

Het type informatie dat in de service moet worden verzameld als reactie op bewakingsaanvragen en hoe deze informatie moet worden retourneren. De meeste bestaande hulpprogramma's en frameworks kijken alleen naar de HTTP-statuscode die het eindpunt als resultaat geeft. Als u aanvullende informatie wilt retourneren en valideren, moet u wellicht een aangepaste controlefunctie of -service maken.

Hoeveel gegevens er moeten worden verzameld. Overmatige verwerking tijdens de controle kan de toepassing overbelasten en gevolgen hebben voor andere gebruikers. De benodigde tijd kan langer duren dan de time-out van het controlesysteem, waardoor de toepassing als niet beschikbaar wordt gemarkeerd. De meeste toepassingen bevatten functies zoals foutenhandlers en prestatiemeteritems die prestatiegegevens en uitgebreide foutinformatie registreren. Dat kan voldoende zijn zodat er geen extra informatie door een statuscontrole hoeft te worden geretourneerd.

De eindpuntstatus opslaan in het cachegeheugen. Het te vaak uitvoeren van een statuscontrole kan een kostbare aangelegenheid zijn. Als de status bijvoorbeeld wordt gerapporteerd via een dashboard, wilt u niet dat elke aanvraag op het dashboard een statuscontrole activeert. Controleer in plaats daarvan de systeemstatus op gezette tijden en sla de status op in de cache. Stel een eindpunt beschikbaar dat de status in het cachegeheugen retourneert.

Het configureren van beveiliging voor de bewakings-eindpunten om ze te beschermen tegen openbare toegang, waardoor de toepassing kan worden blootgesteld aan schadelijke aanvallen, het risico bestaat dat gevoelige informatie wordt blootgesteld of DoS-aanvallen (Denial of Service) worden aan trekken. Meestal moet dit worden ingesteld in de configuratie van de toepassing zodat deze eenvoudig kan worden bijgewerkt zonder de toepassing opnieuw op te starten. Overweeg het gebruik van een of meer van de volgende technieken:

• Beveilig het eindpunt door verificatie te vereisen. U kunt dit doen met behulp van een verificatiesleutel voor beveiliging in de aanvraagheader of door referenties te verstrekken bij de aanvraag, mits de controlefunctie of -service verificatie ondersteunt.

  • Gebruik een cryptisch of verborgen eindpunt. Stel het eindpunt bijvoorbeeld beschikbaar op een ander IP-adres dan het adres dat door de URL van de standaardtoepassing wordt gebruikt, configureer het eindpunt op een niet-standaard HTTP-poort en/of gebruik een complex pad naar de testpagina. Meestal kunt u extra eindpuntadressen en -poorten opgeven in de toepassingsconfiguratie en vermeldingen voor deze eindpunten toevoegen aan de DNS-server, als dat nodig is om te voorkomen dat de IP-adres rechtstreeks moeten worden opgegeven.

  • Stel een methode beschikbaar op een eindpunt dat een parameter zoals een sleutelwaarde of een waarde voor de bewerkingsmodus accepteert. Afhankelijk van de voor deze parameter opgegeven waarde, kan de code bij ontvangst van een aanvraag een specifieke test of reeks van tests uitvoeren of een 404 (Niet gevonden)-fout retourneren als de parameterwaarde niet wordt herkend. De herkende parameterwaarden kunnen worden ingesteld in de toepassingsconfiguratie.

    DoS-aanvallen hebben wellicht minder impact op een afzonderlijk eindpunt dat elementaire functionele tests uitvoert zonder de werking van de toepassing negatief te beïnvloeden. Vermijd in het ideale geval gebruik van een test waarmee gevoelige gegevens openbaar kunnen worden gemaakt. Als u informatie moet retourneren die nuttig kan zijn voor een aanvaller, denk dan na over hoe u het eindpunt en de gegevens het beste kunt beschermen tegen onbevoegde toegang. In dit geval is alleen op onbekendheid vertrouwen niet voldoende. Overweeg zeker ook het gebruik van een HTTPS-verbinding en het versleutelen van gevoelige gegevens, hoewel daardoor wel de belasting van de server wordt verhoogd.

• Het openen van een eindpunt dat is beveiligd met behulp van verificatie is een punt dat moet worden overwogen bij het evalueren van eindpunten voor statuscontrole en eindpunten die het gebruiken. De ingebouwde statuscontrole App Service bijvoorbeeld geïntegreerd met de verificatie- en autorisatiefuncties van App Service van uw systeem.

Hoe u ervoor kunt zorgen dat de bewakingsagent correct wordt uitgevoerd. Een van de mogelijkheden is een eindpunt beschikbaar te stellen dat een waarde uit de configuratie van de toepassing of een willekeurige waarde retourneert die kan worden gebruikt om de agent te testen.

Let er ook op dat het controlesysteem zichzelf controleert, bijvoorbeeld met een zelftest en ingebouwde test, om te voorkomen dat er fout-positieve resultaten worden gegeven.

Wanneer dit patroon gebruiken

Dit patroon is handig voor:

• Controleren van websites en webtoepassingen om de beschikbaarheid ervan te controleren.
• Controleren van websites en webtoepassingen om te controleren op een juiste werking.
• Controleren van services van de middelste laag of van gedeelde services om problemen te detecteren en isoleren die de werking van andere toepassingen kunnen verstoren.
• Aanvullen van bestaande instrumentatie in de toepassing, zoals prestatiemeteritems en foutenhandlers. Het uitvoeren van statuscontroles dient niet als vervanging van de vereiste voor registratie en auditing in de toepassing. Instrumentatie kan waardevolle informatie verstrekken voor een bestaand framework dat meteritems en foutenlogboeken controleert om storingen en andere problemen op te sporen. Er kan echter geen informatie worden verstrekt als de toepassing niet beschikbaar is.

Voorbeeld

Statuscontroles voor ASP.NET is middleware en een set bibliotheken voor het rapporteren van de status van onderdelen van de app-infrastructuur. Het biedt een framework voor het rapporteren van statuscontroles in een consistente methode, waarbij veel van de hierboven beschreven procedures worden geïmplementeerd. Dit omvat externe controles, zoals databaseconnectiviteit en specifieke concepten zoals liveheids- en gereedheidstests.

op GitHub.

Eindpunten in door Azure gehoste toepassingen controleren

Dit zijn enkele opties voor het controleren van eindpunten in Azure-toepassingen:

• Gebruik de ingebouwde controlefuncties van Azure.

• Gebruik een service van derden of een framework zoals Microsoft System Center Operations Manager.

• Maak een aangepast hulpprogramma of een service die op uw eigen server of op een gehoste server wordt uitgevoerd.

  Hoewel Azure een redelijk uitgebreide set controle-opties biedt, kunt u extra services en hulpprogramma's gebruiken om extra informatie te geven. Application Insights, een functie van Azure Monitor, is gericht op het ontwikkelteam, om u te helpen begrijpen hoe uw app presteert en hoe deze wordt gebruikt. Het bewaakt de aanvraagsnelheden, reactietijden, foutpercentages, afhankelijkheidssnelheden en foutpercentages en kan u helpen om erachter te komen of externe services u vertragen.

De voorwaarden die u kunt bewaken, variëren afhankelijk van het hostingmechanisme dat u voor uw toepassing kiest, maar al deze voorwaarden omvatten de mogelijkheid om een waarschuwingsregel te maken die gebruikmaakt van een web-eindpunt dat u opgeeft in de instellingen voor uw service. Dit eindpunt moet op tijd reageren, zodat het waarschuwingssysteem kan vaststellen of de toepassing correct functioneert.

Meer informatie over waarschuwingsmeldingen maken.

In het geval van een grote storing moet clientverkeer routeerbaar zijn naar een toepassingsimplementatie die beschikbaar blijft in andere regio's of zones. Dit is uiteindelijk waar cross-premises connectiviteit en globale taakverdeling moeten worden gebruikt, afhankelijk van of de toepassing intern en/of extern is. Services zoals Azure Front Door, Azure Traffic Manager of CDN's kunnen verkeer door regio's sturen op basis van de toepassingstoestand die wordt geleverd via statustests.

Azure Traffic Manager is een routerings- en taakverdelingsservice die aanvragen naar specifieke exemplaren van uw toepassing kan distribueren op basis van een reeks regels en instellingen. Naast het routeren van aanvragen pingt Traffic Manager een URL, poort en relatief pad die u op gezette tijden opgeeft om te bepalen welke instanties van de toepassing die in de regels van Traffic Manager zijn gedefinieerd, actief zijn en reageren op aanvragen. Als de statuscode 200 (OK) wordt gedetecteerd, wordt de toepassing als beschikbaar gemarkeerd. Bij elke andere statuscode markeert Traffic Manager de toepassing als offline. U kunt de status in de Traffic Manager-console weergeven en de regel configureren om aanvragen om te leiden naar andere instanties van de toepassing die reageren.

U Traffic Manager echter slechts een bepaalde tijd wachten om een reactie van de bewakings-URL te ontvangen. Daarom moet u ervoor zorgen dat uw code voor de statuscontrole binnen die tijd wordt uitgevoerd, rekening houdend met netwerklatentie bij het retourneren vanuit Traffic Manager naar uw toepassing en weer terug.

Verwante informatie

De volgende richtlijnen kunnen van pas komen bij de implementatie van dit patroon:

• Richtlijnen voor statuscontrole in toepassingen op basis van microservices
• Well-Architected bewakingstoepassings health for reliability van Well-Architected Framework
• Waarschuwingsmeldingen ontvangen