Patroon voor eindpuntstatusbewaking

Als u wilt controleren of toepassingen en services correct presteren, kunt u het patroon Statuseindpuntbewaking gebruiken. Dit patroon geeft het gebruik van functionele controles in een toepassing aan. Externe hulpprogramma's hebben regelmatig toegang tot deze controles via blootgestelde eindpunten.

Context en probleem

Het is een goede gewoonte om webtoepassingen en back-endservices te bewaken. Bewaking zorgt ervoor dat toepassingen en services beschikbaar zijn en correct presteren. Bedrijfsvereisten omvatten vaak bewaking.

Het is soms moeilijker om cloudservices te bewaken dan on-premises services. Een van de redenen is dat u geen volledige controle hebt over de hostingomgeving. Een andere is dat de services doorgaans afhankelijk zijn van andere services die platformleveranciers en anderen bieden.

Veel factoren zijn van invloed op toepassingen in de cloud. Voorbeelden zijn netwerklatentie, de prestaties en beschikbaarheid van de onderliggende reken- en opslagsystemen en de netwerkbandbreedte ertussen. Een service kan volledig of gedeeltelijk mislukken vanwege een van deze factoren. Om een vereist beschikbaarheidsniveau te garanderen, moet u met regelmatige tussenpozen controleren of uw service correct presteert. Uw SLA (Service Level Agreement) kan het niveau opgeven waaraan u moet voldoen.

Oplossing

Implementeer statuscontrole door aanvragen naar een eindpunt in uw toepassing te verzenden. De toepassing moet de benodigde controles uitvoeren en vervolgens een indicatie van de status ervan retourneren.

In een statuscontrole worden doorgaans twee factoren gecombineerd:

• De controles (indien aanwezig) die de toepassing of service uitvoert als reactie op de aanvraag voor het eindpunt voor statusverificatie
• De analyse van de resultaten door het hulpprogramma of framework dat de statuscontrole uitvoert

De antwoordcode geeft de status van de toepassing aan. Optioneel biedt de antwoordcode ook de status van onderdelen en services die door de app worden gebruikt. Het bewakingsprogramma of framework voert de latentie- of reactietijdcontrole uit.

In de volgende afbeelding ziet u een overzicht van het patroon.

De statuscontrolecode in de toepassing kan ook andere controles uitvoeren om te bepalen:

• De beschikbaarheid en reactietijd van cloudopslag of een database.
• De status van andere resources of services die door de toepassing worden gebruikt. Deze resources en services bevinden zich mogelijk in de toepassing of erbuiten.

Services en hulpprogramma's zijn beschikbaar die webtoepassingen bewaken door een aanvraag in te dienen bij een configureerbare set eindpunten. Deze services en hulpprogramma's evalueren vervolgens de resultaten op basis van een set configureerbare regels. Het is relatief eenvoudig om een service-eindpunt te maken voor het enige doel van het uitvoeren van enkele functionele tests op een systeem.

Typische controles die door bewakingshulpprogramma'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.
• Controleer de inhoud van het antwoord om fouten te detecteren, zelfs wanneer de statuscode 200 (OK) is. Door de inhoud te controleren, kunt u fouten detecteren die alleen van invloed zijn op een sectie van de geretourneerde webpagina of servicereactie. U kunt bijvoorbeeld de titel van een pagina controleren of zoeken naar een specifieke woordgroep die aangeeft dat de app de juiste pagina heeft geretourneerd.
• De reactietijd meten. De waarde omvat 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.
• Resources of services controleren die zich buiten de toepassing bevinden. Een voorbeeld is een netwerk voor contentlevering dat door de toepassing wordt gebruikt voor het leveren van inhoud uit globale caches.
• Controleren op het verlopen van TLS-certificaten.
• Het meten van de reactietijd van een DNS-zoekopdracht voor de URL van de toepassing. Met deze controle worden DNS-latentie en DNS-fouten berekend.
• Valideren van de URL die een DNS-zoekopdracht retourneert. Door te valideren, kunt u ervoor zorgen dat de vermeldingen juist zijn. U kunt ook kwaadwillende aanvraagomleiding voorkomen die kan resulteren na een aanval op uw DNS-server.

