Waarneembaarheidspatronen

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Net zoals patronen zijn ontwikkeld om de indeling van code in toepassingen te helpen, zijn er patronen voor operationele toepassingen op een betrouwbare manier. Er zijn drie nuttige patronen ontstaan bij het onderhouden van toepassingen: logboekregistratie, bewaking en waarschuwingen.

Wanneer moet u logboekregistratie gebruiken

Hoe voorzichtig we ook zijn, toepassingen gedragen zich bijna altijd op onverwachte manieren in productie. Wanneer gebruikers problemen met een toepassing melden, is het handig om te zien wat er met de app is gebeurd toen het probleem zich voordeed. Een van de meest geprobeerde en echte manieren om informatie vast te leggen over wat een toepassing doet terwijl deze wordt uitgevoerd, is door de toepassing te laten opschrijven wat het doet. Dit proces wordt logboekregistratie genoemd. Wanneer er fouten of problemen optreden in de productieomgeving, moet het doel zijn om de omstandigheden te reproduceren waaronder de fouten zijn opgetreden, in een niet-productieomgeving. Een goede logboekregistratie biedt ontwikkelaars een routekaart om te volgen om problemen in een omgeving te dupliceren waarmee kan worden getest en geëxperimenteerd.

Uitdagingen bij logboekregistratie met cloudtoepassingen

In traditionele toepassingen worden logboekbestanden meestal opgeslagen op de lokale computer. In feite is er op Unix-achtige besturingssystemen een mapstructuur gedefinieerd voor het opslaan van logboeken, meestal onder /var/log.

Afbeelding 7-1. Logboekregistratie bij een bestand in een monolithische app.

Het nut van logboekregistratie naar een plat bestand op één computer is aanzienlijk verminderd in een cloudomgeving. Toepassingen die logboeken produceren, hebben mogelijk geen toegang tot de lokale schijf of de lokale schijf zijn mogelijk zeer tijdelijk omdat containers in willekeurige volgorde worden geplaatst rond fysieke machines. Zelfs eenvoudig omhoog schalen van monolithische toepassingen op meerdere knooppunten kan het lastig maken om het juiste op bestanden gebaseerde logboekbestand te vinden.

Afbeelding 7-2. Logboekregistratie bij bestanden in een geschaalde monolithische app.

Cloudeigen toepassingen die zijn ontwikkeld met behulp van een microservicearchitectuur vormen ook enkele uitdagingen voor logboekregistraties op basis van bestanden. Gebruikersaanvragen kunnen nu meerdere services omvatten die op verschillende computers worden uitgevoerd en kunnen serverloze functies bevatten die helemaal geen toegang hebben tot een lokaal bestandssysteem. Het zou erg lastig zijn om de logboeken van een gebruiker of een sessie over deze vele services en machines te correleren.

Afbeelding 7-3. Logboekregistratie naar lokale bestanden in een microservices-app.

Ten slotte is het aantal gebruikers in sommige cloudeigen toepassingen hoog. Stel dat elke gebruiker honderd regels logboekberichten genereert wanneer ze zich aanmelden bij een toepassing. Geïsoleerd, dat is beheerbaar, maar vermenigvuldig dat meer dan 100.000 gebruikers en het volume van logboeken wordt groot genoeg dat gespecialiseerde hulpprogramma's nodig zijn om effectief gebruik van de logboeken te ondersteunen.

Logboekregistratie in cloudtoepassingen

Elke programmeertaal heeft hulpprogramma's waarmee logboeken kunnen worden geschreven, en meestal is de overhead voor het schrijven van deze logboeken laag. Veel van de logboekregistratiebibliotheken bieden verschillende soorten kritieke kenmerken, die tijdens runtime kunnen worden afgestemd. De Serilog-bibliotheek is bijvoorbeeld een populaire bibliotheek voor gestructureerde logboekregistratie voor .NET die de volgende logboekregistratieniveaus biedt:

• Uitgebreid
• Fouten opsporen
• Gegevens
• Waarschuwing
• Fout
• Fataal

Deze verschillende logboekniveaus bieden granulariteit in logboekregistratie. Wanneer de toepassing goed functioneert in productie, kan deze zodanig worden geconfigureerd dat alleen belangrijke berichten worden vastgelegd. Wanneer de toepassing zich niet gedraagt, kan het logboekniveau worden verhoogd, zodat uitgebreidere logboeken worden verzameld. Dit zorgt voor een balans tussen prestaties tegen het gemak van foutopsporing.

