Delen via

Het cluster bewaken

  • Artikel

Het is belangrijk om te controleren op clusterniveau om te bepalen of uw hardware en cluster zich gedragen zoals verwacht. Hoewel Service Fabric toepassingen kan blijven uitvoeren tijdens een hardwarefout, maar u moet nog steeds vaststellen of er een fout optreedt in een toepassing of in de onderliggende infrastructuur. U moet ook uw clusters bewaken om capaciteit beter te plannen, zodat u beslissingen kunt nemen over het toevoegen of verwijderen van hardware.

Service Fabric toont verschillende gestructureerde platformgebeurtenissen, zoals Service Fabric-gebeurtenissen, via de EventStore en verschillende logboekkanalen out-of-the-box.

In Windows zijn Service Fabric-gebeurtenissen beschikbaar van één ETW-provider met een set relevante toepassingen logLevelKeywordFilters die worden gebruikt om te kiezen tussen operationele kanalen en gegevens en berichten. Dit is de manier waarop we uitgaande Service Fabric-gebeurtenissen scheiden waarop we waar nodig moeten worden gefilterd.

  • Operationele bewerkingen op hoog niveau die worden uitgevoerd door Service Fabric en het cluster, inclusief gebeurtenissen voor een knooppunt dat wordt geïmplementeerd, een nieuwe toepassing die wordt geïmplementeerd of een terugdraaiactie voor een upgrade, enzovoort. Bekijk hier de volledige lijst met gebeurtenissen.

  • Operationeel - gedetailleerd
    Statusrapporten en taakverdelingsbeslissingen.