Waar mogelijk is het ook handig om deze controles uit te voeren vanaf verschillende on-premises of gehoste locaties en vervolgens reactietijden te vergelijken. In het ideale geval moet u toepassingen bewaken vanaf locaties die zich dicht bij klanten bevinden. Vervolgens krijgt u een nauwkeurige weergave van de prestaties van elke locatie. Deze procedure biedt een krachtiger controlemechanisme. De resultaten kunnen u ook helpen bij het nemen van de volgende beslissingen:

• Waar uw toepassing moet worden geïmplementeerd
• Of het in meer dan één datacenter moet worden geïmplementeerd

Voer tests uit op alle service-exemplaren die klanten gebruiken om ervoor te zorgen dat uw toepassing correct werkt voor alle klanten. Als de opslag van klanten bijvoorbeeld is verdeeld over meer dan één opslagaccount, moet het bewakingsproces elk account controleren.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Denk na over het valideren van het antwoord. Bepaal bijvoorbeeld of een statuscode van 200 (OK) voldoende is om te controleren of de toepassing correct werkt. Het controleren van de statuscode is de minimale implementatie van dit patroon. Een statuscode biedt een eenvoudige meting van de beschikbaarheid van toepassingen. Maar een code bevat weinig informatie over de bewerkingen, trends en mogelijke toekomstige problemen in de toepassing.

• Bepaal het aantal eindpunten dat moet worden weergegeven voor een toepassing. Een benadering is om ten minste één eindpunt beschikbaar te maken voor de kernservices die door de toepassing worden gebruikt en een andere voor services met een lagere prioriteit. Met deze aanpak kunt u verschillende urgentieniveaus toewijzen aan elk bewakingsresultaat. Overweeg ook extra eindpunten beschikbaar te maken. U kunt er een beschikbaar maken voor elke kernservice om de granulariteit van de bewaking te vergroten. Een statuscontrole kan bijvoorbeeld de database, de opslag en een externe geocoderingsservice controleren die een toepassing gebruikt. Elk vereist mogelijk een ander niveau van uptime en reactietijd. De geocoderingsservice of een andere achtergrondtaak is mogelijk enkele minuten niet beschikbaar. Maar de toepassing is mogelijk nog steeds in orde.

• Bepaal of u hetzelfde eindpunt wilt gebruiken voor bewaking en voor algemene toegang. U kunt hetzelfde eindpunt voor beide gebruiken, maar een specifiek pad ontwerpen voor statusverificatiecontroles. U kunt bijvoorbeeld /health gebruiken op het eindpunt voor algemene toegang. Met deze aanpak kunnen bewakingshulpprogramma's enkele functionele tests uitvoeren in de toepassing. Voorbeelden hiervan zijn het registreren van een nieuwe gebruiker, het aanmelden en het plaatsen van een testorder. Tegelijkertijd kunt u ook controleren of het eindpunt voor algemene toegang beschikbaar is.

• Bepaal het type informatie dat moet worden verzameld in de service als reactie op bewakingsaanvragen. U moet ook bepalen hoe deze informatie moet worden geretourneerd. 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.

• Bepaal hoeveel informatie moet worden verzameld. Het uitvoeren van overmatige verwerking tijdens de controle kan de toepassing overbelasten en andere gebruikers beïnvloeden. De verwerkingstijd kan ook de time-out van het bewakingssysteem overschrijden. Als gevolg hiervan kan het systeem de toepassing markeren als niet beschikbaar. De meeste toepassingen omvatten instrumentatie, zoals fouthandlers en prestatiemeteritems. Deze hulpprogramma's kunnen de prestaties en gedetailleerde foutinformatie vastleggen, wat mogelijk voldoende is. Overweeg om deze gegevens te gebruiken in plaats van aanvullende informatie te retourneren uit een statusverificatiecontrole.

• Overweeg om de eindpuntstatus in de cache op te nemen. Het uitvoeren van de statuscontrole kan vaak duur zijn. Als de status bijvoorbeeld wordt gerapporteerd via een dashboard, wilt u niet dat elke aanvraag naar het dashboard een statuscontrole activeert. Controleer in plaats daarvan regelmatig de systeemstatus en sla de status in de cache op. Stel een eindpunt beschikbaar dat de status in het cachegeheugen retourneert.

