Bewaking en diagnose voor Azure Service Fabric

  • Artikel
  • 9 minuten om te lezen

Dit artikel biedt een overzicht van bewaking en diagnostische gegevens voor Azure Service Fabric. Bewaking en diagnose zijn essentieel voor het ontwikkelen, testen en implementeren van workloads in elke cloudomgeving. U kunt bijvoorbeeld bijhouden hoe uw toepassingen worden gebruikt, de acties die worden ondernomen door het Service Fabric-platform, uw resourcegebruik met prestatiemeters en de algehele status van uw cluster. U kunt deze informatie gebruiken om problemen vast te stellen en op te lossen, en om te voorkomen dat deze zich in de toekomst voordoen. In de volgende secties wordt elk gebied van de bewaking Service Fabric rekening moet worden gehouden voor productieworkloads.

Notitie

Dit artikel is onlangs bijgewerkt waarbij Log Analytics is vervangen door de term Azure Monitor-logboeken. Logboekgegevens worden nog steeds opgeslagen in een Log Analytics-werkruimte, en worden nog steeds verzameld en geanalyseerd met dezelfde Log Analytics-service. De terminologie wordt bijgewerkt om de rol van logboeken in Azure Monitor beter te weerspiegelen. Zie Wijzigingen in Azure Monitor-terminologie voor meer informatie.

Toepassingsbewaking

Toepassingsbewaking houdt bij hoe functies en onderdelen van uw toepassing worden gebruikt. U wilt uw toepassingen bewaken om ervoor te zorgen dat er problemen zijn die van invloed zijn op gebruikers. De verantwoordelijkheid van toepassingsbewaking is voor de gebruikers die een toepassing en de services ervan ontwikkelen, omdat deze uniek zijn voor de bedrijfslogica van uw toepassing. Het bewaken van uw toepassingen kan nuttig zijn in de volgende scenario's:

  • Hoeveel verkeer ondervindt mijn toepassing? - Moet u uw services schalen om te voldoen aan de eisen van de gebruiker of om een potentieel knelpunt in uw toepassing op te lossen?
  • Zijn mijn service-naar-service-aanroepen geslaagd en bij te houden?
  • Welke acties worden ondernomen door de gebruikers van mijn toepassing? - Het verzamelen van telemetrie kan de ontwikkeling van toekomstige functies en betere diagnoses voor toepassingsfouten helpen
  • Heeft mijn toepassing onverhandelde uitzonderingen?
  • Wat gebeurt er in de services die worden uitgevoerd in mijn containers?

Het fantastische van toepassingsbewaking is dat ontwikkelaars alle hulpprogramma's en frameworks kunnen gebruiken die ze willen, omdat deze zich binnen de context van uw toepassing kunnen houden. Meer informatie over de Azure-oplossing voor toepassingsbewaking met Azure Monitor - Application Insights vindt u in Gebeurtenisanalyse met Application Insights. We hebben ook een zelfstudie over het instellen van dit voor .NET-toepassingen. Deze zelfstudie gaat over het installeren van de juiste hulpprogramma's, een voorbeeld van het schrijven van aangepaste telemetrie in uw toepassing en het weergeven van de diagnostische gegevens en telemetrie van de toepassing in de Azure Portal.

Platformbewaking (cluster)

Een gebruiker heeft controle over welke telemetrie afkomstig is van de toepassing omdat een gebruiker de code zelf schrijft, maar hoe zit het met de diagnostische gegevens van het Service Fabric platform? Een van Service Fabric doel is om toepassingen bestand te houden tegen hardwarefouten. Dit doel wordt bereikt door de mogelijkheid van systeemservices van het platform om infrastructuurproblemen te detecteren en snel failover-workloads naar andere knooppunten in het cluster uit te kunnen pakken. Maar wat gebeurt er in dit specifieke geval als de systeemservices zelf problemen hebben? Of als bij een poging om een workload te implementeren of verplaatsen, de regels voor de plaatsing van services worden geschonden? Service Fabric biedt diagnostische gegevens voor deze en meer om ervoor te zorgen dat u op de hoogte bent van activiteiten die plaatsvinden in uw cluster. Enkele voorbeeldscenario's voor clusterbewaking zijn:

Service Fabric biedt een uitgebreide set gebeurtenissen die u kunt gebruiken. Deze Service Fabric zijn toegankelijk via de EventStore of het operationele kanaal (gebeurteniskanaal beschikbaar gemaakt door het platform).

  • Service Fabric-gebeurteniskanalen: op Windows zijn Service Fabric-gebeurtenissen beschikbaar via één ETW-provider met een set relevante die wordt gebruikt om te kiezen tussen operationele kanalen en Data & Messaging-kanalen. Dit is de manier waarop uitgaande Service Fabric-gebeurtenissen waar nodig op moeten worden logLevelKeywordFilters gefilterd. In Linux Service Fabric gebeurtenissen via LTTng en worden ze in één Storage gezet, van waar ze naar behoefte kunnen worden gefilterd. Deze kanalen bevatten gecureerde, gestructureerde gebeurtenissen die kunnen worden gebruikt om de status van uw cluster beter te begrijpen. Diagnostische gegevens zijn standaard ingeschakeld tijdens het maken van het cluster, waardoor een Azure Storage-tabel wordt gemaakt waarin de gebeurtenissen van deze kanalen worden verzonden zodat u in de toekomst een query kunt uitvoeren.

  • EventStore: de EventStore is een functie die wordt aangeboden door het platform dat Service Fabric platformgebeurtenissen biedt die beschikbaar zijn in de Service Fabric Explorer en via REST API. U kunt voor elke entiteit een momentopnameweergave bekijken van wat er in uw cluster gebeurt, bijvoorbeeld knooppunt, service, toepassing en query op basis van het tijdstip van de gebeurtenis. U kunt ook Meer informatie over de EventStore vinden in het EventStore-overzicht.

Schermopname toont het tabblad GEBEURTENISSEN van het deelvenster Knooppunten verschillende gebeurtenissen, waaronder een NodeDown-gebeurtenis.

De verstrekte diagnostische gegevens hebben de vorm van een uitgebreide set gebeurtenissen. Deze Service Fabric gebeurtenissen illustreren acties die door het platform worden uitgevoerd op verschillende entiteiten, zoals knooppunten, toepassingen, services, partities, enzovoort. In het laatste scenario hierboven, als een knooppunt uit zou gaan, zou het platform een gebeurtenis uitzenden en zou u direct een melding kunnen ontvangen van het bewakingshulpprogramma NodeDown van uw keuze. Andere veelvoorkomende voorbeelden zijn ApplicationUpgradeRollbackStarted of PartitionReconfigured tijdens een failover. Dezelfde gebeurtenissen zijn beschikbaar in zowel Windows linux-clusters.

De gebeurtenissen worden verzonden via standaardkanalen op Windows linux en kunnen worden gelezen door elk bewakingshulpprogramma dat dit ondersteunt. De Azure Monitor oplossing bestaat uit Azure Monitor logboeken. Lees hier meer over onze integratie Azure Monitor logboeken, waaronder een aangepast operationeel dashboard voor uw cluster en enkele voorbeeldquery's van waaruit u waarschuwingen kunt maken. Meer clusterbewakingsconcepten zijn beschikbaar op gebeurtenis- en logboekgeneratie op platformniveau.

Statuscontrole

Het Service Fabric-platform bevat een statusmodel dat extensible health reporting biedt voor de status van entiteiten in een cluster. Elk knooppunt, elke toepassing, service, partitie, replica of instantie heeft een continu bijwerkbare status. De status kan 'OK', 'Waarschuwing' of 'Fout' zijn. U kunt Service Fabric gebeurtenissen zien als werkwoorden die door het cluster worden uitgevoerd voor verschillende entiteiten en status als een bijvoeglijk naamwoord voor elke entiteit. Telkens als de status van een bepaalde entiteit overkomt, wordt er ook een gebeurtenis uitgezonden. Op deze manier kunt u query's en waarschuwingen instellen voor statusgebeurtenissen in het bewakingshulpprogramma van uw keuze, net als elke andere gebeurtenis.

Daarnaast laten we gebruikers zelfs de status van entiteiten overschrijven. Als uw toepassing een upgrade doormaakt en validatietests mislukken, kunt u naar Service Fabric Health schrijven met behulp van de Health-API om aan te geven dat uw toepassing niet meer in orde is en Service Fabric de upgrade automatisch terugdraaien. Bekijk de inleiding tot het controleren van de status van Service Fabric voor meer informatie over het statusmodel

SFX-statusdashboard

Waakhonden