Het bewerkingskanaal kan worden geopend via verschillende manieren, waaronder ETW-/Windows-gebeurtenislogboeken, de EventStore (beschikbaar in Windows in versies 6.2 en hoger voor Windows-clusters). De EventStore biedt u toegang tot de gebeurtenissen van uw cluster per entiteit (entiteiten zoals cluster, knooppunten, toepassingen, services, partities, replica's en containers) en maakt ze beschikbaar via REST API's en de Service Fabric-clientbibliotheek. Gebruik de EventStore om uw ontwikkel-/testclusters te bewaken en om inzicht te krijgen in de status van uw productieclusters.

  • Gegevens en berichten
    Kritieke logboeken en gebeurtenissen die zijn gegenereerd in de berichten (momenteel alleen reverseProxy) en gegevenspad (betrouwbare servicesmodellen).

  • Data & Messaging - gedetailleerd
    Uitgebreid kanaal dat alle niet-kritieke logboeken van gegevens en berichten in het cluster bevat (dit kanaal heeft een zeer groot aantal gebeurtenissen).

Daarnaast zijn er twee gestructureerde EventSource-kanalen beschikbaar, evenals logboeken die we verzamelen voor ondersteuningsdoeleinden.

  • Reliable Services-gebeurtenissen
    Specifieke gebeurtenissen in het programmeermodel.

  • Reliable Actors-gebeurtenissen
    Specifieke gebeurtenissen en prestatiemeteritems voor programmeermodellen.

  • Ondersteuningslogboeken
    Systeemlogboeken die door Service Fabric worden gegenereerd, worden alleen door ons gebruikt bij het bieden van ondersteuning.

Deze verschillende kanalen hebben betrekking op de meeste logboekregistratie op platformniveau die wordt aanbevolen. Voor het verbeteren van logboekregistratie op platformniveau kunt u overwegen om beter inzicht te krijgen in het statusmodel en aangepaste statusrapporten toe te voegen en aangepaste prestatiemeteritems toe te voegen om een realtime inzicht te krijgen in de impact van uw services en toepassingen op het cluster.

Als u wilt profiteren van deze logboeken, wordt het ten zeerste aanbevolen om 'Diagnostische gegevens' ingeschakeld te laten tijdens het maken van het cluster in Azure Portal. Door diagnostische gegevens in te schakelen, kan Windows Azure Diagnostics, wanneer het cluster wordt geïmplementeerd, de kanalen Operational, Reliable Services en Reliable Actors erkennen en de gegevens opslaan, zoals verder wordt uitgelegd in statistische gebeurtenissen met Azure Diagnostics.

Azure Service Fabric-status- en belastingrapportage

Service Fabric heeft een eigen statusmodel, dat uitgebreid wordt beschreven in deze artikelen:

Statuscontrole is essentieel voor meerdere aspecten van het uitvoeren van een service, met name tijdens een upgrade van een toepassing. Nadat elk upgradedomein van de service is bijgewerkt, moet het upgradedomein statuscontroles doorgeven voordat de implementatie naar het volgende upgradedomein wordt verplaatst. Als de status ok niet kan worden bereikt, wordt de implementatie teruggedraaid, zodat de toepassing de status OK heeft. Hoewel sommige klanten mogelijk worden beïnvloed voordat de services worden teruggedraaid, ondervinden de meeste klanten geen probleem. Ook treedt een oplossing relatief snel op zonder te hoeven wachten op actie van een menselijke operator. Hoe meer statuscontroles zijn opgenomen in uw code, hoe toleranter uw service is bij implementatieproblemen.

Een ander aspect van de servicestatus is het rapporteren van metrische gegevens van de service. Metrische gegevens zijn belangrijk in Service Fabric omdat ze worden gebruikt om het resourcegebruik te verdelen. Metrische gegevens kunnen ook een indicator van de systeemstatus zijn. U hebt bijvoorbeeld een toepassing met veel services en elk exemplaar rapporteert een metrische waarde voor aanvragen per seconde (RPS). Als één service meer resources gebruikt dan een andere service, verplaatst Service Fabric service-exemplaren rond het cluster om zelfs het resourcegebruik te behouden. Zie Resourceverbruik beheren en laden in Service Fabric met metrische gegevens voor een gedetailleerdere uitleg over de werking van resourcegebruik.

Metrische gegevens kunnen u ook inzicht geven in de prestaties van uw service. In de loop van de tijd kunt u metrische gegevens gebruiken om te controleren of de service binnen de verwachte parameters werkt. Als bijvoorbeeld trends laten zien dat op maandagochtend om 9 uur het gemiddelde RPS 1000 is, kunt u een statusrapport instellen dat u waarschuwt als de RPS lager is dan 500 of hoger dan 1.500. Alles kan perfect zijn, maar het is misschien een kijkje waard om ervoor te zorgen dat uw klanten een geweldige ervaring hebben. Uw service kan een set metrische gegevens definiëren die kunnen worden gerapporteerd voor statuscontroledoeleinden, maar die geen invloed hebben op de resourceverdeling van het cluster. Hiervoor stelt u het metrische gewicht in op nul. We raden u aan om alle metrische gegevens te starten met een gewicht van nul en niet het gewicht te verhogen totdat u zeker weet hoe gewicht van de metrische gegevens van invloed is op resourceverdeling voor uw cluster.

Tip

Gebruik niet te veel gewogen metrische gegevens. Het kan lastig zijn om te begrijpen waarom service-exemplaren worden verplaatst voor taakverdeling. Een paar metrische gegevens kunnen een lange weg gaan!

Alle informatie die de status en prestaties van uw toepassing kan aangeven, is een kandidaat voor metrische gegevens en statusrapporten. Met een PRESTATIEmeteritem voor CPU kunt u zien hoe uw knooppunt wordt gebruikt, maar wordt u niet verteld of een bepaalde service in orde is, omdat meerdere services mogelijk op één knooppunt worden uitgevoerd. Maar metrische gegevens, zoals RPS, verwerkte items en latentie van aanvragen, kunnen allemaal de status van een specifieke service aangeven.

Service Fabric-ondersteuningslogboeken

Als u contact moet opnemen met Microsoft Ondersteuning voor hulp bij uw Azure Service Fabric-cluster, zijn ondersteuningslogboeken vrijwel altijd vereist. Als uw cluster wordt gehost in Azure, worden ondersteuningslogboeken automatisch geconfigureerd en verzameld als onderdeel van het maken van een cluster. De logboeken worden opgeslagen in een toegewezen opslagaccount in de resourcegroep van uw cluster. Het opslagaccount heeft geen vaste naam, maar in het account ziet u blobcontainers en tabellen met namen die beginnen met fabric. Zie Een zelfstandig Azure Service Fabric-cluster en configuratie-instellingen voor een zelfstandig Windows-cluster maken en beheren voor informatie over het instellen van logboekverzamelingen voor een zelfstandig Cluster. Voor zelfstandige Service Fabric-exemplaren moeten de logboeken worden verzonden naar een lokale bestandsshare. U moet deze logboeken hebben voor ondersteuning, maar ze zijn niet bedoeld om te kunnen worden gebruikt door iemand buiten het microsoft-klantondersteuningsteam.

Prestaties meten

Meting van de prestaties van uw cluster helpt u inzicht te krijgen in hoe het belasting kan verwerken en beslissingen kan nemen over het schalen van uw cluster (zie meer over het schalen van een cluster in Azure of on-premises). Prestatiegegevens zijn ook handig in vergelijking met acties die u of uw toepassingen en services mogelijk hebben uitgevoerd, bij het analyseren van logboeken in de toekomst.

Zie Prestatiemeteritems in Service Fabric voor een lijst met prestatiemeteritems die moeten worden verzameld bij het gebruik van Service Fabric

Hier volgen twee veelvoorkomende manieren waarop u prestatiegegevens voor uw cluster kunt instellen:

  • Een agent gebruiken
    Dit is de voorkeurswijze voor het verzamelen van prestaties van een computer, omdat agents meestal een lijst hebben met mogelijke prestatiegegevens die kunnen worden verzameld en het is een relatief eenvoudig proces om de metrische gegevens te kiezen die u wilt verzamelen of wijzigen. Lees meer over de Azure Monitor die Azure Monitor-logboeken biedt in de integratie van Azure Monitor-logboeken van Service Fabric en het instellen van de Log Analytics-agent voor meer informatie over de Log Analytics-agent. Dit is een dergelijke bewakingsagent die prestatiegegevens voor cluster-VM's en geïmplementeerde containers kan ophalen.

  • Prestatiemeteritems voor Azure Table Storage
    U kunt ook metrische prestatiegegevens verzenden naar dezelfde tabelopslag als de gebeurtenissen. Hiervoor moet u de configuratie van Azure Diagnostics wijzigen om de juiste prestatiemeteritems van de VM's in uw cluster op te halen en dockerstatistieken op te halen als u containers gaat implementeren. Lees meer over het configureren van prestatiemeteritems in WAD in Service Fabric om prestatiemeteritems in te stellen.

Volgende stappen