• Plan hoe u beveiliging configureert voor de bewakingseindpunten. Door beveiliging te configureren, kunt u helpen de eindpunten te beschermen tegen openbare toegang, wat het volgende kan doen:

  • De toepassing blootstellen aan schadelijke aanvallen.
  • Risico lopen op blootstelling van gevoelige informatie.
  • DoS-aanvallen (Denial of Service) aantrekken.

  Normaal gesproken configureert u beveiliging in de toepassingsconfiguratie. Vervolgens kunt u de instellingen eenvoudig bijwerken 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. Als de bewakingsservice of het hulpprogramma verificatie ondersteunt, kunt u een verificatiebeveiligingssleutel gebruiken in de aanvraagheader. U kunt ook referenties doorgeven aan de aanvraag. Wanneer u verificatie gebruikt, kunt u overwegen om toegang te krijgen tot uw statuscontrole-eindpunten. Als voorbeeld heeft Azure-app Service een ingebouwde statuscontrole die kan worden geïntegreerd met App Service-verificatie- en autorisatiefuncties.

  • Gebruik een cryptisch of verborgen eindpunt. Stel het eindpunt beschikbaar op een ander IP-adres dan het eindpunt dat door de standaardtoepassings-URL wordt gebruikt. Configureer het eindpunt op een niet-standaard HTTP-poort. Overweeg ook om een complex pad naar uw testpagina te gebruiken. U kunt meestal extra eindpuntadressen en poorten opgeven in de toepassingsconfiguratie. Indien nodig kunt u vermeldingen voor deze eindpunten toevoegen aan de DNS-server. Vervolgens vermijdt u dat u het IP-adres rechtstreeks moet opgeven.

  • Stel een methode beschikbaar op een eindpunt dat een parameter zoals een sleutelwaarde of een waarde voor de bewerkingsmodus accepteert. Wanneer een aanvraag binnenkomt, kan de code specifieke tests uitvoeren die afhankelijk zijn van de waarde van de parameter. De code kan een 404-fout (niet gevonden) retourneren als de parameterwaarde niet wordt herkend. Maak het mogelijk om parameterwaarden in de toepassingsconfiguratie te definiëren.

  • Gebruik een afzonderlijk eindpunt dat eenvoudige functionele tests uitvoert zonder de werking van de toepassing in gevaar te brengen. Met deze aanpak kunt u helpen de impact van een DoS-aanval te verminderen. Vermijd in het ideale geval gebruik van een test waarmee gevoelige gegevens openbaar kunnen worden gemaakt. Soms moet u informatie retourneren die nuttig kan zijn voor een aanvaller. In dit geval kunt u overwegen hoe u het eindpunt en de gegevens kunt beveiligen tegen onbevoegde toegang. Vertrouwen op obscuriteit is niet voldoende. Overweeg ook een HTTPS-verbinding te gebruiken en gevoelige gegevens te versleutelen, hoewel deze benadering de belasting op de server verhoogt.

• Bepaal hoe u ervoor kunt zorgen dat de bewakingsagent correct presteert. Een benadering is het beschikbaar maken van een eindpunt dat een waarde retourneert uit de toepassingsconfiguratie of een willekeurige waarde die u kunt gebruiken om de agent te testen. Zorg er ook voor dat het bewakingssysteem controles op zichzelf uitvoert. U kunt een zelftest of ingebouwde test gebruiken om te voorkomen dat het bewakingssysteem fout-positieve resultaten geeft.

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.
• Bewaking van de middelste laag of gedeelde services om fouten te detecteren en isoleren die andere toepassingen kunnen verstoren.
• Aanvullen van bestaande instrumentatie in de toepassing, zoals prestatiemeteritems en foutenhandlers. Statuscontrole vervangt geen toepassingsvereisten voor logboekregistratie en controle. Instrumentatie kan waardevolle informatie verstrekken voor een bestaand framework dat meteritems en foutenlogboeken controleert om storingen en andere problemen op te sporen. Maar instrumentatie kan geen informatie opgeven als een toepassing niet beschikbaar is.

