Hand leiding voor Cloud monitoring: de juiste gegevens verzamelenCloud monitoring guide: Collect the right data

In dit artikel worden enkele overwegingen beschreven voor het verzamelen van bewakings gegevens in een Cloud toepassing.This article describes some considerations for collecting monitoring data in a cloud application.

Als u de status en beschik baarheid van uw Cloud oplossing wilt observeren, moet u de controle hulpprogramma's configureren om een niveau aan signalen te verzamelen dat is gebaseerd op voorspel bare fout statussen.To observe the health and availability of your cloud solution, you must configure the monitoring tools to collect a level of signals that are based on predictable failure states. Deze signalen zijn de symptomen van de fout, niet de oorzaak.These signals are the symptoms of the failure, not the cause. De controle hulpprogramma's gebruiken metrische gegevens en, voor geavanceerde diagnose en analyse van hoofd oorzaken, Logboeken.The monitoring tools use metrics and, for advanced diagnostics and root cause analysis, logs.

Plan voor controle en migratie zorgvuldig.Plan for monitoring and migration carefully. Begin met het opnemen van de eigenaar van de bewakings service, de Manager van de bewerkingen en andere gerelateerde mede werkers tijdens de planning en blijf deze in de ontwikkelings-en release fase.Start by including the monitoring service owner, the manager of operations, and other related personnel during the planning phase, and continue engaging them throughout the development and release cycle. De focus is het ontwikkelen van een bewakings configuratie die is gebaseerd op de volgende criteria:Their focus will be to develop a monitoring configuration that's based on the following criteria:

  • Wat is de samen stelling van de service?What is the composition of the service? Worden deze afhankelijkheden vandaag gecontroleerd?Are those dependencies monitored today? Als dat het geval is, zijn er dan meerdere hulpprogram ma's betrokken?If so, are there multiple tools involved? Is er een kans om de consolidatie uit te voeren, zonder dat er Risico's worden ge├»ntroduceerd?Is there an opportunity to consolidate, without introducing risks?
  • Wat is de SLA van de service en hoe meten en rapporteren?What is the SLA of the service, and how will I measure and report it?
  • Hoe moet het service dashboard eruitzien wanneer een incident wordt gegenereerd?What should the service dashboard look like when an incident is raised? Hoe moet het dash board eruitzien voor de eigenaar van de service en voor het team dat de service ondersteunt?What should the dashboard look like for the service owner, and for the team that supports the service?
  • Welke metrische gegevens levert de resource die ik moet bewaken?What metrics does the resource produce that I need to monitor?
  • Hoe zullen de eigenaar van de service, ondersteunings teams en andere mede werkers zoeken in de logboeken?How will the service owner, support teams, and other personnel be searching the logs?

Hoe u deze vragen beantwoordt en de criteria voor waarschuwingen, bepaalt hoe u het bewakings platform gaat gebruiken.How you answer those questions, and the criteria for alerting, determines how you'll use the monitoring platform. Als u migreert van een bestaande bewakings platform of set controle hulpprogramma's, gebruikt u de migratie als een kans om de door u verzamelde signalen opnieuw te evalueren.If you're migrating from an existing monitoring platform or set of monitoring tools, use the migration as an opportunity to reevaluate the signals you collect. Dit is in het bijzonder waar u rekening mee moet houden wanneer u migreert of integreert met een bewakings platform op basis van de Cloud, zoals Azure Monitor.This is especially true now that there are several cost factors to consider when you migrate or integrate with a cloud-based monitoring platform like Azure Monitor. Houd er rekening mee dat bewakings gegevens moeten kunnen worden uitgevoerd.Remember, monitoring data needs to be actionable. U moet geoptimaliseerde gegevens hebben verzameld om 10.000 u de algemene status van de service te geven.You need to have optimized data collected to give you "a 10,000 foot view" of the overall health of the service. De instrumentatie die is gedefinieerd om echte incidenten te identificeren, moet zo eenvoudig, voorspelbaar en betrouwbaar zijn.The instrumentation that's defined to identify real incidents should be as simple, predictable, and reliable as possible.

Een bewakings configuratie ontwikkelenDevelop a monitoring configuration

De eigenaar en het team van de monitoring service volgen doorgaans een gemeen schappelijke set activiteiten om een bewakings configuratie te ontwikkelen.The monitoring service owner and team typically follow a common set of activities to develop a monitoring configuration. Deze activiteiten beginnen bij de eerste plannings fases, door gaan met testen en valideren in een niet-productspecifieke omgeving, en worden uitgebreid naar productie.These activities start at the initial planning stages, continue through testing and validating in a nonproduction environment, and extend to deploying into production. Bewakings configuraties zijn afgeleid van bekende fout modi, test resultaten van gesimuleerde fouten en de ervaring van verschillende personen in de organisatie (de Service Desk, Operations, ingenieurs en ontwikkel aars).Monitoring configurations are derived from known failure modes, test results of simulated failures, and the experience of several people in the organization (the service desk, operations, engineers, and developers). Deze configuraties gaan ervan uit dat de service al bestaat, wordt gemigreerd naar de Cloud en niet opnieuw is gearchitectd.Such configurations assume that the service already exists, it's being migrated to the cloud, and it hasn't been rearchitected.

Bewaak de status en beschik baarheid van deze services vroegtijdig in het ontwikkelings proces voor kwaliteits resultaten op service niveau.For service-level quality results, monitor the health and availability of these services early in the development process. Als u het ontwerp van deze service of toepassing bewaken als een behandeld, zijn uw resultaten niet zo goed.If you monitor the design of that service or application as an afterthought, your results won't be as successful.

Als u een snellere oplossing van het incident wilt door nemen, moet u rekening houden met de volgende aanbevelingen:To drive quicker resolution of the incident, consider the following recommendations:

  • Definieer een dash board voor elk service onderdeel.Define a dashboard for each service component.
  • Gebruik metrische gegevens om verdere diagnose te begeleiden en om een oplossing of tijdelijke oplossing van het probleem te identificeren als een hoofd oorzaak niet kan worden gedetecteerd.Use metrics to help guide further diagnosis and to identify a resolution or workaround of the issue if a root cause can't be uncovered.
  • Gebruik inzoom mogelijkheden in het dash board of ondersteuning voor het aanpassen van de weer gave om deze te verfijnen.Use dashboard drill-down capabilities, or support customizing the view to refine it.
  • Als u uitgebreide logboeken nodig hebt, moeten meet gegevens het doel van de zoek criteria hebben geholpen.If you need verbose logs, metrics should have helped target the search criteria. Als de metrische gegevens niet zijn geholpen, kunt u ze verbeteren voor het volgende incident.If the metrics didn't help, improve them for the next incident.

Het gebruik van deze richt lijnen voor het instellen van de guid's kan u helpen om uw eigen real-time inzichten te bieden, evenals een beter beheer van uw service.Embracing this guiding set of principles can help give you near-real-time insights, as well as better management of your service.

Volgende stappenNext steps