Over het algemeen is een watchdog een afzonderlijke service die de status en belasting van services bewaakt, eindpunten pingt en onverwachte statusgebeurtenissen in het cluster rapporteert. Dit kan helpen bij het voorkomen van fouten die mogelijk niet worden gedetecteerd op basis van de prestaties van één service. Watchdogs zijn ook een goede plaats voor het hosten van code die herstelacties uitvoert waarvoor geen tussenkomst van de gebruiker is vereist, zoals het opsnuwen van logboekbestanden in de opslag met bepaalde tijdsintervallen. Zie het project FabricObserver als u een volledig geïmplementeerde open source SF Watchdog-service wilt met een eenvoudig te gebruiken watchdog-extensibility-model dat wordt uitgevoerd in zowel Windows- als Linux-clusters. FabricObserver is software die gereed is voor productie. We raden u aan FabricObserver te implementeren in uw test- en productieclusters en deze uit te breiden om aan uw behoeften te voldoen via het ingebouwde model of door het te forken en uw eigen ingebouwde waarnemers te schrijven. De eerste methode (in plug-ins) is de aanbevolen aanpak.

Bewaking van infrastructuur (prestaties)

Nu we de diagnostische gegevens in uw toepassing en het platform hebben behandeld, hoe weten we dan dat de hardware werkt zoals verwacht? Het bewaken van uw onderliggende infrastructuur is een belangrijk onderdeel van het begrijpen van de status van uw cluster en uw resourcegebruik. Het meten van de systeemprestaties is afhankelijk van veel factoren die subjectief kunnen zijn, afhankelijk van uw workloads. Deze factoren worden doorgaans gemeten via prestatiemeters. Deze prestatiemeters kunnen afkomstig zijn uit verschillende bronnen, waaronder het besturingssysteem, het .NET Framework of het Service Fabric platform zelf. Enkele scenario's waarin ze nuttig zijn, zijn

  • Gebruik ik mijn hardware efficiënt? Wilt u uw hardware met 90% CPU of 10% CPU gebruiken? Dit is handig bij het schalen van uw cluster of het optimaliseren van de processen van uw toepassing.
  • Kan ik problemen met de infrastructuur proactief voorspellen? - veel problemen worden voorafgegaan door plotselinge wijzigingen (dalingen) in de prestaties, zodat u prestatiemeters zoals netwerk-I/O en CPU-gebruik kunt gebruiken om de problemen proactief te voorspellen en te diagnosticeren.

Een lijst met prestatiemeters die moeten worden verzameld op infrastructuurniveau vindt u op Prestatiemetrieken.

Service Fabric bevat ook een set prestatiemeters voor de programmeermodellen Reliable Services en Actors. Als u een van deze modellen gebruikt, kunnen deze prestatiemeters informatie bieden om ervoor te zorgen dat uw actoren goed draaien of dat uw betrouwbare serviceaanvragen snel genoeg worden verwerkt. Zie Monitoring for Reliable Service Remoting and Performance monitoring for Reliable Actors voor meer Reliable Actors.

De Azure Monitor voor het verzamelen van deze logboeken is Azure Monitor net als bewaking op platformniveau. Gebruik de Log Analytics-agent om de juiste prestatiemeters te verzamelen en deze weer te geven in Azure Monitor logboeken.

Nu we elk gebied van bewakings- en voorbeeldscenario's hebben bekeken, volgt hier een samenvatting van de Azure-bewakingshulpprogramma's en wordt ingesteld dat nodig is om alle bovenstaande gebieden te bewaken.

U kunt ook de ARM-voorbeeldsjabloon gebruiken en wijzigen om de implementatie van alle benodigde resources en agents te automatiseren.

Andere oplossingen voor logboekregistratie

Hoewel de twee oplossingen die we hebben aanbevolen, hebben Azure Monitor-logboeken en Application Insights ingebouwde integratie met Service Fabric, veel gebeurtenissen worden weggeschreven via ETW-providers en kunnen worden uitgevoerd met andere oplossingen voor logboekregistratie. U moet ook kijken naar de Elastic Stack (met name als u overweegt een cluster in een offline omgeving uit te stellen), Dynatraceof een ander platform van uw voorkeur. Hier is een lijst met geïntegreerde partners beschikbaar.

De belangrijkste punten voor elk platform dat u kiest, zijn onder andere hoe vertrouwd u bent met de gebruikersinterface, de querymogelijkheden, de beschikbare aangepaste visualisaties en dashboards en de extra hulpprogramma's die ze bieden om uw bewakingservaring te verbeteren.

Volgende stappen