Workloadontwerp

Een architect moet evalueren hoe het patroon Statuseindpuntbewaking kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

U kunt de ASP.NET middleware en bibliotheken gebruiken om de status van onderdelen van de app-infrastructuur te rapporteren. Dit framework biedt een manier om statuscontroles op een consistente manier te rapporteren. Het implementeert veel van de procedures die in dit artikel worden beschreven. De ASP.NET statuscontroles bevatten bijvoorbeeld externe controles, zoals databaseconnectiviteit en specifieke concepten, zoals liveness- en gereedheidstests.

Verschillende voorbeeld-implementaties die gebruikmaken van ASP.NET statuscontroles zijn beschikbaar op GitHub.

Eindpunten bewaken in door Azure gehoste toepassingen

Opties voor het bewaken van eindpunten in Azure-toepassingen zijn:

• Gebruik de ingebouwde bewakingsfuncties van Azure, zoals Azure Monitor.
• Gebruik een service van derden of een framework zoals Microsoft System Center Operations Manager.
• Maak een aangepast hulpprogramma of een service die wordt uitgevoerd op uw eigen server of een gehoste server.

Hoewel Azure uitgebreide bewakingsopties biedt, kunt u aanvullende services en hulpprogramma's gebruiken om extra informatie te bieden. Application Insights, een functie van Monitor, is ontworpen voor ontwikkelteams. Met deze functie krijgt u inzicht in hoe uw app presteert en hoe deze wordt gebruikt. Application Insights bewaakt aanvraagsnelheden, reactietijden, foutpercentages en afhankelijkheidssnelheden. Hiermee kunt u bepalen of externe services u vertragen.

De voorwaarden die u kunt bewaken, zijn afhankelijk van het hostingmechanisme dat u voor uw toepassing kiest. Alle opties in deze sectie ondersteunen waarschuwingsregels. Een waarschuwingsregel maakt gebruik van een webeindpunt 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. Zie Een nieuwe waarschuwingsregel maken voor meer informatie.

Als er sprake is van een grote storing, moet clientverkeer routeerbaar zijn voor een toepassingsimplementatie die beschikbaar is in andere regio's of zones. Deze situatie is een goed geval voor cross-premises connectiviteit en wereldwijde taakverdeling. De keuze is afhankelijk van of de toepassing intern of extern is. Services zoals Azure Front Door, Azure Traffic Manager of netwerken voor contentlevering kunnen verkeer routeren tussen regio's op basis van gegevens die statustests bieden.

Traffic Manager is een routerings- en taakverdelingsservice. Het kan een reeks regels en instellingen gebruiken om aanvragen te distribueren naar specifieke exemplaren van uw toepassing. Naast routeringsaanvragen kan Traffic Manager regelmatig een URL, poort en relatief pad pingen. U geeft de pingdoelen op met het doel te bepalen welke exemplaren van uw toepassing actief zijn en reageren op aanvragen. Als Traffic Manager een statuscode van 200 (OK) detecteert, wordt de toepassing gemarkeerd als beschikbaar. Bij elke andere statuscode markeert Traffic Manager de toepassing als offline. In de Traffic Manager-console wordt de status van elke toepassing weergegeven. U kunt elke regel configureren om aanvragen om te leiden naar andere exemplaren van de toepassing die reageren.

Traffic Manager wacht tot een bepaalde tijd een reactie van de bewakings-URL ontvangt. Zorg ervoor dat uw statusverificatiecode in deze tijd wordt uitgevoerd. Sta netwerklatentie toe voor de retour van Traffic Manager naar uw toepassing en weer terug.

Volgende stappen

De volgende richtlijnen zijn handig voor het implementeren van dit patroon:

• Richtlijnen voor statuscontrole in toepassingen op basis van microservices
• Toepassingsstatus voor betrouwbaarheid bewaken, onderdeel van het Azure Well-Architected Framework
• Een nieuwe waarschuwingsregel maken

Verwante resources

• Patroon extern configuratiearchief
• Patroon Circuitonderbreker
• Gateway Routing pattern (Patroon Routering van gateway)
• Gatekeeper-patroon