De hoge prestaties van logboekregistratiehulpprogramma's en de tonijnbaarheid van uitgebreidheid moeten ontwikkelaars aanmoedigen om regelmatig te registreren. Veel geven de voorkeur aan een patroon van het vastleggen van de vermelding en het verlaten van elke methode. Deze benadering klinkt misschien als overkill, maar het is niet vaak dat ontwikkelaars minder logboekregistratie willen. Het is zelfs niet ongebruikelijk om implementaties uit te voeren voor het enige doel om logboekregistratie toe te voegen rond een problematische methode. Err aan de zijkant van te veel logboekregistratie en niet te weinig. Sommige hulpprogramma's kunnen worden gebruikt om dit soort logboekregistratie automatisch op te geven.

Vanwege de uitdagingen met betrekking tot het gebruik van logboeken op basis van bestanden in cloudeigen apps, hebben gecentraliseerde logboeken de voorkeur. Logboeken worden verzameld door de toepassingen en verzonden naar een centrale logboekregistratietoepassing die de logboeken indexeert en opslaat. Deze systeemklasse kan elke dag tientallen gigabytes aan logboeken opnemen.

Het is ook handig om enkele standaardprocedures te volgen bij het bouwen van logboekregistratie die veel services omvat. Als u bijvoorbeeld een correlatie-id aan het begin van een langdurige interactie genereert en deze vervolgens aanmeldt in elk bericht dat aan die interactie is gerelateerd, kunt u gemakkelijker zoeken naar alle gerelateerde berichten. Eén bericht hoeft slechts één bericht te vinden en de correlatie-id te extraheren om alle gerelateerde berichten te vinden. Een ander voorbeeld is ervoor te zorgen dat de logboekindeling voor elke service hetzelfde is, ongeacht de taal- of logboekregistratiebibliotheek die wordt gebruikt. Deze standaardisatie maakt het lezen van logboeken veel eenvoudiger. Afbeelding 7-4 laat zien hoe een microservicesarchitectuur gecentraliseerde logboekregistratie kan gebruiken als onderdeel van de werkstroom.

Afbeelding 7-4. Logboeken uit verschillende bronnen worden opgenomen in een gecentraliseerd logboekarchief.

Problemen met het detecteren en reageren op mogelijke problemen met de status van apps

Sommige toepassingen zijn niet bedrijfskritiek. Misschien worden ze alleen intern gebruikt en wanneer er een probleem optreedt, kan de gebruiker contact opnemen met het team dat verantwoordelijk is en kan de toepassing opnieuw worden gestart. Klanten hebben echter vaak hogere verwachtingen voor de toepassingen die ze gebruiken. U moet weten wanneer er problemen optreden met uw toepassing voordat gebruikers dit doen of voordat gebruikers u hiervan op de hoogte stellen. Anders kan het eerste wat u weet over een probleem zijn wanneer u een boze vloed van sociale media-berichten ziet die uw toepassing of zelfs uw organisatie onderdrukken.

Enkele scenario's die u moet overwegen, zijn onder andere:

• Eén service in uw toepassing blijft mislukken en opnieuw opstarten, wat resulteert in onregelmatige trage reacties.
• Op sommige momenten van de dag is de reactietijd van uw toepassing traag.
• Na een recente implementatie is de belasting van de database verdrievoudigd.

De bewaking kan u op de juiste manier laten weten over voorwaarden die tot problemen leiden, zodat u onderliggende voorwaarden kunt oplossen voordat ze leiden tot aanzienlijke gevolgen van de gebruiker.

Cloudeigen apps bewaken

Sommige gecentraliseerde logboekregistratiesystemen nemen een extra rol over het verzamelen van telemetrie buiten pure logboeken. Ze kunnen metrische gegevens verzamelen, zoals tijd voor het uitvoeren van een databasequery, gemiddelde reactietijd van een webserver en zelfs cpu-belastings gemiddelden en geheugenbelasting zoals gerapporteerd door het besturingssysteem. In combinatie met de logboeken kunnen deze systemen een holistische weergave bieden van de status van knooppunten in het systeem en de toepassing als geheel.

De mogelijkheden voor het verzamelen van metrische gegevens van de bewakingshulpprogramma's kunnen ook handmatig vanuit de toepassing worden ingevoerd. Bedrijfsstromen die van bijzonder belang zijn, zoals nieuwe gebruikers die zich registreren of bestellingen plaatsen, kunnen zodanig worden geïnstrueerd dat ze een teller in het centrale bewakingssysteem verhogen. Met dit aspect worden de bewakingshulpprogramma's ontgrendeld om niet alleen de status van de toepassing, maar ook de status van het bedrijf te bewaken.

Query's kunnen worden samengesteld in de hulpprogramma's voor logboekaggregatie om te zoeken naar bepaalde statistieken of patronen, die vervolgens in grafische vorm kunnen worden weergegeven, op aangepaste dashboards. Vaak investeren teams in grote, wandgemonteerde displays die door de statistieken met betrekking tot een toepassing draaien. Op deze manier is het eenvoudig om de problemen te zien terwijl ze optreden.

Cloudeigen bewakingshulpprogramma's bieden realtime telemetrie en inzicht in apps, ongeacht of ze monolithische toepassingen of gedistribueerde microservicearchitecturen zijn. Ze bevatten hulpprogramma's waarmee gegevens uit de app kunnen worden verzameld, evenals hulpprogramma's voor het opvragen en weergeven van informatie over de status van de app.

Problemen met het reageren op kritieke problemen in cloudeigen apps

Als u moet reageren op problemen met uw toepassing, hebt u een manier nodig om het juiste personeel te waarschuwen. Dit is het derde cloudeigen toepassingsobserveerbaarheidspatroon en is afhankelijk van logboekregistratie en bewaking. Uw toepassing moet zich aanmelden om problemen te kunnen diagnosticeren en in sommige gevallen om in te voeren in bewakingshulpprogramma's. Er moet worden gecontroleerd om metrische gegevens en statusgegevens van toepassingen op één plaats te aggregeren. Zodra dit is ingesteld, kunnen regels worden gemaakt waarmee waarschuwingen worden geactiveerd wanneer bepaalde metrische gegevens buiten acceptabele niveaus vallen.

Over het algemeen worden waarschuwingen gelaagd boven op bewaking, zodat bepaalde voorwaarden passende waarschuwingen activeren om teamleden op de hoogte te stellen van urgente problemen. In sommige scenario's waarvoor mogelijk waarschuwingen zijn vereist, zijn onder andere:

• Een van de services van uw toepassing reageert niet na 1 minuut downtime.
• Uw toepassing retourneert mislukte HTTP-antwoorden naar meer dan 1% van de aanvragen.
• De gemiddelde reactietijd van uw toepassing voor sleuteleindpunten overschrijdt 2000 ms.

Waarschuwingen in cloudeigen apps

U kunt query's maken op basis van de bewakingshulpprogramma's om te zoeken naar bekende foutvoorwaarden. Query's kunnen bijvoorbeeld zoeken in de binnenkomende logboeken naar indicaties van HTTP-statuscode 500, wat duidt op een probleem op een webserver. Zodra een van deze wordt gedetecteerd, kan er een e-mail of sms worden verzonden naar de eigenaar van de oorspronkelijke service die kan beginnen met onderzoeken.

Normaal gesproken is één 500-fout echter niet voldoende om te bepalen of er een probleem is opgetreden. Dit kan betekenen dat een gebruiker zijn of haar wachtwoord verkeerd heeft getypt of een aantal onjuiste gegevens heeft ingevoerd. De waarschuwingsquery's kunnen alleen worden gemaakt om te worden geactiveerd wanneer een groter dan gemiddeld aantal van 500 fouten wordt gedetecteerd.

Een van de meest schadelijke patronen in waarschuwingen is om te veel waarschuwingen te activeren voor mensen om te onderzoeken. Service-eigenaren worden snel ongevoelig voor fouten die ze eerder hebben onderzocht en die goedaardig zijn. Wanneer er dan echte fouten optreden, gaan ze verloren in de ruis van honderden fout-positieven. De parable van de Jongen Wie Cried Wolf wordt vaak aan kinderen verteld om hen te waarschuwen voor dit zeer gevaar. Het is belangrijk om ervoor te zorgen dat de waarschuwingen die worden geactiveerd, duiden op een echt probleem.

VorigeVolgende