Metod tips för övervakning av moln programBest practices for monitoring cloud applications

Distribuerade program och tjänster som körs i molnet är till sin natur komplexa delar av programvara som utgör många rörliga delar.Distributed applications and services running in the cloud are, by their nature, complex pieces of software that comprise many moving parts. I en produktions miljö är det viktigt att kunna spåra hur användarna använder systemet, spåra resursutnyttjande och i allmänhet övervaka systemets hälso tillstånd och prestanda.In a production environment, it's important to be able to track the way in which users use your system, trace resource utilization, and generally monitor the health and performance of your system. Du kan använda den här informationen som diagnostiskt stöd och identifiera och åtgärda problem, och för att upptäcka potentiella problem och förebygga att de uppstår.You can use this information as a diagnostic aid to detect and correct issues, and also to help spot potential problems and prevent them from occurring.

Scenarier för övervakning och diagnostikMonitoring and diagnostics scenarios

Du kan använda övervakning för att få en överblick över hur bra ett system fungerar.You can use monitoring to gain an insight into how well a system is functioning. Övervakning är en viktig del av att upprätthålla tjänstens målsättning för kvalitet.Monitoring is a crucial part of maintaining quality-of-service targets. Vanliga scenarier för att samla in övervakningsdata är:Common scenarios for collecting monitoring data include:

  • Se till att systemet förblir felfritt.Ensuring that the system remains healthy.
  • Spåra tillgänglighet för systemet och dess komponentelementet.Tracking the availability of the system and its component elements.
  • Underhålla prestanda för att säkerställa att systemets dataflöde inte försämras oväntat medan arbetsvolymen ökar.Maintaining performance to ensure that the throughput of the system does not degrade unexpectedly as the volume of work increases.
  • Garantera att systemet uppfyller alla servicenivåavtal (SLA:er) som har upprättats med kunderna.Guaranteeing that the system meets any service-level agreements (SLAs) established with customers.
  • Skydda systemets och användarnas sekretess och säkerhet samt deras data.Protecting the privacy and security of the system, users, and their data.
  • Spåra åtgärder som utförs för gransknings- och föreskriftssyften.Tracking the operations that are performed for auditing or regulatory purposes.
  • Övervaka daglig användning av systemet och upptäcka trender som kan leda till problem om de inte åtgärdas.Monitoring the day-to-day usage of the system and spotting trends that might lead to problems if they're not addressed.
  • Spåra problem som uppstår, från en första rapport via analyser av möjliga orsaker, korrigering, efterföljande programuppdateringar och distribution.Tracking issues that occur, from initial report through to analysis of possible causes, rectification, consequent software updates, and deployment.
  • Spåra åtgärder och felsöka programversioner.Tracing operations and debugging software releases.

Anteckning

Den här listan är inte avsedd att vara omfattande.This list is not intended to be comprehensive. Det här dokumentet fokuserar på scenarier som är de vanligaste situationerna för övervakning.This document focuses on these scenarios as the most common situations for performing monitoring. Det kan finnas andra som är mindre vanliga eller som är specifika för din miljö.There might be others that are less common or are specific to your environment.

I följande avsnitt beskrivs dessa scenarier mer utförligt.The following sections describe these scenarios in more detail. Information för varje scenario tas upp i följande format:The information for each scenario is discussed in the following format:

  1. En kort översikt över scenariot.A brief overview of the scenario.
  2. De typiska kraven för det här scenariot.The typical requirements of this scenario.
  3. Rå Instrumentation-data som krävs för att stödja scenariot och möjliga källor av den här informationen.The raw instrumentation data that's required to support the scenario, and possible sources of this information.
  4. Hur dessa rå data kan analyseras och kombineras för att generera meningsfull diagnostikinformation.How this raw data can be analyzed and combined to generate meaningful diagnostic information.

HälsoövervakningHealth monitoring

Ett system är felfritt om det körs och kan genomföra begäranden.A system is healthy if it is running and capable of processing requests. Syftet med hälsoövervakning är att skapa en ögonblicksbild av systemets aktuella status, så att du kan kontrollera att systemets alla komponenter fungerar som de ska.The purpose of health monitoring is to generate a snapshot of the current health of the system so that you can verify that all components of the system are functioning as expected.

Krav för hälsoövervakningRequirements for health monitoring

En operatör ska snabbt meddelas (inom några sekunder) om någon del av systemet bedöms vara felaktig.An operator should be alerted quickly (within a matter of seconds) if any part of the system is deemed to be unhealthy. Operatören ska kunna kontrollera vilka av systemets delar som fungerar normalt och vilka delar som har problem.The operator should be able to ascertain which parts of the system are functioning normally, and which parts are experiencing problems. Systemets hälsostatus kan framhävas med ett trafikljussystem:System health can be highlighted through a traffic-light system:

  • Rött betyder ohälsosamt (systemet har stoppats)Red for unhealthy (the system has stopped)
  • Gult betyder delvis felfritt (systemet körs med begränsad funktionalitet)Yellow for partially healthy (the system is running with reduced functionality)
  • Grönt betyder helt felfrittGreen for completely healthy

Med en omfattande hälsoövervakning av systemet kan en operatör granska hela systemet nedåt och visa hälsostatus för delsystem och komponenter.A comprehensive health-monitoring system enables an operator to drill down through the system to view the health status of subsystems and components. Om systemets övergripande hälsostatus till exempel beskrivs som delvis felfritt ska operatören kunna zooma in och avgöra vilka funktioner som inte är tillgängliga.For example, if the overall system is depicted as partially healthy, the operator should be able to zoom in and determine which functionality is currently unavailable.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

De rådata som krävs som stöd för hälsoövervakning kan genereras till följd av:The raw data that's required to support health monitoring can be generated as a result of:

  • Spårning av användarbegäran.Tracing execution of user requests. Den här informationen kan användas för att avgöra vilka begäranden som lyckats, misslyckats och hur lång tid varje begärande tar.This information can be used to determine which requests have succeeded, which have failed, and how long each request takes.
  • Syntetisk användarövervakning.Synthetic user monitoring. Den här processen simulerar stegen som utförs av en användare och följer en fördefinierad rad steg.This process simulates the steps performed by a user and follows a predefined series of steps. Resultatet för varje steg ska hämtas.The results of each step should be captured.
  • Undantag för loggning, fel och aviseringar.Logging exceptions, faults, and warnings. Den här informationen kan hämtas tack vare spårningsinstruktioner som bäddats in i programkoden, samt hämta information från händelseloggarna för alla tjänster som refererar till systemet.This information can be captured as a result of trace statements embedded into the application code, as well as retrieving information from the event logs of any services that the system references.
  • Hälsoövervakning av tredjepartstjänster som systemet använder.Monitoring the health of any third-party services that the system uses. Den här övervakningen kan behöva hämta och parsa data för hälsotillstånd som tjänsterna tillhandahåller.This monitoring might require retrieving and parsing health data that these services supply. Den här informationen kan ha en mängd olika format.This information might take a variety of formats.
  • Slutpunktsövervakning.Endpoint monitoring. Den här mekanismen beskrivs mer utförligt i avsnittet ”Tillgänglighetsövervakning”.This mechanism is described in more detail in the "Availability monitoring" section.
  • Insamling av omgivande prestandainformation, som processoranvändning i bakgrunden eller aktivitet för I/O (inklusive nätverket).Collecting ambient performance information, such as background CPU utilization or I/O (including network) activity.

Analysera hälsodataAnalyzing health data

Hälsoövervakningens huvudsakliga fokus är att snabbt ange huruvida systemet körs.The primary focus of health monitoring is to quickly indicate whether the system is running. Heta analyser av omedelbara data kan utlösa en avisering om fel upptäcks i viktiga komponenter.Hot analysis of the immediate data can trigger an alert if a critical component is detected as unhealthy. (Du kan till exempel inte svara på en serie ping-signaler i följd.) Operatören kan sedan vidta lämplig korrigerings åtgärd.(It fails to respond to a consecutive series of pings, for example.) The operator can then take the appropriate corrective action.

Ett mer avancerat system kan innehålla förutsägande element som utför kalla analyser framför senaste och aktuella arbetsbelastningar.A more advanced system might include a predictive element that performs a cold analysis over recent and current workloads. En kall analys kan upptäcka trender och avgöra huruvida systemet sannolikt är felfritt eller om det behöver ytterligare resurser.A cold analysis can spot trends and determine whether the system is likely to remain healthy or whether the system will need additional resources. Det här förutsägande elementet ska baseras på kritiska prestandamått, som:This predictive element should be based on critical performance metrics, such as:

  • Antalet begäranden som är riktade mot varje tjänst eller undersystem.The rate of requests directed at each service or subsystem.
  • Svarstider för de här begärandena.The response times of these requests.
  • Mängden data som flödar till och från varje tjänst.The volume of data flowing into and out of each service.

Om värdet för alla mått överskrider ett angivet tröskelvärde kan systemet utlösa en avisering som ger en operatör eller automatisk skalning (om tillgängligt) möjligheten att vidta förebyggande åtgärder som behövs för att upprätthålla systemhälsan.If the value of any metric exceeds a defined threshold, the system can raise an alert to enable an operator or autoscaling (if available) to take the preventative actions necessary to maintain system health. De här åtgärderna kan handla om att lägga till resurser, starta om en eller flera tjänster som misslyckats eller tillämpa begränsning på begäranden med lägre prioritet.These actions might involve adding resources, restarting one or more services that are failing, or applying throttling to lower-priority requests.

TillgänglighetsövervakningAvailability monitoring

Ett helt felfritt system kräver att komponenterna och delsystemen som utgör systemet är tillgängliga.A truly healthy system requires that the components and subsystems that compose the system are available. Tillgänglighetsövervakning är nära förknippat med hälsoövervakning.Availability monitoring is closely related to health monitoring. Medan hälsoövervakning ger en omedelbar insikt i systemets aktuella hälsotillstånd handlar tillgänglighetsövervakning om att spåra systemets tillgänglighet och dess komponenter, för att generera statistik om drifttid för systemet.But whereas health monitoring provides an immediate view of the current health of the system, availability monitoring is concerned with tracking the availability of the system and its components to generate statistics about the uptime of the system.

I många system är vissa komponenter (till exempel en databas) konfigurerade med inbyggd redundans för att möjliggöra snabb växling vid ett allvarligt fel eller anslutningsproblem.In many systems, some components (such as a database) are configured with built-in redundancy to permit rapid failover in the event of a serious fault or loss of connectivity. I den bästa av världar är användaren inte medveten om att ett sådant fel inträffat.Ideally, users should not be aware that such a failure has occurred. Från ett tillgänglighetsövervakningsperspektiv är det dock nödvändigt att samla in så mycket information som möjligt om de här felen, för att ta reda på orsaken och vidta åtgärder så att de inte uppstår igen.But from an availability monitoring perspective, it's necessary to gather as much information as possible about such failures to determine the cause and take corrective actions to prevent them from recurring.

De data som krävs för att spåra tillgänglighet kan vara beroende av ett antal faktorer med lägre nivå.The data that's required to track availability might depend on a number of lower-level factors. Många av faktorerna kan vara specifika för programmet, systemet och miljön.Many of these factors might be specific to the application, system, and environment. Ett effektivt övervakningssystem samlar in tillgänglighetsdata som motsvarar faktorerna med låg nivå och aggregera dem för att ge en övergripande bild av systemet.An effective monitoring system captures the availability data that corresponds to these low-level factors and then aggregates them to give an overall picture of the system. I exempelvis ett e-handelssystem kan verksamhetsfunktionerna som gör det möjligt för en kund att göra en beställning bero på databasen där beställningsinformationen lagras och betalningssystemet som hanterar de monetära transaktionerna när beställningarna betalas.For example, in an e-commerce system, the business functionality that enables a customer to place orders might depend on the repository where order details are stored and the payment system that handles the monetary transactions for paying for these orders. Tillgängligheten för systemets beställningsdel är därför en tillgänglighetsfunktion för databasen och undersystemet för betalning.The availability of the order-placement part of the system is therefore a function of the availability of the repository and the payment subsystem.

Krav för tillgänglighetsövervakningRequirements for availability monitoring

En operatör bör även kunna visa historisk tillgänglighet för varje system och undersystem och använda informationen för att upptäcka eventuella trender som kan orsaka att ett eller flera delsystem misslyckas regelbundet.An operator should also be able to view the historical availability of each system and subsystem, and use this information to spot any trends that might cause one or more subsystems to periodically fail. (Misslyckas tjänster vid vissa tillfällen på dagen som motsvarar en bearbetningshöjdpunkt?)(Do services start to fail at a particular time of day that corresponds to peak processing hours?)

En övervakningslösning bör ge en omedelbar och historisk översikt över varje undersystems tillgänglighet eller otillgänglighet.A monitoring solution should provide an immediate and historical view of the availability or unavailability of each subsystem. Den bör också snabbt kunna meddela en operatör när en eller flera tjänster misslyckas eller när användare inte kan ansluta till tjänster.It should also be capable of quickly alerting an operator when one or more services fail or when users can't connect to services. Det här handlar inte bara om övervakning av varje tjänst, utan också om att undersöka vilka åtgärder som varje användare utför, om dessa åtgärder misslyckas när de försöker kommunicera med en tjänst.This is a matter of not only monitoring each service, but also examining the actions that each user performs if these actions fail when they attempt to communicate with a service. Anslutningsfel i viss omfattning är normalt och kan bero på övergående fel.To some extent, a degree of connectivity failure is normal and might be due to transient errors. Det kan dock vara praktiskt om systemet kan generera ett meddelande för antalet anslutningsfel till ett särskilt delsystem som uppstår under en viss period.But it might be useful to allow the system to raise an alert for the number of connectivity failures to a specified subsystem that occur during a specific period.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

Precis som med hälsoövervakning kan de rådata som krävs som stöd för tillgänglighetsövervakning genereras som ett resultat av syntetisk användarövervakning eller loggning av undantag, fel och aviseringar som kan uppstå.As with health monitoring, the raw data that's required to support availability monitoring can be generated as a result of synthetic user monitoring and logging any exceptions, faults, and warnings that might occur. Dessutom kan tillgänglighetsdata hämtas från slutpunktsövervakningen.In addition, availability data can be obtained from performing endpoint monitoring. Programmet kan exponera en eller flera hälsa slutpunkter, som testar åtkomst till ett funktionsområde i systemet.The application can expose one or more health endpoints, each testing access to a functional area within the system. Övervakningssystemet kan pinga varje slutpunkt genom att följa ett definierat schema och samla in resultatet (lyckat eller misslyckat).The monitoring system can ping each endpoint by following a defined schedule and collect the results (success or fail).

Alla tidsgränser, nätverksanslutningsfel och anslutningsförsök måste registreras.All timeouts, network connectivity failures, and connection retry attempts must be recorded. Alla data ska vara tidsstämplade.All data should be timestamped.

Analysera tillgänglighetsdataAnalyzing availability data

Instrumentationsdata måste aggregeras och korrelera för att ge stöd för följande typer av analys:The instrumentation data must be aggregated and correlated to support the following types of analysis:

  • Omedelbar tillgänglighet för system och undersystem.The immediate availability of the system and subsystems.
  • Felfrekvens för tillgänglighet i systemet och undersystemen.The availability failure rates of the system and subsystems. I den bästa av världar ska en operatör kunna korrelera felen med särskilda åtgärder: vad pågick när systemet misslyckades?Ideally, an operator should be able to correlate failures with specific activities: what was happening when the system failed?
  • En historisk vy över felfrekvenser för systemet eller undersystem vid särskilda tidsperioder och belastningen på systemet (antalet användarbegäranden) när ett fel inträffat.A historical view of failure rates of the system or any subsystems across any specified period, and the load on the system (number of user requests, for example) when a failure occurred.
  • Orsaker till att systemet eller undersystem är otillgängliga.The reasons for unavailability of the system or any subsystems. Anledningarna kan exempelvis vara att en tjänst inte körs, att anslutningen kopplades ifrån, att nätverket är anslutet men har ett avbrott eller att det är anslutet med har återkommande problem.For example, the reasons might be service not running, connectivity lost, connected but timing out, and connected but returning errors.

Du kan beräkna procentandelen för en tjänsts tillgänglighet under en viss tidsperiod med hjälp av följande formel:You can calculate the percentage availability of a service over a period of time by using the following formula:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Det här är användbart för SLA-syften.This is useful for SLA purposes. (SLA-övervakning beskrivs mer detaljerat längre fram i den här vägledningen.) Definitionen av avbrotts tiden beror på tjänsten.(SLA monitoring is described in more detail later in this guidance.) The definition of downtime depends on the service. Exempelvis definierar Build-tjänsten i Visual Studio Team Service driftstopp som den tid (totalt antal minuter sammanlagt) som Build-tjänsten varit otillgänglig.For example, Visual Studio Team Services Build Service defines downtime as the period (total accumulated minutes) during which Build Service is unavailable. En minut anses vara otillgänglig om alla kundinitierade kontinuerliga HTTP-åtgärdsbegäranden till Build-tjänsten under hela minuten antingen resulterar i en felkod eller inte returnerar något svar.A minute is considered unavailable if all continuous HTTP requests to Build Service to perform customer-initiated operations throughout the minute either result in an error code or do not return a response.

PrestandaövervakningPerformance monitoring

Om systemet utsätts för mer och mer stress (genom ökat antal användare) ökar storleken på datauppsättningarna som användarna har åtkomst till och risken att det uppstår problem med en eller flera komponenter ökar.As the system is placed under more and more stress (by increasing the volume of users), the size of the datasets that these users access grows and the possibility of failure of one or more components becomes more likely. Ofta föregås komponentfel av prestandaförsämring.Frequently, component failure is preceded by a decrease in performance. Om du upplever en minskning kan du vidta förebyggande åtgärder för att avhjälpa situationen.If you're able detect such a decrease, you can take proactive steps to remedy the situation.

Systemets prestanda beror på ett antal faktorer.System performance depends on a number of factors. Varje faktor mäts vanligtvis via nyckelindikatorer (KPI:er), som antalet databastransaktioner per sekund eller antalet nätverksbegäranden som hanteras inom en viss tidsram.Each factor is typically measured through key performance indicators (KPIs), such as the number of database transactions per second or the volume of network requests that are successfully serviced in a specified time frame. Vissa av dessa KPI:er kan finnas som specifika prestandamått, medan andra kan härledas från en kombination av mått.Some of these KPIs might be available as specific performance measures, whereas others might be derived from a combination of metrics.

Anteckning

För att kunna avgöra om prestandan är bra eller dålig krävs förståelse för den prestandanivå som systemet bör kunna köra på.Determining poor or good performance requires that you understand the level of performance at which the system should be capable of running. Detta kräver att system övervakas medan det körs under normal belastning och att data hämtas för alla KPI:er under en tidsperiod.This requires observing the system while it's functioning under a typical load and capturing the data for each KPI over a period of time. Det här kan innefatta att systemet körs under simulerad belastning i en testmiljö och att lämpliga data samlas in innan systemet driftsätts i en produktionsmiljö.This might involve running the system under a simulated load in a test environment and gathering the appropriate data before deploying the system to a production environment.

Du bör också säkerställa att prestandaövervakningen inte överbelastar systemet.You should also ensure that monitoring for performance purposes does not become a burden on the system. Du kan eventuellt justera detaljnivån för de data som prestandaövervakningen samlar in dynamiskt.You might be able to dynamically adjust the level of detail for the data that the performance monitoring process gathers.

Krav för prestandaövervakningRequirements for performance monitoring

För kontroll av systemets prestanda behöver operatören vanligtvis information om:To examine system performance, an operator typically needs to see information that includes:

  • Svarsfrekvenser för användarbegäranden.The response rates for user requests.
  • Antal samtida användarbegäranden.The number of concurrent user requests.
  • Nätverkstrafikens volym.The volume of network traffic.
  • Frekvens för företagstransaktioner som håller på att slutföras.The rates at which business transactions are being completed.
  • Genomsnittlig bearbetningstid för begäranden.The average processing time for requests.

Det kan också vara bra att tillhandahålla verktyg som ger operatören möjligheten att upptäcka korrelationer som:It can also be helpful to provide tools that enable an operator to help spot correlations, such as:

  • Antal samtida användare jämfört med svarstid för begäranden (den tid det tar att starta bearbetning för ett begärande när användaren har skickat det).The number of concurrent users versus request latency times (how long it takes to start processing a request after the user has sent it).
  • Antal samtida användare jämfört med genomsnittlig svarstid (den tid det tar för att slutföra ett begärande när bearbetning startat).The number of concurrent users versus the average response time (how long it takes to complete a request after it has started processing).
  • Antal begäranden jämfört med antal bearbetningsfel.The volume of requests versus the number of processing errors.

Tillsammans med den här funktionella informationen på hög nivå ska en operatör kunna få en detaljerad vy av varje komponents prestanda i systemet.Along with this high-level functional information, an operator should be able to obtain a detailed view of the performance for each component in the system. Dessa data är vanligtvis försedda via prestandaräknare på låg nivå som spårar information som:This data is typically provided through low-level performance counters that track information such as:

  • Minnesanvändning.Memory utilization.
  • Antal trådar.Number of threads.
  • Bearbetningstid för CPU.CPU processing time.
  • Kölängd för begärande.Request queue length.
  • Avgifter för disk eller I/O-nätverk och fel.Disk or network I/O rates and errors.
  • Antal skrivna eller lästa byte.Number of bytes written or read.
  • Indikatorer för mellanprogram, exempelvis kölängd.Middleware indicators, such as queue length.

Alla visualiseringar ska tillåta en operatör att ange en tidsperiod.All visualizations should allow an operator to specify a time period. Data som visas kan vara en ögonblicksbild av den aktuella situationen och/eller en historisk vy över prestandan.The displayed data might be a snapshot of the current situation and/or a historical view of the performance.

En operatör ska kunna generera en avisering baserad på ett prestandamått för alla angivna värden under en angiven tidsperiod.An operator should be able to raise an alert based on any performance measure for any specified value during any specified time interval.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

Du kan samla in prestandadata på hög nivå (dataflöde, antal samtida användare, antal företagstransaktioner, felfrekvens och så vidare) genom att övervaka förloppet för användarnas begäranden när de tas emot och passerar genom systemet.You can gather high-level performance data (throughput, number of concurrent users, number of business transactions, error rates, and so on) by monitoring the progress of users' requests as they arrive and pass through the system. Det här innefattar införlivandet av spårningsrapporter vid nyckelpunkter i programkoden, tillsammans med tidsinformation.This involves incorporating tracing statements at key points in the application code, together with timing information. Alla fel, undantag och aviseringar ska samlas in med tillräckliga data för korrelation mellan dem och de begäranden som orsakade dem.All faults, exceptions, and warnings should be captured with sufficient data for correlating them with the requests that caused them. Internet Information Services-loggen (IIS) är en annan användbar källa.The Internet Information Services (IIS) log is another useful source.

Om möjligt ska du hämta prestandadata för alla externa system som används i programmet.If possible, you should also capture performance data for any external systems that the application uses. De här externa systemen kan ange sina egna prestandaräknare eller andra funktioner för att begära prestandadata.These external systems might provide their own performance counters or other features for requesting performance data. Om detta inte är möjligt registrerar du information som start- och sluttid för när varje begärande gjordes till ett externt system, tillsammans med status (slutfört, misslyckat eller varning) för åtgärden.If this is not possible, record information such as the start time and end time of each request made to an external system, together with the status (success, fail, or warning) of the operation. Du kan till exempel använda ett stoppur för att ta tid på begäranden: starta tidtagningen när ett begärande startar och stoppa sedan tidtagningen när begärandet avslutas.For example, you can use a stopwatch approach to time requests: start a timer when the request starts and then stop the timer when the request finishes.

Prestandadata på låg nivå för enskilda komponenter i ett system kan finnas tillgängliga genom funktioner och tjänster, som Windows prestandaräknare eller Azure Diagnostics.Low-level performance data for individual components in a system might be available through features and services such as Windows performance counters and Azure Diagnostics.

Analysera prestandadataAnalyzing performance data

Stor del av analysarbetet består av att sammanställa prestandadata efter användarbegärandetyper och/eller undersystem eller tjänster som vardera begärande skickas till.Much of the analysis work consists of aggregating performance data by user request type and/or the subsystem or service to which each request is sent. Exempel på användarbegäranden är när en artikel läggs till i en kundvagn eller när ett begärande om att gå till kassan görs i ett e-handelssystem.An example of a user request is adding an item to a shopping cart or performing the checkout process in an e-commerce system.

Ett annat vanligt krav är att prestandadata sammanfattas i valda percentiler.Another common requirement is summarizing performance data in selected percentiles. En operatör kan exempelvis avgöra svarstiden för 99 procent av begäranden, 95 procent av begäranden och 70 procent av begäranden.For example, an operator might determine the response times for 99 percent of requests, 95 percent of requests, and 70 percent of requests. Det kan finnas SLA-mål eller andra mål för vardera percentil.There might be SLA targets or other goals set for each percentile. Pågående resultat ska rapporteras i nära realtid för att bidra till att upptäcka omedelbara problem.The ongoing results should be reported in near real time to help detect immediate issues. Resultatet bör av statistiska skäl också aggregeras under längre tid.The results should also be aggregated over the longer time for statistical purposes.

Vid problem med fördröjningar som påverkar prestandan ska en operatör snabbt kunna identifiera anledningen till att flaskhalsen uppstår genom att utreda fördröjningen i varje steg som ett begärande utför.In the case of latency issues affecting performance, an operator should be able to quickly identify the cause of the bottleneck by examining the latency of each step that each request performs. Prestandadata måste därför tillhandahålla ett sätt för att korrelera prestandamått för vardera steg, för att förknippa dem till en specifik begäran.The performance data must therefore provide a means of correlating performance measures for each step to tie them to a specific request.

Beroende på visualiseringskraven kan det vara användbart att generera och lagra en datakub som innehåller vyer över rådata.Depending on the visualization requirements, it might be useful to generate and store a data cube that contains views of the raw data. Den här datakuben kan tillåta komplexa ad hoc-frågor och -analyser av prestandainformation.This data cube can allow complex ad hoc querying and analysis of the performance information.

SäkerhetsövervakningSecurity monitoring

Alla kommersiella system som innehåller känsliga data måste implementera en säkerhetsstruktur.All commercial systems that include sensitive data must implement a security structure. Säkerhetsmekanismens komplexitet är vanligtvis en funktion för känsliga data.The complexity of the security mechanism is usually a function of the sensitivity of the data. I ett system som kräver att användare autentiseras ska du registrera:In a system that requires users to be authenticated, you should record:

  • Alla inloggningsförsök, huruvida de misslyckas eller lyckas.All sign-in attempts, whether they fail or succeed.
  • Alla åtgärder som utförs av — och information om alla resurser som används av — en autentiserad användare.All operations performed by—and the details of all resources accessed by—an authenticated user.
  • När en användare avslutar en session och loggar ut.When a user ends a session and signs out.

Med hjälp av övervakning kan du upptäcka attacker på systemet.Monitoring might be able to help detect attacks on the system. Ett stort antal misslyckade inloggningsförsök kan exempelvis tyda på en nyckelsökningsattack.For example, a large number of failed sign-in attempts might indicate a brute-force attack. En oväntat ökning av begäranden kan bero på en distribuerad överbelastningsattack (DDoS).An unexpected surge in requests might be the result of a distributed denial-of-service (DDoS) attack. Du måste vara förberedd på att övervaka alla begäranden till alla källor, oavsett källan för de här begärandena.You must be prepared to monitor all requests to all resources regardless of the source of these requests. Ett system som är inloggningskänsligt kan av misstag exponera källor för omvärlden, utan att en användare faktiskt loggar in.A system that has a sign-in vulnerability might accidentally expose resources to the outside world without requiring a user to actually sign in.

Krav för säkerhetsövervakningRequirements for security monitoring

De viktigaste aspekterna i säkerhetsövervakning ska göra det möjligt för en operatör att snabbt:The most critical aspects of security monitoring should enable an operator to quickly:

  • Identifiera försök till intrång av en icke-autentiserad enhet.Detect attempted intrusions by an unauthenticated entity.
  • Identifiera enheter som försökt utföra åtgärder på data som de inte har beviljats åtkomst till.Identify attempts by entities to perform operations on data for which they have not been granted access.
  • Avgöra huruvida systemet eller någon del av systemet angripits utifrån eller inifrån.Determine whether the system, or some part of the system, is under attack from outside or inside. (Till exempel kan en autentiserad angripare försöka avsluta systemet.)(For example, a malicious authenticated user might be attempting to bring the system down.)

För att stödja dessa krav bör en operatör meddelas om:To support these requirements, an operator should be notified if:

  • Ett konto gör upprepade misslyckade inloggnings försök inom en angiven period.One account makes repeated failed sign-in attempts within a specified period.
  • Ett autentiserat konto försöker upprepade gånger att komma åt en otillåten resurs under en angiven period.One authenticated account repeatedly tries to access a prohibited resource during a specified period.
  • Ett stort antal oautentiserade eller icke-auktoriserade begär Anden sker under en angiven period.A large number of unauthenticated or unauthorized requests occur during a specified period.

Den information som har angetts för en operatör bör innehålla källans värdadress för varje begärande.The information that's provided to an operator should include the host address of the source for each request. Om säkerhetsöverträdelser uppstår från ett visst adressintervall kan de här värdarna blockeras.If security violations regularly arise from a particular range of addresses, these hosts might be blocked.

En viktig del i att upprätthålla ett systems säkerhet är att snabbt identifiera åtgärder som avviker från det vanliga mönstret.A key part in maintaining the security of a system is being able to quickly detect actions that deviate from the usual pattern. Information som antalet misslyckade och/eller lyckade begäranden om inloggningar kan visas för bidra till att upptäcka huruvida det finns en höjdpunkt i aktiviteten under en ovanlig tid.Information such as the number of failed and/or successful sign-in requests can be displayed visually to help detect whether there is a spike in activity at an unusual time. (Ett exempel på en sådan aktivitet är användare som loggar in kl 03:00 och utför många åtgärder, trots att deras arbetsdag börjar vid 09:00).(An example of this activity is users signing in at 3:00 AM and performing a large number of operations when their working day starts at 9:00 AM). Den här informationen kan också användas för att konfigurera tidsbaserad automatisk skalning.This information can also be used to help configure time-based autoscaling. Om en operatör iakttar att ett stort antal användare regelbundet loggar in vid en viss tid på dagen kan operatören upprätta ytterligare autentiseringstjänster för att hantera arbetsbelastningen och sedan stänga ned de ytterligare tjänsterna när en höjdpunkt passerat.For example, if an operator observes that a large number of users regularly sign in at a particular time of day, the operator can arrange to start additional authentication services to handle the volume of work, and then shut down these additional services when the peak has passed.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

Säkerhet är en omfattande aspekt av de mest distribuerade systemen.Security is an all-encompassing aspect of most distributed systems. Viktiga data genereras troligen på flera platser i ett system.The pertinent data is likely to be generated at multiple points throughout a system. Du bör överväga att anta ett förhållningssätt mer likt Säkerhetsinformation och händelsehantering (SIEM) för att samla in säkerhetsrelaterad information som är konsekvensen av utlösta händelser i programmet, nätverksutrustning, servrar, brandväggar, antivirusprogram och andra intrångsskyddande element.You should consider adopting a Security Information and Event Management (SIEM) approach to gather the security-related information that results from events raised by the application, network equipment, servers, firewalls, antivirus software, and other intrusion-prevention elements.

Säkerhetsövervakning kan innefatta data från verktyg som inte är en del av programmet.Security monitoring can incorporate data from tools that are not part of your application. De här verktygen kan innefatta funktioner som identifierar portskanningsaktiviteter från externa agenturer eller nätverksfilter som identifierar icke-autentiserade åtkomstförsök till program eller data.These tools can include utilities that identify port-scanning activities by external agencies, or network filters that detect attempts to gain unauthenticated access to your application and data.

Oavsett måste insamlade data göra det möjligt för en administratör att avgöra en attacks syfte och vidta lämpliga åtgärder.In all cases, the gathered data must enable an administrator to determine the nature of any attack and take the appropriate countermeasures.

Analysera säkerhetsdataAnalyzing security data

En säkerhetsövervakningsfunktion är en rad källor varifrån data uppstår.A feature of security monitoring is the variety of sources from which the data arises. De olika formaten och detaljnivån kräver ofta komplexa analyser av insamlade data för att förknippa dem till en enhetlig informationstråd.The different formats and level of detail often require complex analysis of the captured data to tie it together into a coherent thread of information. Bortsett från de enklaste fallen (som att spåra ett stort antal misslyckade inloggningar eller upprepade försök till att få oauktoriserad åtkomst till kritiska resurser) är det kanske inte möjligt att utföra komplex automatisk bearbetning av säkerhetsdata.Apart from the simplest of cases (such as detecting a large number of failed sign-ins, or repeated attempts to gain unauthorized access to critical resources), it might not be possible to perform any complex automated processing of security data. I stället kan det vara bättre att skriva dessa data, tidsstämplade men på annat sätt i sitt ursprungliga format, till en säker lagrings plats för manuell analys av experten.Instead, it might be preferable to write this data, timestamped but otherwise in its original form, to a secure repository to allow for expert manual analysis.

SLA-övervakningSLA monitoring

Många kommersiella system med stöd för betalande kunder ger garantier om systemets prestanda i form av SLA:er.Many commercial systems that support paying customers make guarantees about the performance of the system in the form of SLAs. SLA-tillstånd anger i huvudsak att systemet kan hantera en definierad mängd arbete inom en överenskommen tidsram och utan att förlora nödvändig information.Essentially, SLAs state that the system can handle a defined volume of work within an agreed time frame and without losing critical information. SLA-övervakning har som syfte att säkerställa att systemet kan uppfylla mätbara SLA:er.SLA monitoring is concerned with ensuring that the system can meet measurable SLAs.

Anteckning

SLA-övervakning är nära förknippat med prestandaövervakning.SLA monitoring is closely related to performance monitoring. Medan prestandaövervakningens syfte är att säkerställa att systemet fungerar optimalt kontrolleras SLA-övervakning av avtalsskyldighet som definierar vad optimalt faktiskt innebär.But whereas performance monitoring is concerned with ensuring that the system functions optimally, SLA monitoring is governed by a contractual obligation that defines what optimally actually means.

SLA:er definieras ofta enligt följande:SLAs are often defined in terms of:

  • Systemets totala tillgänglighet.Overall system availability. En organisation kan till exempel garantera att systemet är tillgängligt 99,9 procent av tiden.For example, an organization might guarantee that the system will be available for 99.9 percent of the time. Det innebär max nio timmars nedtid per år eller ungefär tio minuter per vecka.This equates to no more than 9 hours of downtime per year, or approximately 10 minutes a week.
  • Driftdataflöde.Operational throughput. Den här aspekten uttrycks ofta som en eller flera övre vattenmärken, som garanti för att systemet har stöd för upp till 100 000 samtida användare eller kan hantera 10 000 samtida företagstransaktioner.This aspect is often expressed as one or more high-water marks, such as guaranteeing that the system can support up to 100,000 concurrent user requests or handle 10,000 concurrent business transactions.
  • Driftsvarstid.Operational response time. Systemet kan också ge garantier för vilken frekvens som begäranden bearbetas inom.The system might also make guarantees for the rate at which requests are processed. Ett exempel är att 99 procent av alla företagstransaktioner avslutas inom två sekunder och att inga enskilda transaktioner tar längre tid än tio sekunder.An example is that 99 percent of all business transactions will finish within 2 seconds, and no single transaction will take longer than 10 seconds.

Anteckning

Vissa kontrakt för kommersiella system kan även innehålla SLA:er för teknisk support.Some contracts for commercial systems might also include SLAs for customer support. Ett exempel är att alla förfrågningar till supportavdelningen får ett svar inom fem minuter och att 99 procent av alla problem kommer att åtgärdas inom 1 arbets dag.An example is that all help-desk requests will elicit a response within five minutes, and that 99 percent of all problems will be fully addressed within 1 working day. Effektiv ärendeuppföljning (beskrivs senare i det här avsnittet) är nyckeln till att uppfylla SLA:er som de här.Effective issue tracking (described later in this section) is key to meeting SLAs such as these.

Krav för övervakning av SLA-övervakningRequirements for SLA monitoring

På den högsta nivån ska en operatör snabbt kunna avgöra huruvida systemet uppfyller avtalade SLA:er eller inte.At the highest level, an operator should be able to determine at a glance whether the system is meeting the agreed SLAs or not. Om inte ska operatören kunna gå nedåt och granska underliggande faktorer nedåt för att fastställa orsakerna till att prestandan är under standard.And if not, the operator should be able to drill down and examine the underlying factors to determine the reasons for substandard performance.

Vanliga indikatorer på hög nivå som kan skildras visuellt innefattar:Typical high-level indicators that can be depicted visually include:

  • Tjänstens drifttid i procent.The percentage of service uptime.
  • Programmets dataflöde (mätt efter lyckade transaktioner och/eller åtgärder per sekund).The application throughput (measured in terms of successful transactions and/or operations per second).
  • Antal lyckade/misslyckade programbegäranden.The number of successful/failing application requests.
  • Antal program- och systemfel, undantag och varningar.The number of application and system faults, exceptions, and warnings.

Alla de här indikatorerna ska kunna filtreras bort av en angiven tidsperiod.All of these indicators should be capable of being filtered by a specified period of time.

Ett molnprogram omfattar sannolikt ett antal undersystem och komponenter.A cloud application will likely comprise a number of subsystems and components. En operatör ska kunna välja en indikator på hög nivå och visa hur den är sammansatt från hälsotillståndet för de underliggande elementen.An operator should be able to select a high-level indicator and see how it's composed from the health of the underlying elements. Om exempelvis det övergripande systemets drifttid sjunker nedanför ett godkänt värde ska en operatör kunna zooma in och avgöra vilka element som bidrar till felet.For example, if the uptime of the overall system falls below an acceptable value, an operator should be able to zoom in and determine which elements are contributing to this failure.

Anteckning

Systemets drifttid måste definieras noggrant.System uptime needs to be defined carefully. I ett system som använder redundans för att säkerställa maximal tillgänglighet kan enskilda elements instanser misslyckas, men systemet kan ändå fungera.In a system that uses redundancy to ensure maximum availability, individual instances of elements might fail, but the system can remain functional. Systemets drifttid som visas av hälsoövervakningen ska ange varje elements aggregerade drifttid och inte nödvändigtvis huruvida systemet faktiskt stoppats.System uptime as presented by health monitoring should indicate the aggregate uptime of each element and not necessarily whether the system has actually halted. Dessutom kan fel vara sporadiska.Additionally, failures might be isolated. Det innebär att även om ett visst system är otillgängligt kan återstoden av systemet vara tillgängligt, fast med begränsad funktionalitet.So even if a specific system is unavailable, the remainder of the system might remain available, although with decreased functionality. (I ett e-handelssystem kan ett systemfel hindra en kund från att göra en beställning, fast kunden fortfarande kan söka i produktkatalogen.)(In an e-commerce system, a failure in the system might prevent a customer from placing orders, but the customer might still be able to browse the product catalog.)

I varningssyfte ska systemet kunna skicka en händelse om någon av indikatorerna på hög nivå överstiger ett särskilt tröskelvärde.For alerting purposes, the system should be able to raise an event if any of the high-level indicators exceed a specified threshold. Informationen på låg nivå för de olika faktorerna som utgör indikatorn på hög nivå ska vara tillgängliga som kontextuella data i aviseringssystemet.The lower-level details of the various factors that compose the high-level indicator should be available as contextual data to the alerting system.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

De rådata som krävs som stöd för SLA-övervakning liknar de rådata som krävs för prestandaövervakning, samt andra hälsoaspekter och tillgänglighetsövervakning.The raw data that's required to support SLA monitoring is similar to the raw data that's required for performance monitoring, together with some aspects of health and availability monitoring. (Mer information finns i dessa avsnitt.) Du kan samla in dessa data genom att:(See those sections for more details.) You can capture this data by:

  • Genomföra slutpunktsövervakning.Performing endpoint monitoring.
  • Undantag för loggning, fel och aviseringar.Logging exceptions, faults, and warnings.
  • Spåra användarbegäranden.Tracing the execution of user requests.
  • Övervaka tillgänglighet av tredjepartstjänster som systemet använder.Monitoring the availability of any third-party services that the system uses.
  • Använda prestandamått och -räknare.Using performance metrics and counters.

Alla data måste vara tidsbegränsade och tidsstämplade.All data must be timed and timestamped.

Analysera SLA-dataAnalyzing SLA data

Instrumentationsdata måste aggregeras för att generera en bild över systemets totala prestanda.The instrumentation data must be aggregated to generate a picture of the overall performance of the system. Aggregerade data måste också ha stöd för att granska nedåt för att aktivera prestandagranskning i de underliggande undersystemen.Aggregated data must also support drill-down to enable examination of the performance of the underlying subsystems. Du ska exempelvis kunna:For example, you should be able to:

  • Beräkna det totala antalet användarbegäranden under en viss tidsperiod och avgöra slutförandefrekvens och misslyckandegrad för de här begärandena.Calculate the total number of user requests during a specified period and determine the success and failure rate of these requests.
  • Generera en övergripande vy över systemets svarstider genom att kombinera svarstiderna för användarbegärandena.Combine the response times of user requests to generate an overall view of system response times.
  • Beräkna den övergripande svarstiden för ett begärande i svarstiderna för begärandets enskilda arbetsobjekt genom att analysera förloppet för användarbegäranden.Analyze the progress of user requests to break down the overall response time of a request into the response times of the individual work items in that request.
  • Avgör systemets övergripande tillgänglighet i procentandel av drifttiden för en viss tidsperiod.Determine the overall availability of the system as a percentage of uptime for any specific period.
  • Analysera procentandelen av tillgänglighet i tid för enskilda komponenter och tjänster i systemet.Analyze the percentage time availability of the individual components and services in the system. Det här kan innefatta parsningsloggar som genererats av tredjepartstjänster.This might involve parsing logs that third-party services have generated.

Många kommersiella system krävs för att rapportera verkliga prestandasiffror gentemot överenskomna SLA:er för en angiven tidsperiod, vanligtvis en månad.Many commercial systems are required to report real performance figures against agreed SLAs for a specified period, typically a month. Den här informationen kan användas till att beräkna krediter eller annan typ av återbetalning till kunden om SLA:erna inte uppnås under tidsperioden.This information can be used to calculate credits or other forms of repayments for customers if the SLAs are not met during that period. Du kan beräkna en tjänsts tillgänglighet genom att använda den teknik som beskrivs i avsnittet Analysera tillgänglighetsdata.You can calculate availability for a service by using the technique described in the section Analyzing availability data.

För interna syften kan en organisation också spåra antalet incidenter och vad som ledde till att tjänsterna misslyckades.For internal purposes, an organization might also track the number and nature of incidents that caused services to fail. Minimera nedtid och uppfyll SLA:er genom att ta reda på hur du snabbt löser de här problemen eller eliminerar de helt.Learning how to resolve these issues quickly, or eliminate them completely, will help to reduce downtime and meet SLAs.

GranskningAuditing

Beroende på programmets egenskaper kan det finnas lagstiftning för krav på granskning av användaråtgärder och registrering av all dataåtkomst.Depending on the nature of the application, there might be statutory or other legal regulations that specify requirements for auditing users' operations and recording all data access. Granskning kan leda till bevismaterial som kopplar samman kunder till ett visst begärande.Auditing can provide evidence that links customers to specific requests. Oavvislig het är en viktig faktor i många e-affärssystem som hjälper till att upprätthålla förtroendet mellan en kund och den organisation som ansvarar för programmet eller tjänsten.Nonrepudiation is an important factor in many e-business systems to help maintain trust be between a customer and the organization that's responsible for the application or service.

Krav för granskningRequirements for auditing

En analytiker måste kunna spåra sekvensen för verksamhetsåtgärder som användare utför, så att du kan rekonstruera användarnas åtgärder.An analyst must be able to trace the sequence of business operations that users are performing so that you can reconstruct users' actions. Det här kan vara nödvändigt för registrering eller som en del i en rättsteknisk utredning.This might be necessary simply as a matter of record, or as part of a forensic investigation.

Granskning av information är högkänsligt.Audit information is highly sensitive. Den innehåller troligtvis data som identifierar systemanvändarna och åtgärderna som de utför.It will likely include data that identifies the users of the system, together with the tasks that they're performing. Därför presenteras granskningsinformation troligtvis i form av rapporter som endast är tillgängliga för betrodda analytiker istället för som ett interaktivt system med stöd för granskning nedåt i grafiska åtgärder.For this reason, audit information will most likely take the form of reports that are available only to trusted analysts rather than as an interactive system that supports drill-down of graphical operations. En analytiker ska kunna generera en mängd rapporter.An analyst should be able to generate a range of reports. Rapporterna kan exempelvis ordna alla användares aktiviteter som inträffar inom en angiven tidsram, visa en enskild användares aktiviteter i kronologisk ordning eller lista i vilken ordning åtgärder utförts gentemot en eller flera resurser.For example, reports might list all users' activities occurring during a specified time frame, detail the chronology of activity for a single user, or list the sequence of operations performed against one or more resources.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

De huvudsakliga informationskällorna för granskning kan innefatta:The primary sources of information for auditing can include:

  • Säkerhetssystemet som hanterar användarautentisering.The security system that manages user authentication.
  • Spårningsloggar som registrerar användaraktivitet.Trace logs that record user activity.
  • Säkerhetsloggar som spårar alla identifierbara och icke-identifierbara nätverksbegäranden.Security logs that track all identifiable and unidentifiable network requests.

Formatet för granskningsdata och hur de lagras kan styras av lagstiftade krav.The format of the audit data and the way in which it's stored might be driven by regulatory requirements. Exempelvis är det kanske inte möjligt att på något vis rensa data.For example, it might not be possible to clean the data in any way. (Den måste registreras i ursprungligt format.) Åtkomst till lagrings platsen där den är lagrad måste skyddas för att förhindra manipulering.(It must be recorded in its original format.) Access to the repository where it's held must be protected to prevent tampering.

Analysera granskningsdataAnalyzing audit data

En analytiker måste kunna komma åt rådata i sin helhet och ursprungliga format.An analyst must be able to access the raw data in its entirety, in its original form. Bortsett från kraven på att generera vanliga granskningsrapporter är verktygen för att analysera data troligtvis specialiserade och förvaras utanför systemet.Aside from the requirement to generate common audit reports, the tools for analyzing this data are likely to be specialized and kept external to the system.

AnvändarövervakningUsage monitoring

Användarövervakning registrerar hur ett programs funktioner och komponenter används.Usage monitoring tracks how the features and components of an application are used. En operatör kan använda den insamlade informationen till att:An operator can use the gathered data to:

  • Avgöra vilka funktioner som används mycket och avgöra alla potentiella surfpunkter i systemet.Determine which features are heavily used and determine any potential hotspots in the system. Element med hög trafik kan dra nytta av funktionell partitionering eller till och med replikering för att sprida ut belastningen på jämnare vis.High-traffic elements might benefit from functional partitioning or even replication to spread the load more evenly. En operatör kan också använda den här informationen för att avgöra vilka funktioner som används sällan och som eventuellt ska dras tillbaka eller ersättas i framtida versioner av systemet.An operator can also use this information to ascertain which features are infrequently used and are possible candidates for retirement or replacement in a future version of the system.

  • Hämta information om drifthändelserna i systemet under normal användning.Obtain information about the operational events of the system under normal use. På en e-handelssida kan du exempelvis registrera statistisk information om antalet transaktioner och kunder som ansvarar för dem.For example, in an e-commerce site, you can record the statistical information about the number of transactions and the volume of customers that are responsible for them. Den här informationen kan användas för kapacitetsplanering allt eftersom att antalet kunder ökar.This information can be used for capacity planning as the number of customers grows.

  • Identifiera (möjligen indirekt) användarnöjdhet med hjälp av systemets prestanda eller funktioner.Detect (possibly indirectly) user satisfaction with the performance or functionality of the system. Om ett stort antal kunder i ett e-handelssystem regelbundet lämnar sina kundvagnar kan det exempelvis bero på ett problem med funktionen för att gå till kassan.For example, if a large number of customers in an e-commerce system regularly abandon their shopping carts, this might be due to a problem with the checkout functionality.

  • Generera faktureringsinformation.Generate billing information. Ett kommersiellt program eller tjänster för flera innehavare kan debitera kunder för de resurser de använder.A commercial application or multitenant service might charge customers for the resources that they use.

  • Tvinga fram kvoter.Enforce quotas. Om en användare i ett system för flera användare överskrider sin utbetalda kvot för bearbetningstid eller resursanvändning under en viss tidsperiod, kan deras åtkomst begränsas eller så kan bearbetningen begränsas.If a user in a multitenant system exceeds their paid quota of processing time or resource usage during a specified period, their access can be limited or processing can be throttled.

Krav för användarövervakningRequirements for usage monitoring

Om en operatör ska kontrollera systemanvändningen behöver den vanligtvis visa information som innefattar:To examine system usage, an operator typically needs to see information that includes:

  • Antalet begäranden som bearbetas av varje undersystem och dirigeras till varje resurs.The number of requests that are processed by each subsystem and directed to each resource.
  • Det arbete som utförs av varje användare.The work that each user is performing.
  • Mängden datalagring som varje användare använder.The volume of data storage that each user occupies.
  • Resurser som varje användare använder.The resources that each user is accessing.

En operatör ska även kunna generera diagram.An operator should also be able to generate graphs. Ett diagram kan exempelvis visa de mest resurshungriga användarna eller de mest använda resurserna eller systemfunktionerna.For example, a graph might display the most resource-hungry users, or the most frequently accessed resources or system features.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

Spårning av användning kan utföras på relativt hög nivå.Usage tracking can be performed at a relatively high level. Den kan notera start- och sluttider för varje begärande och dess egenskaper (läsa, skriva osv. beroende på resursen i fråga).It can note the start and end times of each request and the nature of the request (read, write, and so on, depending on the resource in question). Du kan hämta den här informationen genom att:You can obtain this information by:

  • Spåra användaraktivitet.Tracing user activity.
  • Läs in prestandaräknare som mäter användning för varje resurs.Capturing performance counters that measure the utilization for each resource.
  • Övervakning av resursanvändningen för varje användare.Monitoring the resource consumption by each user.

För mätnings syfte måste du också kunna identifiera vilka användare som ansvarar för att utföra vilka åtgärder och vilka resurser som används av dessa åtgärder.For metering purposes, you also need to be able to identify which users are responsible for performing which operations, and the resources that these operations use. Den insamlade informationen ska vara tillräckligt detaljerad för att kunna aktivera korrekt fakturering.The gathered information should be detailed enough to enable accurate billing.

ÄrendeuppföljningIssue tracking

Kunder och andra användare kan rapportera problem om oväntade händelser eller beteenden inträffar i systemet.Customers and other users might report issues if unexpected events or behavior occurs in the system. Ärendeuppföljning handlar om att hantera problemen, associera dem med försök att lösa systemets underliggande problem och informera kunder om möjliga lösningar.Issue tracking is concerned with managing these issues, associating them with efforts to resolve any underlying problems in the system, and informing customers of possible resolutions.

Krav på ärendeuppföljningRequirements for issue tracking

Operatörer utför ofta ärendeuppföljning med hjälp av ett separat system som gör det möjligt för dem att registrera och rapportera den probleminformation som användarna rapporterar.Operators often perform issue tracking by using a separate system that enables them to record and report the details of problems that users report. Den här informationen kan innefatta åtgärderna som användaren försökte utföra, symptom på problemet, händelseföljd och eventuella fel- eller varningsmeddelanden som utlösts.These details can include the tasks that the user was trying to perform, symptoms of the problem, the sequence of events, and any error or warning messages that were issued.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

Den inledande datakällan för ärendeuppföljningsdata är användaren som först rapporterade problemet.The initial data source for issue-tracking data is the user who reported the issue in the first place. Användaren kan tillhandahålla ytterligare information som:The user might be able to provide additional data such as:

  • En kraschdump (om programmet innefattar en komponent som kör på användarens skrivbord).A crash dump (if the application includes a component that runs on the user's desktop).
  • En ögonblicksbild av skärmen.A screen snapshot.
  • Datum och tid för när felet inträffade, tillsammans med annan information om omgivningen, som användarens plats.The date and time when the error occurred, together with any other environmental information such as the user's location.

Den här informationen kan användas till att bidra till felsökning och till att skapa kvarvarande uppgifter för framtida lanseringar av programvaran.This information can be used to help the debugging effort and help construct a backlog for future releases of the software.

Analysera ärendeuppföljningsdataAnalyzing issue-tracking data

Olika användare kan rapportera samma problem.Different users might report the same problem. Ärendeuppföljningsystemet ska associera till vanliga rapporter.The issue-tracking system should associate common reports.

Felsökningsförloppet ska registreras gentemot vardera felrapport.The progress of the debugging effort should be recorded against each issue report. När problemet är löst informeras kunden om lösningen.When the problem is resolved, the customer can be informed of the solution.

Om en användare rapporterar ett problem som har en känd lösning i ärendeuppföljningsystemet kan operatören omedelbart meddela användaren om lösningen.If a user reports an issue that has a known solution in the issue-tracking system, the operator should be able to inform the user of the solution immediately.

Spåra åtgärder och felsöka programversionerTracing operations and debugging software releases

När en användare rapporterar ett problem är användaren ofta bara medveten om den omedelbara påverkan den har på sina åtgärder.When a user reports an issue, the user is often only aware of the immediate effect that it has on their operations. Användaren kan bara rapportera ett resultat om sina egna upplevelser till en operatör som ansvarar för att underhålla systemet.The user can only report the results of their own experience back to an operator who is responsible for maintaining the system. Detta är vanligtvis bara synliga symptom på ett eller flera grundläggande problem.These experiences are usually just a visible symptom of one or more fundamental problems. I många fall behöver en analytiker leta i kronologisk ordning efter de underliggande åtgärderna, för att kunna fastställa problemets rotorsak.In many cases, an analyst will need to dig through the chronology of the underlying operations to establish the root cause of the problem. Processen kallas rotorsaksanalys.This process is called root cause analysis.

Anteckning

Rotorsaksanalysen kan uppdaga ineffektivitet i ett programs design.Root cause analysis might uncover inefficiencies in the design of an application. I sådana fall kan det vara möjligt att omarbeta berörda element och distribuera dem som en del av en senare version.In these situations, it might be possible to rework the affected elements and deploy them as part of a subsequent release. Den här processen kräver noggrann kontroll och de uppdaterade komponenterna bör övervakas noggrant.This process requires careful control, and the updated components should be monitored closely.

Krav för spårning och felsökningRequirements for tracing and debugging

Om du vill spåra oväntade händelser och andra problem är det viktigt att dina övervakningsdata tillhandahåller tillräckligt med information så att en analytiker kan spåra problemens ursprung och återskapa i vilken ordning som de inträffade.For tracing unexpected events and other problems, it's vital that the monitoring data provides enough information to enable an analyst to trace back to the origins of these issues and reconstruct the sequence of events that occurred. Den här informationen måste vara tillräcklig för att en analytiker ska kunna diagnostisera problemets rotorsak.This information must be sufficient to enable an analyst to diagnose the root cause of any problems. En utvecklare kan sedan genomföra nödvändiga ändringar så att det inte inträffar igen.A developer can then make the necessary modifications to prevent them from recurring.

Krav för insamling av data, instrumentation och datakällorData sources, instrumentation, and data-collection requirements

Felsökning kan innefatta alla de metoder (och respektive parametrar) som uppstått som del av en åtgärd för att bygga ett träd som avbildar det logiska flödet genom systemet när en kund gör ett visst begärande.Troubleshooting can involve tracing all the methods (and their parameters) invoked as part of an operation to build up a tree that depicts the logical flow through the system when a customer makes a specific request. Undantag och varningar som systemet genererar som resultat av flödet måste samlas in och loggas.Exceptions and warnings that the system generates as a result of this flow need to be captured and logged.

Som stöd för felsökning kan systemet tillhandahålla krokar som en operatör kan använda till att hämta tillståndsinformation vid kritiska punkter i systemet.To support debugging, the system can provide hooks that enable an operator to capture state information at crucial points in the system. Eller så kan systemet leverera utförlig information steg för steg allt eftersom de valda åtgärderna bearbetas.Or, the system can deliver detailed step-by-step information as selected operations progress. Att läsa in data på den här nivån kan skapa ytterligare belastning på systemet och bör vara en tillfällig process.Capturing data at this level of detail can impose an additional load on the system and should be a temporary process. En operatör använder i huvudsak den här processen när en väldigt ovanlig händelse inträffar och är svår att replikera eller när en ny version av ett eller flera element i ett system kräver noggrann övervakning för att säkerställa att elementen fungerar som förväntat.An operator uses this process mainly when a highly unusual series of events occurs and is difficult to replicate, or when a new release of one or more elements into a system requires careful monitoring to ensure that the elements function as expected.

Pipeline för övervakning och diagnostikThe monitoring and diagnostics pipeline

Det kan vara en stor utmaning att övervaka ett stort distribuerat system.Monitoring a large-scale distributed system poses a significant challenge. Alla scenarion som beskrivs i föregående avsnitt ska inte nödvändigtvis betraktas i sin enskildhet.Each of the scenarios described in the previous section should not necessarily be considered in isolation. Det är troligt att det uppstår en väsentlig överlappning i övervaknings- och diagnostikdata som krävs för vardera situation, trots att informationen kan behöva bearbetas och presenteras på olika sätt.There is likely to be a significant overlap in the monitoring and diagnostic data that's required for each situation, although this data might need to be processed and presented in different ways. Därför bör du anta en holistisk syn på övervakning och diagnostik.For these reasons, you should take a holistic view of monitoring and diagnostics.

Du kan betrakta hela övervaknings- och diagnostikprocessen som en pipeline som består av de steg som visas nedan på bild 1.You can envisage the entire monitoring and diagnostics process as a pipeline that comprises the stages shown in Figure 1.

Steg i pipeline för övervakning och diagnostik

Figur 1 – stegen i pipeline för övervakning och diagnostik.Figure 1 - The stages in the monitoring and diagnostics pipeline.

På bild 1 visas hur data för övervakning och diagnostik kan komma från en mängd olika datakällor.Figure 1 highlights how the data for monitoring and diagnostics can come from a variety of data sources. Stegen för instrumentation och insamling har att göra med att identifiera källorna som data måste läsas in ifrån och avgöra vilka data som ska läsas in, hur de ska hämtas och hur dessa data ska formateras så att de enkelt kan kontrolleras.The instrumentation and collection stages are concerned with identifying the sources from where the data needs to be captured, determining which data to capture, how to capture it, and how to format this data so that it can be easily examined. Steget för analys/diagnos använder rådata för att generera meningsfull information som en operatör kan använda för att avgöra systemets tillstånd.The analysis/diagnosis stage takes the raw data and uses it to generate meaningful information that an operator can use to determine the state of the system. Operatören kan med den här informationen ta beslut om möjliga åtgärder som ska vidtas och sedan skicka tillbaka resultatet till stegen för instrumentation och insamling.The operator can use this information to make decisions about possible actions to take, and then feed the results back into the instrumentation and collection stages. Fasen för visualisering/aviseringar visar en förbrukningsvy som kan användas av systemets tillstånd.The visualization/alerting stage phase presents a consumable view of the system state. Information kan visas i nära realtid med hjälp av en serie instrumentpaneler.It can display information in near real time by using a series of dashboards. Det kan generera rapporter, diagram och tabeller och på sås vis tillhandahålla en historisk översikt över de data som kan hjälpa dig att identifiera långsiktiga trender.And it can generate reports, graphs, and charts to provide a historical view of the data that can help identify long-term trends. Om information visar att en KPI riskerar att överskrida acceptabla gränser kan det här steget också utlösa en avisering till en operatör.If information indicates that a KPI is likely to exceed acceptable bounds, this stage can also trigger an alert to an operator. I vissa fall kan en avisering också användas för att utlösa en automatiserad process som försöker vidta åtgärder, till exempel autoskalning.In some cases, an alert can also be used to trigger an automated process that attempts to take corrective actions, such as autoscaling.

Observera att de här stegen utgör en kontinuerlig flödesprocess där stegen sker parallellt.Note that these steps constitute a continuous-flow process where the stages are happening in parallel. Vi rekommenderar att alla faser konfigureras dynamiskt.Ideally, all the phases should be dynamically configurable. Vid vissa tidpunkter, särskilt när ett system som nyligen har driftsatts eller har upplevt problem, kan det vara nödvändigt att samla in utökade data oftare.At some points, especially when a system has been newly deployed or is experiencing problems, it might be necessary to gather extended data on a more frequent basis. Vid andra tillfällen bör det vara möjligt att återgå till att läsa in basnivån för viktig information för att verifiera att systemet fungerar korrekt.At other times, it should be possible to revert to capturing a base level of essential information to verify that the system is functioning properly.

Dessutom bör hela övervakningsprocessen anses vara en pågående lösning i realtid som ska finjusteras och förbättras allteftersom feedback tas emot.Additionally, the entire monitoring process should be considered a live, ongoing solution that's subject to fine-tuning and improvements as a result of feedback. Du kan till exempel börja med att mäta många faktorer för att fastställa systemets hälsa.For example, you might start with measuring many factors to determine system health. Analysering över tid kan leda till förfining, då du avfärdar mått som är irrelevanta, vilket gör att du ökar fokus på de data du behöver och att bakgrundsljud minskar.Analysis over time might lead to a refinement as you discard measures that aren't relevant, enabling you to more precisely focus on the data that you need while minimizing background noise.

Källor för övervaknings- och diagnostikdataSources of monitoring and diagnostic data

Informationen som används för övervakningsprocessen kan komma från flera källor, som visas i bild 1.The information that the monitoring process uses can come from several sources, as illustrated in Figure 1. På programnivå kommer information från spårningsloggar som införlivas i systemets kod.At the application level, information comes from trace logs incorporated into the code of the system. Utvecklare bör följa en standardmetod för att spåra flödeskontrollen via sin kod.Developers should follow a standard approach for tracking the flow of control through their code. Exempelvis kan en post till en metod generera ett spårningsmeddelande som anger namnet på metoden, den aktuella tiden, värdet för varje parameter och annan relevant information.For example, an entry to a method can emit a trace message that specifies the name of the method, the current time, the value of each parameter, and any other pertinent information. Det kan också vara användbart att registrera in- och utloggningstider.Recording the entry and exit times can also prove useful.

Du bör logga alla undantag och varningar och se till att du behåller en fullständig spårning av eventuella kapslade undantag och varningar.You should log all exceptions and warnings, and ensure that you retain a full trace of any nested exceptions and warnings. Du bör helst hämta information som identifierar användaren som kör koden tillsammans med informationen för korrelationsaktivitet (för att spåra begäranden när de passerar genom systemet).Ideally, you should also capture information that identifies the user who is running the code, together with activity correlation information (to track requests as they pass through the system). Du bör också logga åtkomstförsök till alla resurser, som meddelandeköer, databaser, filer och andra beroende tjänster.And you should log attempts to access all resources such as message queues, databases, files, and other dependent services. Den här informationen kan användas för mätnings- och granskningsändamål.This information can be used for metering and auditing purposes.

Många program använder bibliotek och ramverk för att utföra vanliga uppgifter som att komma åt ett data lager eller kommunicera över ett nätverk.Many applications use libraries and frameworks to perform common tasks such as accessing a data store or communicating over a network. De här ramverken kan konfigureras för att tillhandahålla egna spårningsmeddelanden och rå diagnostisk information, som transaktionsfrekvens och lyckade och misslyckade dataöverföring.These frameworks might be configurable to provide their own trace messages and raw diagnostic information, such as transaction rates and data transmission successes and failures.

Anteckning

Många moderna ramverk publicerar automatiskt prestanda och spårningshändelser.Many modern frameworks automatically publish performance and trace events. Insamling av den här information handlar bara om att skapa ett sätt att hämta och lagra den där den kan bearbetas och analyseras.Capturing this information is simply a matter of providing a means to retrieve and store it where it can be processed and analyzed.

Operativsystemet där programmet körs kan vara en källa för systemomfattande information på låg nivå, till exempel prestandaräknare som anger I/O-frekvens, minnesanvändning och CPU-användning.The operating system where the application is running can be a source of low-level system-wide information, such as performance counters that indicate I/O rates, memory utilization, and CPU usage. Fel i operativsystemet (till exempel att det inte gick att öppna en fil korrekt) kan också rapporteras.Operating system errors (such as the failure to open a file correctly) might also be reported.

Du bör också ha de underliggande infrastrukturerna och komponenterna som kör ditt system i åtanke.You should also consider the underlying infrastructure and components on which your system runs. Virtuella datorer, virtuella nätverk och lagringstjänster kan vara källor med viktiga prestandaräknare och andra diagnostikdata på infrastrukturnivå.Virtual machines, virtual networks, and storage services can all be sources of important infrastructure-level performance counters and other diagnostic data.

Om programmet använder andra externa tjänster, till exempel en webbserver eller databashanteringssystem, kan de här tjänsterna publicera sin egen spårningsinformation samt egna loggar och prestandaräknare.If your application uses other external services, such as a web server or database management system, these services might publish their own trace information, logs, and performance counters. Exempel innefattar SQL Server Dynamic Management Views för spårningsåtgärder som utförs mot en SQL Server-databas och IIS-spårningsloggar för registrering av begäranden till en webbserver.Examples include SQL Server Dynamic Management Views for tracking operations performed against a SQL Server database, and IIS trace logs for recording requests made to a web server.

Allt eftersom att systemkomponenterna förändras och nya versioner lanseras är det är viktigt att kunna tillskriva varje versions problem, händelser och mått.As the components of a system are modified and new versions are deployed, it's important to be able to attribute issues, events, and metrics to each version. Den här informationen ska kopplas till versionspipelinen, så att problem med en viss komponentversion snabbt kan spåras och korrigeras.This information should be tied back to the release pipeline so that problems with a specific version of a component can be tracked quickly and rectified.

Säkerhetsproblem kan uppstå när som helst i systemet.Security issues might occur at any point in the system. Exempelvis kan en användare försöka logga in med ett ogiltigt användar-ID eller lösenord.For example, a user might attempt to sign in with an invalid user ID or password. En autentiserad användare kan försöka få oauktoriserad åtkomst till en resurs.An authenticated user might try to obtain unauthorized access to a resource. Eller så kan en användare försöka komma åt krypterad information med en ogiltig eller för gammal åtkomstnyckel.Or a user might provide an invalid or outdated key to access encrypted information. Säkerhetsrelaterad information för lyckade eller misslyckade begäranden ska alltid loggas.Security-related information for successful and failing requests should always be logged.

Avsnittet Arrangera ett program innehåller mer vägledning till informationen som du bör läsa in.The section Instrumenting an application contains more guidance on the information that you should capture. Du kan använda en mängd strategier för att samla in den här informationen:But you can use a variety of strategies to gather this information:

  • Program/systemövervakning.Application/system monitoring. Den här strategin använder interna källor inuti programmet, programmets ramverk, operativsystem och infrastruktur.This strategy uses internal sources within the application, application frameworks, operating system, and infrastructure. Programkoden kan generera sina egna övervakningsdata vid viktiga punkter under livscykeln för ett klientbegärande.The application code can generate its own monitoring data at notable points during the lifecycle of a client request. Programmet kan innehålla spårningsuppgifter som kan aktiveras eller inaktiveras beroende på omständigheterna.The application can include tracing statements that might be selectively enabled or disabled as circumstances dictate. Det kan också vara möjligt att mata in diagnostik dynamiskt med hjälp av ett ramverk för diagnostik.It might also be possible to inject diagnostics dynamically by using a diagnostics framework. De här ramverken har vanligtvis plugin-program som kan ansluta till olika instrumentationspunkter i koden och hämta spårningsdata vid de här punkterna.These frameworks typically provide plug-ins that can attach to various instrumentation points in your code and capture trace data at these points.

    Dessutom kan din kod och/eller underliggande infrastruktur utlösa händelser vid kritiska punkter.Additionally, your code and/or the underlying infrastructure might raise events at critical points. Övervakning av agenter som konfigurerats för att lyssna efter de här händelserna kan registrera händelseinformationen.Monitoring agents that are configured to listen for these events can record the event information.

  • Verklig användarövervakning.Real user monitoring. Med den här metoden registreras interaktioner mellan en användare och programmet, och flödet för varje begärande och svar observeras.This approach records the interactions between a user and the application and observes the flow of each request and response. Den här informationen kan ha ett dubbelt syfte: den kan användas för att mäta användning efter varje användare och för att avgöra huruvida användare tar emot service på lämplig nivå (exempelvis snabb svarstid, låg fördröjning och minimalt med fel).This information can have a two-fold purpose: it can be used for metering usage by each user, and it can be used to determine whether users are receiving a suitable quality of service (for example, fast response times, low latency, and minimal errors). Du kan använda inlästa data till att identifiera viktiga områden där fel oftast uppstår.You can use the captured data to identify areas of concern where failures occur most often. Du kan också använda data för att identifiera element då systemet blir långsammare, möjligen på grund av surfpunkter i programmet eller någon annan form av flaskhals.You can also use the data to identify elements where the system slows down, possibly due to hotspots in the application or some other form of bottleneck. Om du använder den här metoden noggrant kan det vara möjligt att rekonstruera användarnas flöden via programmet för felsökning och testning.If you implement this approach carefully, it might be possible to reconstruct users' flows through the application for debugging and testing purposes.

    Viktigt

    Du bör ha i åtanke att de data som läses in via övervakningen av riktiga användare är högkänsligt material, då de innehåller konfidentiellt material.You should consider the data that's captured by monitoring real users to be highly sensitive because it might include confidential material. Om du sparar inlästa data ska du lagra de på ett säkert sätt.If you save captured data, store it securely. Om du vill använda data för prestandaövervakning eller felsökningssyften ska du först ta bort all personligt identifierbar information.If you want to use the data for performance monitoring or debugging purposes, strip out all personally identifiable information first.

  • Övervakning av syntetisk användare.Synthetic user monitoring. Med den här metoden kan du skriva din egna testklient som simulerar en användare och utför en konfigurerbar men typisk rad åtgärder.In this approach, you write your own test client that simulates a user and performs a configurable but typical series of operations. Du kan spåra testklientens prestanda som hjälp för att avgöra systemets tillstånd.You can track the performance of the test client to help determine the state of the system. Du kan också använda flera instanser av testklienten som en del av ett belastningstest för att fastställa hur systemet svarar under hög belastning och vilken typ av övervakning av utdata som genereras under dessa villkor.You can also use multiple instances of the test client as part of a load-testing operation to establish how the system responds under stress, and what sort of monitoring output is generated under these conditions.

    Anteckning

    Du kan implementera verklig och syntetisk användarövervakning genom att inkludera kod som spårar och tar tid på metodanropets körning och andra viktiga delar i ett program.You can implement real and synthetic user monitoring by including code that traces and times the execution of method calls and other critical parts of an application.

  • Profilering.Profiling. Den här metoden är primärt avsett för att övervaka och förbättra programmets prestanda.This approach is primarily targeted at monitoring and improving application performance. Istället för att fungera på den funktionella nivån för verklig och syntetisk användarövervakning läses information på lägre nivåer in medan programmet körs.Rather than operating at the functional level of real and synthetic user monitoring, it captures lower-level information as the application runs. Du kan implementera profilering genom att använda periodisk provtagning på ett programs körningstillstånd (avgöra vilka delar i koden som programmet använder vid en viss tidpunkt).You can implement profiling by using periodic sampling of the execution state of an application (determining which piece of code that the application is running at a given point in time). Du kan också använda instrumentation som infogar avsökningar i koden vid viktiga föreningspunkter (till exempel start och slut för ett metodanrop ) och registrerar vilka metoder som anropades vid vilken tidpunkt och hur lång tid varje anrop tog.You can also use instrumentation that inserts probes into the code at important junctures (such as the start and end of a method call) and records which methods were invoked, at what time, and how long each call took. Du kan sedan analysera dina data och avgöra vilka delar i programmet som kan orsaka prestandaproblemen.You can then analyze this data to determine which parts of the application might cause performance problems.

  • Slut punkts övervakning.Endpoint monitoring. Den här metoden använder en eller flera diagnostiska slutpunkter som exponeras specifikt av programmet för att aktivera övervakning.This technique uses one or more diagnostic endpoints that the application exposes specifically to enable monitoring. En slutpunkt skapar en gångstig i programkoden och kan returnera information om systemets hälsotillstånd.An endpoint provides a pathway into the application code and can return information about the health of the system. Olika slutpunkter kan fokusera på olika aspekter av funktionen.Different endpoints can focus on various aspects of the functionality. Du kan skriva en egen diagnostikklient som skickar regelbundna begäranden till slutpunkterna och sammanställa svaren.You can write your own diagnostics client that sends periodic requests to these endpoints and assimilate the responses. Mer information finns i övervaknings mönstret för hälso slut punkt.For more information, see the Health Endpoint Monitoring pattern.

För maximal täckning bör du använda en kombination av dessa metoder.For maximum coverage, you should use a combination of these techniques.

Instrumentering av ett programInstrumenting an application

Instrumentation är en viktig del i övervakningsprocessen.Instrumentation is a critical part of the monitoring process. Du kan bara ta meningsfulla beslut om prestandan och hälsotillståndet för ett system om du först hämtade data som gör att du kan ta de här besluten.You can make meaningful decisions about the performance and health of a system only if you first capture the data that enables you to make these decisions. Den information som du samlar in med hjälp av instrumentation bör vara tillräckliga för att utvärdera prestanda, diagnostisera problem och ta beslut utan att behöva logga in på en fjärransluten produktionsserver och utföra spårning (och felsökning) manuellt.The information that you gather by using instrumentation should be sufficient to enable you to assess performance, diagnose problems, and make decisions without requiring you to sign in to a remote production server to perform tracing (and debugging) manually. Instrumentationsdata omfattar vanligtvis mått och information som skrivs till spårningsloggar.Instrumentation data typically comprises metrics and information that's written to trace logs.

Innehållet i en spårningslogg kan vara resultatet av textdata som skrivits av programmet eller binära data som skapats som ett resultat av en spårningshändelse (om programmet använder Händelsespårning för Windows – ETW).The contents of a trace log can be the result of textual data that's written by the application or binary data that's created as the result of a trace event (if the application is using Event Tracing for Windows--ETW). De kan också genereras från systemloggar som registrerar händelser från delar av infrastrukturen, till exempel en webbserver.They can also be generated from system logs that record events arising from parts of the infrastructure, such as a web server. Textloggsmeddelanden utformas ofta för att vara läsbara för mänskliga ögat, men de bör också skrivas i ett format som gör det möjligt för automatiserade system att enkelt parsa dem.Textual log messages are often designed to be human-readable, but they should also be written in a format that enables an automated system to parse them easily.

Du bör också kategorisera loggar.You should also categorize logs. Skriv inte alla spårningsdata till en enskild logg, utan registrera spårningsutdata från systemets olika driftaspekter med hjälp av separata loggar.Don't write all trace data to a single log, but use separate logs to record the trace output from different operational aspects of the system. Du kan då snabbt filtrera loggmeddelanden genom att läsa i respektive logg, istället för att behöva bearbeta en enda lång fil.You can then quickly filter log messages by reading from the appropriate log rather than having to process a single lengthy file. Skriv aldrig information som har andra säkerhetskrav (som granskningsinformation och felsökningsdata) till samma logg.Never write information that has different security requirements (such as audit information and debugging data) to the same log.

Anteckning

En logg kan implementeras som en fil i filsystemet eller lagras i något annat format, till exempel som blob i bloblagring.A log might be implemented as a file on the file system, or it might be held in some other format, such as a blob in blob storage. Logginformation kan också lagras på ett mer strukturerat sätt, som rader i en tabell.Log information might also be held in more structured storage, such as rows in a table.

Mått är vanligtvis mått eller beräkningar från vissa aspekter eller resurser i systemet vid en viss tidpunkt, med en eller flera associerade taggar eller dimensioner (kallas i bland för ett prov).Metrics will generally be a measure or count of some aspect or resource in the system at a specific time, with one or more associated tags or dimensions (sometimes called a sample). En enskild instans för ett mått är vanligtvis inte användbar på egen hand.A single instance of a metric is usually not useful in isolation. Måtten måste i stället samlas över tid.Instead, metrics have to be captured over time. Det är viktigt att tänka på vilka mått som du ska registrera och hur ofta.The key issue to consider is which metrics you should record and how frequently. Om du genererar data för mått för ofta kan den extra belastningen på systemet bli avsevärd, medan du riskerar att gå miste om omständigheter som orsakar en betydande händelse om du läser in måtten för sällan.Generating data for metrics too often can impose a significant additional load on the system, whereas capturing metrics infrequently might cause you to miss the circumstances that lead to a significant event. Övervägandena varierar från mått till mått.The considerations will vary from metric to metric. CPU-användning på en server kan exempelvis variera avsevärt från en sekund till en annan, men hög användning blir bara ett problem om det är långlivat i mer ett antal minuter.For example, CPU utilization on a server might vary significantly from second to second, but high utilization becomes an issue only if it's long-lived over a number of minutes.

Information för att korrelera dataInformation for correlating data

Du kan enkelt övervaka enskilda prestandaräknare på systemnivå, hämta mått för resurser och hämta spårningsinformation för program från olika loggfiler.You can easily monitor individual system-level performance counters, capture metrics for resources, and obtain application trace information from various log files. Vissa typer av övervakning kräver dock att analys- och diagnostiksteget i övervakningspipelinen korrelerar informationen som hämtats från flera källor.But some forms of monitoring require the analysis and diagnostics stage in the monitoring pipeline to correlate the data that's retrieved from several sources. Dessa data kan ta sig olika former i dina rådata och analysprocessen måste anges med tillräckliga instrumentationsdata för att kunna mappa de olika formaten.This data might take several forms in the raw data, and the analysis process must be provided with sufficient instrumentation data to be able to map these different forms. På nivån för programmets ramverk kan exempelvis en uppgift identifieras av tråd-ID.For example, at the application framework level, a task might be identified by a thread ID. I ett program kan samma jobb associeras med användar-ID:t för den användare som utför uppgiften.Within an application, the same work might be associated with the user ID for the user who is performing that task.

Det är också osannolikt att 1:1-mappning används mellan trådar och användarbegäranden, eftersom asynkrona åtgärder kan återanvända samma trådar för att utföra åtgärder å en eller flera användares vägnar.Also, there's unlikely to be a 1:1 mapping between threads and user requests, because asynchronous operations might reuse the same threads to perform operations on behalf of more than one user. För att göra saker och ting ytterligare lite mer komplicerade kan ett enskilt begärande hanteras av fler än en tråd, eftersom utförandet flödar i systemet.To complicate matters further, a single request might be handled by more than one thread as execution flows through the system. Om det är möjligt ska du associera ett begärande med ett unikt aktivitets-ID som sprids i systemet som en del av begärandets kontext.If possible, associate each request with a unique activity ID that's propagated through the system as part of the request context. (Tekniken för att generera och inkludera aktivitets-ID:n i spårningsinformation beror på tekniken som används för att hämta spårningsdata.)(The technique for generating and including activity IDs in trace information depends on the technology that's used to capture the trace data.)

Alla övervaknings data ska vara tidsstämplade på samma sätt.All monitoring data should be timestamped in the same way. Du skapar konsekvens genom att registrera alla datum och tidpunkter med hjälp av Koordinerad universell tid.For consistency, record all dates and times by using Coordinated Universal Time. Detta hjälper dig att enkelt spåra händelsesekvenser.This will help you more easily trace sequences of events.

Anteckning

Datorer i olika tidszoner och nätverk kan kanske inte synkroniseras.Computers operating in different time zones and networks might not be synchronized. Är inte beroende av att enbart använda tidsstämplar för att korrelera Instrumentation-data som sträcker sig över flera datorer.Don't depend on using timestamps alone for correlating instrumentation data that spans multiple machines.

Information som ska ingå i instrumentationsdataInformation to include in the instrumentation data

Ha följande punkter i åtanke när du bestämmer dig för vilka instrumentationsdata du behöver samla in:Consider the following points when you're deciding which instrumentation data you need to collect:

  • Kontrollera att informationen som lästs in av spårningshändelser är läsbar för mänskliga ögat och datorer.Make sure that information captured by trace events is machine and human readable. Anta väldefinierade scheman för den här informationen för att underlätta den automatiserade bearbetningen av loggdata i de olika systemen och skapa konsekvens bland åtgärder och för den tekniska personalen som läser loggarna.Adopt well-defined schemas for this information to facilitate automated processing of log data across systems, and to provide consistency to operations and engineering staff reading the logs. Inkludera miljöinformation, som distributionsmiljö, vilken dator som ska köra processen, processinformation och anropsstack.Include environmental information, such as the deployment environment, the machine on which the process is running, the details of the process, and the call stack.

  • Aktivera profilering endast när det är nödvändigt, eftersom det kan det innebära stor belastning på systemet.Enable profiling only when necessary because it can impose a significant overhead on the system. Profilering med hjälp av instrumentation registrerar en händelse (till exempel ett metodanrop) varje gång en sådan uppstår, medan sampling endast registrerar utvalda händelser.Profiling by using instrumentation records an event (such as a method call) every time it occurs, whereas sampling records only selected events. Urvalet kan vara tidsbaserat (en gång var n:te sekund) eller frekvens-baserad (en gång per n -begäranden).The selection can be time-based (once every n seconds), or frequency-based (once every n requests). Om händelser inträffar ofta kan profilering med instrumentation orsaka för mycket belastning och påverka den totala prestandan.If events occur very frequently, profiling by instrumentation might cause too much of a burden and itself affect overall performance. I sådana fall kan en samplingsmetod vara att föredra.In this case, the sampling approach might be preferable. Om frekvensen för händelser däremot är låg kan sampling gå miste om dem.However, if the frequency of events is low, sampling might miss them. I sådana fall kan instrumentation vara en bättre metod.In this case, instrumentation might be the better approach.

  • Genom att tillhandahålla tillräckligt med kontext blir det möjligt för en utvecklare eller administratör att avgöra källan för varje begärande.Provide sufficient context to enable a developer or administrator to determine the source of each request. Det här kan innefatta en typ av aktivitets-ID som identifierar en viss instans för ett begärande.This might include some form of activity ID that identifies a specific instance of a request. Det kan även innefatta information som kan användas för att korrelera aktiviteten med dataarbetet som utförs och de resurser som används.It might also include information that can be used to correlate this activity with the computational work performed and the resources used. Observera att jobbet kan korsa process- och datorgränser.Note that this work might cross process and machine boundaries. För mätning bör kontexten också innefatta (antingen direkt eller indirekt via annan korrelerad information) en referens till kunden som skickade begärandet.For metering, the context should also include (either directly or indirectly via other correlated information) a reference to the customer who caused the request to be made. Den här kontexten ger värdefull information om programmets hälsa vid tillfället då dina övervakningsdata lästes in.This context provides valuable information about the application state at the time that the monitoring data was captured.

  • Registrera alla begäranden och de platser eller regioner där begärandena görs.Record all requests, and the locations or regions from which these requests are made. Den här informationen kan bidra till att avgöra huruvida det finns några platsspecifika surfpunkter.This information can assist in determining whether there are any location-specific hotspots. Den här informationen kan också användas för att fastställa huruvida du vill partitionera om ett program eller de data som används.This information can also be useful in determining whether to repartition an application or the data that it uses.

  • Registrera och hämta noggrant information om undantag.Record and capture the details of exceptions carefully. Kritisk felsökningsinformation går ofta förlorad på grund av undermålig undantagshantering.Often, critical debug information is lost as a result of poor exception handling. Hämta fullständig information om undantag som programmet genererar, inklusive interna undantag och annan kontextinformation.Capture the full details of exceptions that the application throws, including any inner exceptions and other context information. Inkludera om möjligt anropsstacken.Include the call stack if possible.

  • Var konsekvent i de data som de olika elementen i programmet läser in, eftersom detta kan bidra till analyseringen av händelser och korrelera dem med användarbegäranden.Be consistent in the data that the different elements of your application capture, because this can assist in analyzing events and correlating them with user requests. Överväg att använda ett omfattande och konfigurerbart loggningspaket för att samla in information, istället för att förlita dig på att utvecklare ska anta samma metod när de implementerar olika delar av systemet.Consider using a comprehensive and configurable logging package to gather information, rather than depending on developers to adopt the same approach as they implement different parts of the system. Samla in data från huvudsakliga prestandaräknare, som volymen för I/O-utförande, nätverksanvändning, antal begäranden, minnesanvändning och CPU-användning.Gather data from key performance counters, such as the volume of I/O being performed, network utilization, number of requests, memory use, and CPU utilization. Vissa infrastrukturtjänster kan ange sina egna specifika prestandaräknare, till exempel antalet anslutningar till en databas, den hastighet som transaktioner utförs med och antalet transaktioner som lyckas eller misslyckas.Some infrastructure services might provide their own specific performance counters, such as the number of connections to a database, the rate at which transactions are being performed, and the number of transactions that succeed or fail. Program kan också definiera sina egna specifika prestandaräknare.Applications might also define their own specific performance counters.

  • Logga alla anrop till externa tjänster, till exempel databassystem, webbtjänster eller andra tjänster på systemnivå som ingår i infrastrukturen.Log all calls made to external services, such as database systems, web services, or other system-level services that are part of the infrastructure. Registrera information om den tid det tar att utföra varje anrop och huruvida anropet lyckas eller misslyckas.Record information about the time taken to perform each call, and the success or failure of the call. Hämta möjligt in information om alla nya försök och fel för tillfälliga fel som uppstår.If possible, capture information about all retry attempts and failures for any transient errors that occur.

Säkerställa kompatibilitet med telemetrisystemEnsuring compatibility with telemetry systems

Ofta genereras informationen som instrumentation producerar som en rad händelser och skickas till ett separat telemetrisystem för bearbetning och analys.In many cases, the information that instrumentation produces is generated as a series of events and passed to a separate telemetry system for processing and analysis. Ett telemetrisystem är vanligtvis oberoende av specifika program eller teknik, men det förväntar sig att information följer ett visst format som vanligtvis definieras av ett schema.A telemetry system is typically independent of any specific application or technology, but it expects information to follow a specific format that's usually defined by a schema. Schemat anger effektivt ett kontrakt som definierar datafältet och -typerna som telemetrisystemet kan mata in.The schema effectively specifies a contract that defines the data fields and types that the telemetry system can ingest. Schemat måste vara generaliserat, så att data kan komma från flera olika plattformar och enheter.The schema should be generalized to allow for data arriving from a range of platforms and devices.

Ett gemensamt schema ska innefatta fält som är gemensamma för alla instrumentationshändelser, till exempel händelsenamn, tidpunkt för händelsen, avsändarens IP-adress och den information som krävs för korrelering med andra händelser (som användar-ID, ett enhets-ID och ett program-ID).A common schema should include fields that are common to all instrumentation events, such as the event name, the event time, the IP address of the sender, and the details that are required for correlating with other events (such as a user ID, a device ID, and an application ID). Kom ihåg att antalet enheter inte påverkar att händelser utlöses, så schemat bör inte bero på enhetstypen.Remember that any number of devices might raise events, so the schema should not depend on the device type. Dessutom kan flera enheter utlösa händelser från samma program – programmet kan ha stöd för roaming eller andra format för distribuering mellan flera enheter.Additionally, various devices might raise events for the same application; the application might support roaming or some other form of cross-device distribution.

Schemat kan också innehålla domänfält som är relevanta för ett visst scenario som är gemensamt för olika program.The schema might also include domain fields that are relevant to a particular scenario that's common across different applications. Det kan vara information om undantag, programstart och sluthändelser och webbtjänsters lyckade och/eller misslyckade API-anrop.This might be information about exceptions, application start and end events, and success and/or failure of web service API calls. Alla program som använder samma uppsättning domänfält ska generera samma uppsättning händelser, aktivera en uppsättning gemensamma rapporter och analyser som ska skapas.All applications that use the same set of domain fields should emit the same set of events, enabling a set of common reports and analytics to be built.

Slutligen kan ett schema innehålla anpassade fält för att samla in information om programspecifika händelser.Finally, a schema might contain custom fields for capturing the details of application-specific events.

Metodtips för instrumentering av programBest practices for instrumenting applications

I följande lista sammanställs metodtips för instrumentering av ett distribuerat program som körs i molnet.The following list summarizes best practices for instrumenting a distributed application running in the cloud.

  • Gör loggar lätta att läsa och enkla att parsa.Make logs easy to read and easy to parse. Använd om möjligt strukturerad loggning.Use structured logging where possible. Var kort och beskrivande i loggmeddelanden.Be concise and descriptive in log messages.

  • Identifiera källan och tillhandahåll kontext och tidtagningsinformation i alla loggar när varje loggpost skrivs.In all logs, identify the source and provide context and timing information as each log record is written.

  • Använd samma tidszon och format för alla tidsstämplar.Use the same time zone and format for all timestamps. På så vis blir det enklare att korrelera händelser för åtgärder som sträcker sig över maskinvara och tjänster som körs på flera olika geografiska platser.This will help to correlate events for operations that span hardware and services running in different geographic regions.

  • Kategorisera loggar och skriv meddelanden till lämplig loggfil.Categorize logs and write messages to the appropriate log file.

  • Lämna inte ut känslig information om systemet eller personlig information om användare.Do not disclose sensitive information about the system or personal information about users. Skrubba informationen innan den är inloggad, men se till att relevant information bevaras.Scrub this information before it's logged, but ensure that the relevant details are retained. Ta till exempel bort ID och lösenord från alla strängar för databasanslutning, men skriv återstående information till loggen, så att en analytiker kan avgöra om systemet har åtkomst till rätt databas.For example, remove the ID and password from any database connection strings, but write the remaining information to the log so that an analyst can determine that the system is accessing the correct database. Logga alla kritiska undantag, men låt administratören aktivera eller inaktivera loggning för lägre nivåer av undantag och varningar.Log all critical exceptions, but enable the administrator to turn logging on and off for lower levels of exceptions and warnings. Hämta och logga också all logikinformation för omprövning.Also, capture and log all retry logic information. Dessa data kan vara användbara vid övervakning av systemets tillfälliga hälsotillstånd.This data can be useful in monitoring the transient health of the system.

  • Spåra utanför processers anrop, till exempel begäranden till externa webbtjänster och databaser.Trace out of process calls, such as requests to external web services or databases.

  • Blanda inte loggmeddelanden med olika säkerhetskrav i samma loggfil.Don't mix log messages with different security requirements in the same log file. Skriv till exempel inte felsöknings- och granskningsinformation till samma logg.For example, don't write debug and audit information to the same log.

  • Med undantag för granskningshändelser ska du se till att alla loggningsanrop är ”fire-and-forget”-åtgärder som inte blockerar verksamhetsåtgärders utveckling.With the exception of auditing events, make sure that all logging calls are fire-and-forget operations that do not block the progress of business operations. Granskningshändelser är undantag eftersom de är viktiga för verksamheten och kan klassificeras som en grundläggande del av verksamheten.Auditing events are exceptional because they are critical to the business and can be classified as a fundamental part of business operations.

  • Se till att loggning kan utökas och inte har några direkta beroenden på ett konkret mål.Make sure that logging is extensible and does not have any direct dependencies on a concrete target. Istället för att exempelvis skriva information med hjälp av System.Diagnostics.Trace definierar du ett abstrakt gränssnitt (som ILogger) som exponerar loggningsmetoder och kan implementeras via lämpliga medel.For example, rather than writing information by using System.Diagnostics.Trace, define an abstract interface (such as ILogger) that exposes logging methods and that can be implemented through any appropriate means.

  • Se till att all loggning är felsäker och aldrig utlöser övergripande fel.Make sure that all logging is fail-safe and never triggers any cascading errors. Loggning får inte utlösa undantag.Logging must not throw any exceptions.

  • Hantera instrumentation som en pågående iterativ process och granska loggarna regelbundet, inte bara när det uppstår ett problem.Treat instrumentation as an ongoing iterative process and review logs regularly, not just when there is a problem.

Samla in och lagra dataCollecting and storing data

Insamlingsstegen för övervakningsprocessen är att hämta informationen som instrumentation genererar, formatera data så att det blir enklare för analys-/diagnossteget att förbruka och spara transformerade data i ett tillförlitligt lager.The collection stage of the monitoring process is concerned with retrieving the information that instrumentation generates, formatting this data to make it easier for the analysis/diagnosis stage to consume, and saving the transformed data in reliable storage. Instrumentationsdata som du samlar in från olika delar av ett distribuerat system kan lagras på olika platser och med olika format.The instrumentation data that you gather from different parts of a distributed system can be held in a variety of locations and with varying formats. Exempelvis kan din programkod generera spårningsloggfiler och loggdata för programhändelser medan prestandaräknare som övervakar viktiga aspekter av den infrastruktur som används i ditt program kan läsas in via andra tekniker.For example, your application code might generate trace log files and generate application event log data, whereas performance counters that monitor key aspects of the infrastructure that your application uses can be captured through other technologies. Alla komponenter och tjänster från tredjepart som ditt program använder kan tillhandahålla instrumentationsinformation i olika format med hjälp av separata spårningsfiler, bloblagring och även ett anpassad datalager.Any third-party components and services that your application uses might provide instrumentation information in different formats, by using separate trace files, blob storage, or even a custom data store.

Insamling av data utförs ofta genom en samling tjänster som kan köras fristående från det program som genererar instrumentationsdata.Data collection is often performed through a collection service that can run autonomously from the application that generates the instrumentation data. Bild 2 visar ett exempel på den här arkitekturen, med undersystemet för insamling av instrumentationsdata.Figure 2 illustrates an example of this architecture, highlighting the instrumentation data-collection subsystem.

Exempel på insamling av instrumentationsdata

Figur 2 – samla in Instrumentation-data.Figure 2 - Collecting instrumentation data.

Observera att detta är en förenklad vy.Note that this is a simplified view. Samlingstjänsten är inte nödvändigtvis en enda process och kan omfatta många beståndsdelar som körs på olika datorer, så som beskrivs i följande avsnitt.The collection service is not necessarily a single process and might comprise many constituent parts running on different machines, as described in the following sections. Om analysen för vissa telemetridata dessutom måste genomföras snabbt (heta analyser, så som beskrivs i avsnitt Stöd för heta, varma och kalla analyser beskrivs senare i det här dokumentet) kan lokala komponenter som fungerar utanför insamlingstjänsten utföra analysuppgifter omedelbart.Additionally, if the analysis of some telemetry data must be performed quickly (hot analysis, as described in the section Supporting hot, warm, and cold analysis later in this document), local components that operate outside the collection service might perform the analysis tasks immediately. Bild 2 visar den här situationen för valda händelser.Figure 2 depicts this situation for selected events. Efter analytisk behandling kan resultatet skickas direkt till undersystemet för visualisering och aviseringar.After analytical processing, the results can be sent directly to the visualization and alerting subsystem. Data som är föremål för varm eller kall analys hålls kvar i lagring under tiden den väntar på bearbetning.Data that's subjected to warm or cold analysis is held in storage while it awaits processing.

Azure-program och -tjänster innehåller en möjlig lösning för att samla in data i Azure Diagnostics.For Azure applications and services, Azure Diagnostics provides one possible solution for capturing data. Azure Diagnostics samlar in data från följande källor för varje beräkningsnod, aggregerar och överför dem sedan till Azure Storage:Azure Diagnostics gathers data from the following sources for each compute node, aggregates it, and then uploads it to Azure Storage:

  • IIS-loggarIIS logs
  • Det gick inte begära loggar i IISIIS Failed Request logs
  • Windows-händelseloggarWindows event logs
  • PrestandaräknarePerformance counters
  • KraschdumparCrash dumps
  • Azure Diagnostics-infrastrukturloggarAzure Diagnostics infrastructure logs
  • Anpassa felloggarCustom error logs
  • .NET EventSource.NET EventSource
  • Manifestbaserad ETWManifest-based ETW

Mer information finns i artikeln om telemetrigrunderna och felsökning i Azure.For more information, see the article Azure: Telemetry Basics and Troubleshooting.

Strategier för insamling av instrumentationsdataStrategies for collecting instrumentation data

Med molnets elastiska egenskaper i åtanke och för att undvika att behöva hämta telemetridata manuellt från varje nod i systemet bör du ordna så att data överförs till en central plats och konsolideras.Considering the elastic nature of the cloud, and to avoid the necessity of manually retrieving telemetry data from every node in the system, you should arrange for the data to be transferred to a central location and consolidated. I ett system som omfattar flera datacenter kan det vara användbart att först samla in, konsolidera och lagra data utefter region och sedan aggregera regionala data till ett enda centralt system.In a system that spans multiple datacenters, it might be useful to first collect, consolidate, and store data on a region-by-region basis, and then aggregate the regional data into a single central system.

Du kan optimera användningen av bandbredd genom att välja att överföra mindre brådskande data i block, som batchar.To optimize the use of bandwidth, you can elect to transfer less urgent data in chunks, as batches. Data får dock inte fördröjas på obestämd tid, särskilt inte om de innehåller tidskänslig information.However, the data must not be delayed indefinitely, especially if it contains time-sensitive information.

Hämta och skicka instrumentationsdataPulling and pushing instrumentation data

Undersystemet för insamling av instrumentationsdata kan aktivt hämta instrumentationsdata från flera loggar och andra källor för varje instans av programmet (hämtningsmodellen).The instrumentation data-collection subsystem can actively retrieve instrumentation data from the various logs and other sources for each instance of the application (the pull model). Det kan också fungera som en passiv mottagare som väntar på att data skickas från komponenterna som utgör vardera instans av programmet (skickamodellen).Or, it can act as a passive receiver that waits for the data to be sent from the components that constitute each instance of the application (the push model).

En metod för att implementera skickamodellen är att använda övervakningsagenter som kör lokalt med varje instans av programmet.One approach to implementing the pull model is to use monitoring agents that run locally with each instance of the application. En övervakningsagent är en separat process som regelbundet hämtar telemetridata som samlats in på den lokala noden och skriver informationen direkt till centraliserad lagring som alla instanser av programmet delar.A monitoring agent is a separate process that periodically retrieves (pulls) telemetry data collected at the local node and writes this information directly to centralized storage that all instances of the application share. Det här är den mekanism som Azure Diagnostics implementerar.This is the mechanism that Azure Diagnostics implements. Varje instans av en webb- eller arbetsroll för Azure kan konfigureras att hämta diagnostik och annan spårningsinformation som lagras lokalt.Each instance of an Azure web or worker role can be configured to capture diagnostic and other trace information that's stored locally. Övervakningsagenten som körs medan varje instans kopierar angivna data till Azure Storage.The monitoring agent that runs alongside each instance copies the specified data to Azure Storage. Mer information om den här processen finns i artikeln om hur du aktiverar diagnostik i Azure Cloud Services och virtuella datorer.The article Enabling Diagnostics in Azure Cloud Services and Virtual Machines provides more details on this process. Vissa element, till exempel IIS-loggar, kraschdumpar och anpassade felloggar skrivs till bloblagring.Some elements, such as IIS logs, crash dumps, and custom error logs, are written to blob storage. Data från Windows-händelselogg, ETW-händelser och prestandaräknare registreras i tabellagring.Data from the Windows event log, ETW events, and performance counters is recorded in table storage. På bild 3 visas följande mekanism.Figure 3 illustrates this mechanism.

Bild av hur du hämtar information och skriver till ett delat lager med en övervakningsagent

Figur 3 – använda en övervaknings agent för att hämta information och skriva till delad lagring.Figure 3 - Using a monitoring agent to pull information and write to shared storage.

Anteckning

Användning av en övervakningsagent är helt anpassat för att läsa in instrumentationsdata som hämtas naturligt från en datakälla.Using a monitoring agent is ideally suited to capturing instrumentation data that's naturally pulled from a data source. Ett exempel är information från SQL Server med dynamiska hanteringsvyer eller längden på en Azure Service Bus-kö.An example is information from SQL Server Dynamic Management Views or the length of an Azure Service Bus queue.

Det är möjligt att lagra telemetridata för ett småskaligt program som körs på ett begränsat antal noder på en enda plats med den metod som beskrivs.It's feasible to use the approach just described to store telemetry data for a small-scale application running on a limited number of nodes in a single location. Ett komplext, högt skalbart, globalt molnprogram kan däremot generera stora mängder data från hundratals webb- och arbetsroller, databasshards och andra tjänster.However, a complex, highly scalable, global cloud application might generate huge volumes of data from hundreds of web and worker roles, database shards, and other services. Det här dataflödet kan enkelt överbelasta I/O-bandbredden som finns på en enskild central plats.This flood of data can easily overwhelm the I/O bandwidth available with a single, central location. Därför måste din telemetrilösning vara skalbar för att förhindra att den blir en flaskhals allteftersom systemet utökas.Therefore, your telemetry solution must be scalable to prevent it from acting as a bottleneck as the system expands. Helst bör din lösning omfatta en grad av redundans för att minska risken för att förlora viktig övervakningsinformation (till exempel gransknings- eller faktureringsdata) om en del av systemet skulle krascha.Ideally, your solution should incorporate a degree of redundancy to reduce the risks of losing important monitoring information (such as auditing or billing data) if part of the system fails.

Bemöt de här problemen genom att implementera köer, så som visas i bild 4.To address these issues, you can implement queuing, as shown in Figure 4. I den här arkitekturen publicerar den lokala övervakningsagenten (om den kan konfigureras korrekt) eller (om inte) den anpassade datainsamlingstjänsten data i en kö.In this architecture, the local monitoring agent (if it can be configured appropriately) or custom data-collection service (if not) posts data to a queue. En separat process som körs asynkront (tjänsten för att skriva till lager i bild 4) hämtar data i den här kön och skriver den till den delade lagringen.A separate process running asynchronously (the storage writing service in Figure 4) takes the data in this queue and writes it to shared storage. En meddelandekö är lämplig för det här scenariot eftersom det skapar ”minst en gång”-semantik som bidrar till att säkerställa att köade data inte går förlorade när de skickas.A message queue is suitable for this scenario because it provides "at least once" semantics that help ensure that queued data will not be lost after it's posted. Du kan implementera tjänsten för att skriva till lager med hjälp av en separat arbetsroll.You can implement the storage writing service by using a separate worker role.

Bild på hur du använder en kö för att buffra instrumentationsdata

Figur 4 – använda en kö för att buffra Instrumentation-data.Figure 4 - Using a queue to buffer instrumentation data.

Tjänsten för lokal datainsamling kan lägga till data i en kö omedelbart efter att den har tagits emot.The local data-collection service can add data to a queue immediately after it's received. Kön fungerar som en buffert och tjänsten för att skriva till lager kan hämta och skriva data i sin egen takt.The queue acts as a buffer, and the storage writing service can retrieve and write the data at its own pace. Som standard körs en kö på principen först in, först ut.By default, a queue operates on a first-in, first-out basis. Du kan dock prioritera meddelanden för att påskynda via kön om de innehåller data som måste hanteras snabbare.But you can prioritize messages to accelerate them through the queue if they contain data that must be handled more quickly. Mer information finns i mönstret prioritets kön.For more information, see the Priority Queue pattern. Du kan också använda olika kanaler (till exempel Service Bus-ämnen) för att dirigera data till olika mål, beroende på vilket format som krävs för analytisk bearbetning.Alternatively, you can use different channels (such as Service Bus topics) to direct data to different destinations depending on the form of analytical processing that's required.

För skalbarhet kan du köra flera instanser av tjänsten för att skriva till lager.For scalability, you can run multiple instances of the storage writing service. Om det finns ett stort antal händelser kan du använda en händelsehubb för att skicka data till olika beräkningsresurser för bearbetning och lagring.If there is a high volume of events, you can use an event hub to dispatch the data to different compute resources for processing and storage.

Konsolidera instrumentationsdataConsolidating instrumentation data

De instrumentationsdata som tjänsten för datainsamling hämtar från en enda instans av ett program skapar en lokaliserad vy över den instansens hälsa och prestanda.The instrumentation data that the data-collection service retrieves from a single instance of an application gives a localized view of the health and performance of that instance. Om du vill fastställa systemets övergripande hälsa är det nödvändigt att konsolidera vissa aspekter av de data som finns i de lokala vyerna.To assess the overall health of the system, it's necessary to consolidate some aspects of the data in the local views. Det här kan du utföra efter att data har lagrats, men i vissa fall kan du också uppnå det under tiden som data samlas in.You can perform this after the data has been stored, but in some cases, you can also achieve it as the data is collected. I stället för att skrivas direkt till en delad lagringsplats kan instrumentationsdata skickas via en separat tjänst för datakonsolidering som kombinerar data och fungerar som ett filter och en rensningsprocess.Rather than being written directly to shared storage, the instrumentation data can pass through a separate data consolidation service that combines data and acts as a filter and cleanup process. Till exempel kan instrumentationsdata som innehåller samma korrelationsinformation, exempelvis ett aktivitets-ID, slås samman.For example, instrumentation data that includes the same correlation information such as an activity ID can be amalgamated. (Det är möjligt att en användare börjar utföra en verksamhets åtgärd på en nod och sedan överförs till en annan nod vid nodfel, eller beroende på hur belastnings utjämning har kon figurer ATS.) Den här processen kan också identifiera och ta bort eventuella duplicerade data (alltid en risk om tjänsten telemetri använder meddelande köer för att skicka instrumentering till lagring).(It's possible that a user starts performing a business operation on one node and then gets transferred to another node in the event of node failure, or depending on how load balancing is configured.) This process can also detect and remove any duplicated data (always a possibility if the telemetry service uses message queues to push instrumentation data out to storage). I bild 5 visas ett exempel på den här strukturen.Figure 5 illustrates an example of this structure.

Exempel på hur du konsoliderar instrumentationsdata med hjälp av en tjänst

Figur 5 – använda en separat tjänst för att konsolidera och rensa instrument data.Figure 5 - Using a separate service to consolidate and clean up instrumentation data.

Lagra instrumentationsdataStoring instrumentation data

Tidigare diskussioner har förmedlat en förenklad bild av hur instrumentationsdata lagras.The previous discussions have depicted a rather simplistic view of the way in which instrumentation data is stored. I verkligheten kan det vara användbart att lagra de olika typerna av information med hjälp av tekniker som är mer anpassade till hur de olika typerna kommer att användas.In reality, it can make sense to store the different types of information by using technologies that are most appropriate to the way in which each type is likely to be used.

Till exempel finns det vissa likheter för åtkomst mellan Azure-blob och -tabellagring.For example, Azure blob and table storage have some similarities in the way in which they're accessed. De har dock begränsningar i vilka åtgärder som du kan utföra och kornigheten för dess data är ganska olik.But they have limitations in the operations that you can perform by using them, and the granularity of the data that they hold is quite different. Om du behöver utföra mer analytiska åtgärder eller kräver sökfunktioner för fullständig text på dina data kan det vara mer användbart att använda datalagring med funktioner som är optimerade för specifika typer av frågor och dataåtkomst.If you need to perform more analytical operations or require full-text search capabilities on the data, it might be more appropriate to use data storage that provides capabilities that are optimized for specific types of queries and data access. Exempel:For example:

  • Prestandaräknardata kan lagras i en SQL-databas för att aktivera ad hoc-analyser.Performance counter data can be stored in a SQL database to enable ad hoc analysis.
  • Spårningsloggar kan lagras bättre i Azure Cosmos DB.Trace logs might be better stored in Azure Cosmos DB.
  • Säkerhetsinformation kan skrivas till HDFS.Security information can be written to HDFS.
  • Information som kräver fullständig textsökning kan lagras via Elasticsearch (som också kan öka sökhastigheten med hjälp av omfattande indexering).Information that requires full-text search can be stored through Elasticsearch (which can also speed searches by using rich indexing).

Du kan implementera ytterligare en tjänst som regelbundet hämtar data från en delad lagringsplats, partitionerar och filtrerar data utefter dess syfte och sedan skriver den till en lämplig uppsättning av datalager som visas i bild 6.You can implement an additional service that periodically retrieves the data from shared storage, partitions and filters the data according to its purpose, and then writes it to an appropriate set of data stores as shown in Figure 6. En annan metod är att inkludera den här funktionen i konsoliderings- och rensningsprocessen och skriva data direkt till lagringsplatserna när de hämtas, istället för att spara dem i en mellanliggande delad lagringsplats.An alternative approach is to include this functionality in the consolidation and cleanup process and write the data directly to these stores as it's retrieved rather than saving it in an intermediate shared storage area. Varje metod har sina för- och nackdelar.Each approach has its advantages and disadvantages. Genom att implementera en separat partitioneringstjänst minskas belastningen på konsoliderings- och rensningstjänsten och gör det möjligt för åtminstone vissa av dina partitionerade data att återskapas vid behov (beroende på hur mycket data som lagrats på den delade lagringsplatsen).Implementing a separate partitioning service lessens the load on the consolidation and cleanup service, and it enables at least some of the partitioned data to be regenerated if necessary (depending on how much data is retained in shared storage). Detta förbrukar dock ytterligare resurser.However, it consumes additional resources. Dessutom kan det vara en fördröjning mellan mottagandet av instrumentationsdata från varje programinstans och konverteringen av data till tillämplig information.Also, there might be a delay between the receipt of instrumentation data from each application instance and the conversion of this data into actionable information.

Partitionering och lagring av data

Bild 6 – partitionera data enligt analys-och lagrings krav.Figure 6 - Partitioning data according to analytical and storage requirements.

Samma instrumentationsdata kan krävas för flera ändamål.The same instrumentation data might be required for more than one purpose. Prestandaräknare kan till exempel användas för att ge en historisk översikt över systemets prestanda över tid.For example, performance counters can be used to provide a historical view of system performance over time. Genom att kombinera den här informationen med andra användningsdata kan du generera kundens faktureringsinformation.This information might be combined with other usage data to generate customer billing information. I sådana situationer kan samma data skickas till flera mål, till exempel en dokumentdatabas som kan fungera som en långsiktig lagring av faktureringsinformation och en flerdimensionell lagring för hantering av komplexa prestandaanalyser.In these situations, the same data might be sent to more than one destination, such as a document database that can act as a long-term store for holding billing information, and a multidimensional store for handling complex performance analytics.

Du bör också överväga hur snabbt dina data behövs.You should also consider how urgently the data is required. Data som innehåller information för aviseringar måste kunna nås snabbt. Därför ska de lagras i snabb datalagring samt indexerade eller strukturerade för att optimera de frågor som aviseringssystemet utfört.Data that provides information for alerting must be accessed quickly, so it should be held in fast data storage and indexed or structured to optimize the queries that the alerting system performs. I vissa fall kan det vara nödvändigt för telemetritjänsten som samlar in data på varje nod att formatera och spara data lokalt, så att en lokal instans av aviseringssystemet snabbt kan meddela dig om eventuella problem.In some cases, it might be necessary for the telemetry service that gathers the data on each node to format and save data locally so that a local instance of the alerting system can quickly notify you of any issues. Samma data kan skickas till tjänsten för att skriva till lager, som visas i tidigare diagram, och lagras centralt om det krävs av andra orsaker.The same data can be dispatched to the storage writing service shown in the previous diagrams and stored centrally if it's also required for other purposes.

Information som används för mer övervägda analyser, rapportering och för att upptäcka historiska trender är mindre brådskande och kan lagras på ett sätt som stödjer datautvinning och ad hoc-frågor.Information that's used for more considered analysis, for reporting, and for spotting historical trends is less urgent and can be stored in a manner that supports data mining and ad hoc queries. Mer information finns i avsnittet Stöd för heta, varma och kalla analyser senare i det här dokumentet.For more information, see the section Supporting hot, warm, and cold analysis later in this document.

Loggrotation och datakvarhållningLog rotation and data retention

Instrumentation kan generera stora mängder data.Instrumentation can generate considerable volumes of data. Dessa data kan lagras på flera platser, från och med råa loggfiler, spårningsfiler och annan information som lästs in vid varje nod för konsoliderade, rensade och partitionerade vyer över data som lagras på delad lagringsplats.This data can be held in several places, starting with the raw log files, trace files, and other information captured at each node to the consolidated, cleaned, and partitioned view of this data held in shared storage. I vissa fall när data har bearbetats och överförts kan rå källdata tas bort från varje nod.In some cases, after the data has been processed and transferred, the original raw source data can be removed from each node. I annat fall kan det vara nödvändigt eller helt enkelt praktiskt att spara den råa informationen.In other cases, it might be necessary or simply useful to save the raw information. Till exempelvis kan det vara bättre att lämna data som genererats för felsökning i sitt råa format, och sedan snabbt tas bort efter att eventuella buggar har åtgärdats.For example, data that's generated for debugging purposes might be best left available in its raw form but can then be discarded quickly after any bugs have been rectified.

Prestandadata har ofta längre livslängd så att de kan användas för att upptäcka prestandatrender och kapacitetsplanering.Performance data often has a longer life so that it can be used for spotting performance trends and for capacity planning. Samlad vy över dessa data lagras vanligtvis online under en begränsad period för snabb åtkomst.The consolidated view of this data is usually kept online for a finite period to enable fast access. Efteråt kan den arkiveras eller tas bort.After that, it can be archived or discarded. Data som samlas in för mätning och fakturering av kunder kan behöva sparas på obestämd tid.Data gathered for metering and billing customers might need to be saved indefinitely. Dessutom kan lagstiftning bestämma att information som hämtats i gransknings- och säkerhetssyfte och måste arkiveras och sparas.Additionally, regulatory requirements might dictate that information collected for auditing and security purposes also needs to be archived and saved. Dessa data är också känsliga och kan behöva krypteras och skyddas på annat sätt för att förhindra manipulation.This data is also sensitive and might need to be encrypted or otherwise protected to prevent tampering. Du ska aldrig registrera användares lösenord eller annan information som kan användas för identitetsbedrägerier.You should never record users' passwords or other information that might be used to commit identity fraud. Sådan information ska rensas från dessa data innan de lagras.Such details should be scrubbed from the data before it's stored.

NedåtsamplingDown-sampling

Det är användbart att lagra historiska data så att du kan upptäcka långvariga trender.It's useful to store historical data so you can spot long-term trends. I stället för att spara gamla data i sin helhet kan det vara möjligt att minska upplösningen och spara lagringskostnader genom att nedåtsampla data.Rather than saving old data in its entirety, it might be possible to down-sample the data to reduce its resolution and save storage costs. Istället för att exempelvis spara prestandaindikatorer minut för minut kan du konsolidera data som är äldre än en månad och skapa en vy timme för timme.As an example, rather than saving minute-by-minute performance indicators, you can consolidate data that's more than a month old to form an hour-by-hour view.

Metodtips för att samla in och lagra loggningsinformationBest practices for collecting and storing logging information

I följande lista sammanfattas metodtips för insamling och lagring av loggningsinformation:The following list summarizes best practices for capturing and storing logging information:

  • Övervakningsagenten eller tjänsten för datainsamling ska köras som en tjänst utanför processen och bör vara enkel att distribuera.The monitoring agent or data-collection service should run as an out-of-process service and should be simple to deploy.

  • Alla utdata från övervakningsagenten eller tjänsten för datainsamling bör ha ett format som är oberoende av dator, operativsystem och nätverksprotokoll.All output from the monitoring agent or data-collection service should be an agnostic format that's independent of the machine, operating system, or network protocol. Till exempel generera information i ett självbeskrivande format, som JSON, MessagePack eller Protobuf istället för ETL/ETW.For example, emit information in a self-describing format such as JSON, MessagePack, or Protobuf rather than ETL/ETW. Genom att använda ett standardformat är det möjligt för systemet att konstruera processpipelines – komponenter som läser, transformerar och skickar data i det överenskomna formatet kan enkelt integreras.Using a standard format enables the system to construct processing pipelines; components that read, transform, and send data in the agreed format can be easily integrated.

  • Processen för övervakning och insamling av data måste vara felsäker och får inte utlösa sammanhängande felvillkor.The monitoring and data-collection process must be fail-safe and must not trigger any cascading error conditions.

  • Om ett tillfälligt fel i uppstår när information ska skickas till en dataplats ska övervakningsagenten eller tjänsten för datainsamling förberedas till att ändra ordningen på telemetridata, så att den senaste information skickas först.In the event of a transient failure in sending information to a data sink, the monitoring agent or data-collection service should be prepared to reorder telemetry data so that the newest information is sent first. (Övervakningsagenten/tjänsten för datainsamling kan utses att ta bort äldre data eller spara lokalt och överföra dem senare för att komma ifatt, efter eget gottfinnande.)(The monitoring agent/data-collection service might elect to drop the older data, or save it locally and transmit it later to catch up, at its own discretion.)

Analysera data och diagnostisera problemAnalyzing data and diagnosing issues

En viktig del av övervaknings- och diagnostikprocessen är att analysera den insamlade informationen för att få en bild av systemets övergripande hälsa.An important part of the monitoring and diagnostics process is analyzing the gathered data to obtain a picture of the overall well-being of the system. Du bör har definierat dina egna KPI:er och prestandamått och det är viktigt att förstå hur du kan strukturera de data som har samlats in för att uppfylla analyskraven.You should have defined your own KPIs and performance metrics, and it's important to understand how you can structure the data that has been gathered to meet your analysis requirements. Det är också viktigt att förstå hur data som hämtas i olika mått och loggfiler korreleras, eftersom den här informationen kan vara viktig för att spåra en händelsesekvens och diagnostisera problem som uppstår.It's also important to understand how the data that's captured in different metrics and log files is correlated, because this information can be key to tracking a sequence of events and help diagnose problems that arise.

Så som beskrivs i avsnittet Konsolidera instrumentationsdata hämtas data för varje del av systemet vanligtvis lokalt, men behöver generellt kombineras med data som genererats på andra sidor som deltar i systemet.As described in the section Consolidating instrumentation data, the data for each part of the system is typically captured locally, but it generally needs to be combined with data generated at other sites that participate in the system. Den här informationen kräver noggrann korrelation så att data kombineras korrekt.This information requires careful correlation to ensure that data is combined accurately. Användningsdata för en åtgärd kan exempelvis omfatta en nod som är värd för en webbplats som en användare ansluter till, en nod som kör en separat tjänst som en del av den här åtgärden och datalagring på en annan nod.For example, the usage data for an operation might span a node that hosts a website to which a user connects, a node that runs a separate service accessed as part of this operation, and data storage held on another node. Den här informationen måste vara sammanlänkande för att kunna ge en övergripande vy av åtgärdens resurs- och användningsdata.This information needs to be tied together to provide an overall view of the resource and processing usage for the operation. Vissa för bearbetning och filtrering av data kan inträffa på den nod där data har fångats, medan agg regering och formatering är mer sannolika på en central nod.Some preprocessing and filtering of data might occur on the node on which the data is captured, whereas aggregation and formatting are more likely to occur on a central node.

Stöd för heta, varma och kalla analyserSupporting hot, warm, and cold analysis

Analysera och formatera om data för visualiserings-, rapporterings- och aviseringsändamål kan vara en komplicerad process som använder en egen uppsättning resurser.Analyzing and reformatting data for visualization, reporting, and alerting purposes can be a complex process that consumes its own set of resources. Vissa typer av övervakning är brådskande och kräver omedelbar dataanalys för att vara effektiv.Some forms of monitoring are time-critical and require immediate analysis of data to be effective. Detta kallas het analys.This is known as hot analysis. Det inkluderar exempelvis analyser som krävs för aviseringar och vissa aspekter av säkerhetsövervakning (som att upptäcka en attack på systemet).Examples include the analyses that are required for alerting and some aspects of security monitoring (such as detecting an attack on the system). Data som krävs för de här ändamålen måste vara tillgängliga snabbt och strukturerade för effektiv bearbetning.Data that's required for these purposes must be quickly available and structured for efficient processing. I vissa fall kan det vara nödvändigt att flytta analysbearbetningen till de enskilda noderna där data lagras.In some cases, it might be necessary to move the analysis processing to the individual nodes where the data is held.

Andra former av analys är mindre brådskande och kan kräva viss beräkning och sammansättning efter att rådata har tagits emot.Other forms of analysis are less time-critical and might require some computation and aggregation after the raw data has been received. Detta kallas varm analys.This is called warm analysis. Prestandaanalys hamnar ofta i den här kategorin.Performance analysis often falls into this category. I det här fallet är det inte troligt att en isolerad, enskild prestandahändelse är statistiskt betydande.In this case, an isolated, single performance event is unlikely to be statistically significant. (Det kan bero på en plötslig insamling eller fel.) Data från en serie händelser bör ge en mer tillförlitlig bild av system prestanda.(It might be caused by a sudden spike or glitch.) The data from a series of events should provide a more reliable picture of system performance.

Varm analys kan också användas för att diagnostisera problem.Warm analysis can also be used to help diagnose health issues. En hälsohändelse bearbetas vanligtvis via het analys och kan utlösa en avisering omedelbart.A health event is typically processed through hot analysis and can raise an alert immediately. En operatör ska kunna ta reda på anledningarna till hälsohändelsen genom att kontrollera data från den varma sökvägen.An operator should be able to drill into the reasons for the health event by examining the data from the warm path. Dessa data ska innehålla information om händelserna som orsakade problemet som utlöste hälsohändelsen.This data should contain information about the events leading up to the issue that caused the health event.

Vissa typer av övervakning genererar mer långsiktiga data.Some types of monitoring generate more long-term data. Den här analysen kan utföras vid ett senare tillfälle, möjligen enligt ett fördefinierat schema.This analysis can be performed at a later date, possibly according to a predefined schedule. I vissa fall kan analysen behöva utföra komplex filtrering av stora mängder data som hämtats under en viss tidsperiod.In some cases, the analysis might need to perform complex filtering of large volumes of data captured over a period of time. Detta kallas kall analys.This is called cold analysis. Ett nyckelkrav är att data lagras på ett säkert sätt när de har hämtats.The key requirement is that the data is stored safely after it has been captured. Användarövervakning och -granskning kräver korrekt återgivning av systemets tillstånd vid regelbundna tidpunkter, men den här tillståndsinformationen behöver inte vara tillgänglig för bearbetning direkt efter att den lästs in.For example, usage monitoring and auditing require an accurate picture of the state of the system at regular points in time, but this state information does not have to be available for processing immediately after it has been gathered.

En operatör kan också tillhandahålla data för förutsägande hälsoanalys genom att använda kall analys.An operator can also use cold analysis to provide the data for predictive health analysis. Operatören kan samla in historisk information över en angiven period och använda den tillsammans med aktuell hälsoinformation (hämtad från den heta sökvägen) och upptäcka trender som kan vara orsaken till hälsoproblemet.The operator can gather historical information over a specified period and use it in conjunction with the current health data (retrieved from the hot path) to spot trends that might soon cause health issues. I sådana fall kan det vara nödvändigt att utlösa en avisering, så att åtgärder kan vidtas.In these cases, it might be necessary to raise an alert so that corrective action can be taken.

Korrelera dataCorrelating data

De data som instrumentation hämtar kan ge en ögonblicksbild av systemets tillstånd, men syftet med analyser är att göra data tillämpliga.The data that instrumentation captures can provide a snapshot of the system state, but the purpose of analysis is to make this data actionable. Exempel:For example:

  • Vad orsakade intensiv I/O-belastning på systemnivå vid en viss tid?What has caused an intense I/O loading at the system level at a specific time?
  • Är ett stort antal databasåtgärder orsaken?Is it the result of a large number of database operations?
  • Speglas det här i databasens svarstider, antalet transaktioner per sekund och programmets svarstider vid samma föreningspunkt?Is this reflected in the database response times, the number of transactions per second, and application response times at the same juncture?

I sådana fall kan en åtgärd som kan minska belastningen vara att dela upp data mellan flera servrar.If so, one remedial action that might reduce the load might be to shard the data over more servers. Dessutom kan undantag uppstå på grund av ett fel på en nivå i systemet.In addition, exceptions can arise as a result of a fault in any level of the system. Ett undantag på en nivå utlöser ofta ett annat fel på nivån ovan.An exception in one level often triggers another fault in the level above.

Därför måste du kunna korrelera de olika typerna av övervakningsdata på varje nivå, så att du får en övergripande vy av systemets tillstånd och programmen som körs.For these reasons, you need to be able to correlate the different types of monitoring data at each level to produce an overall view of the state of the system and the applications that are running on it. Du kan använda den här informationen för avgöra huruvida systemet fungerar bra eller inte samt ta reda på vad som kan göras för att förbättra kvaliteten på systemet.You can then use this information to make decisions about whether the system is functioning acceptably or not, and determine what can be done to improve the quality of the system.

Så som beskrivs i avsnittet Information korrelering av data måste du säkerställa att rå instrumentationsdata innefattar tillräckligt med information om kontext och aktivitets-ID som stöd för de korrelerade händelsernas obligatoriska sammansättningar.As described in the section Information for correlating data, you must ensure that the raw instrumentation data includes sufficient context and activity ID information to support the required aggregations for correlating events. Dessa data kan dessutom lagras i olika format och det kan vara nödvändigt att parsa informationen för att konvertera den till ett standardformat för analyser.Additionally, this data might be held in different formats, and it might be necessary to parse this information to convert it into a standardized format for analysis.

Felsökning och diagnostisera problemTroubleshooting and diagnosing issues

Diagnos kräver att det går att avgöra orsaken till det oväntade beteendet, inklusive att utföra en rotorsaksanalys.Diagnosis requires the ability to determine the cause of faults or unexpected behavior, including performing root cause analysis. Information som vanligtvis krävs inkluderar:The information that's required typically includes:

  • Utförlig information från händelseloggar och spårningar, antingen för hela systemet eller för ett specifikt undersystem under ett angivet tidsintervall.Detailed information from event logs and traces, either for the entire system or for a specified subsystem during a specified time window.
  • Slutför stackspår som uppstår på grund av undantag och fel på någon angiven nivå inuti systemet eller i ett specifikt undersystem under en angiven period.Complete stack traces resulting from exceptions and faults of any specified level that occur within the system or a specified subsystem during a specified period.
  • Kraschdumpar för alla misslyckade processer antingen var som helst i systemet eller för ett angivet undersystem under ett angivet tidsintervall.Crash dumps for any failed processes either anywhere in the system or for a specified subsystem during a specified time window.
  • Aktivitetsloggar som registrerar åtgärderna som utförs av antingen alla användare eller för utvalda användare under en angiven period.Activity logs recording the operations that are performed either by all users or for selected users during a specified period.

Att analysera data för felsökningssyften kräver ofta djup teknisk förståelse för systemets arkitektur och de olika komponenterna som utgör lösningen.Analyzing data for troubleshooting purposes often requires a deep technical understanding of the system architecture and the various components that compose the solution. Därför krävs ofta en hög nivå av manuella åtgärder för att tolka data, fastställa orsaken till problemen och rekommendera en lämplig åtgärdsstrategi.As a result, a large degree of manual intervention is often required to interpret the data, establish the cause of problems, and recommend an appropriate strategy to correct them. Det kan vara bra att spara en kopia av den här informationen i sitt ursprungliga format och göra den tillgänglig för kall analys av en expert.It might be appropriate simply to store a copy of this information in its original format and make it available for cold analysis by an expert.

Visualisera data och utlösa aviseringarVisualizing data and raising alerts

En viktig del av alla övervakningssystem är möjligheten att presentera data så att en operatör snabbt kan upptäcka trender eller problem.An important aspect of any monitoring system is the ability to present the data in such a way that an operator can quickly spot any trends or problems. Möjlighet att snabbt kunna informera en operatör när en betydande händelse som kan kräva åtgärder inträffar är också betydande.Also important is the ability to quickly inform an operator if a significant event has occurred that might require attention.

Datapresentation kan ha flera former, inklusive visualisering med hjälp av instrumentpaneler, aviseringar och rapportering.Data presentation can take several forms, including visualization by using dashboards, alerting, and reporting.

Visualisering med hjälp av instrumentpanelerVisualization by using dashboards

Det vanligaste sättet att visualisera data är att använda instrumentpaneler som kan visa information som en serie diagram, tabeller och eller någon annan bild.The most common way to visualize data is to use dashboards that can display information as a series of charts, graphs, or some other illustration. Objekten kan parameteriseras och en analytiker ska kunna välja viktiga parametrar (t.ex tidsperiod) för en specifik situation.These items can be parameterized, and an analyst should be able to select the important parameters (such as the time period) for any specific situation.

Instrumentpaneler kan ordnas hierarkiskt.Dashboards can be organized hierarchically. Översta instrumentpanelerna kan ge en övergripande vy av varje aspekt av systemet, men gör det möjligt för en operatör att öka informationens detaljnivå.Top-level dashboards can give an overall view of each aspect of the system but enable an operator to drill down to the details. En instrumentpanel som förmedlar övergripande disk-I/O för systemet bör exempelvis tillåta att en analytiker visar I/O-hastighet för varje enskild disk för att säkerställa huruvida en eller flera specifika enheter svarar för en oproportionerlig mängd eller trafik.For example, a dashboard that depicts the overall disk I/O for the system should allow an analyst to view the I/O rates for each individual disk to ascertain whether one or more specific devices account for a disproportionate volume of traffic. Helst ska instrumentpanelen också visa relaterad information, till exempel källan för varje begärande (användare eller aktivitet) som genererar den här I/O.Ideally, the dashboard should also display related information, such as the source of each request (the user or activity) that's generating this I/O. Den här informationen kan sedan användas till att avgöra huruvida (och hur) belastning ska spridas ut jämnare över enheten, och huruvida systemet kan prestera bättre om fler enheter läggs till.This information can then be used to determine whether (and how) to spread the load more evenly across devices, and whether the system would perform better if more devices were added.

En instrumentpanel kan också använda färgkodning eller andra visuella tips som anger värden som verkar vara avvikande eller som är utanför ett förväntat intervall.A dashboard might also use color-coding or some other visual cues to indicate values that appear anomalous or that are outside an expected range. Från föregående exempel:Using the previous example:

  • En disk med en I/O-hastighet som närmar sig sin maximala kapacitet under en längre tid (en het disk) kan markeras i rött.A disk with an I/O rate that's approaching its maximum capacity over an extended period (a hot disk) can be highlighted in red.
  • En disk med en I/O-hastighet som körs regelbundet på sin maxgräns under korta perioder (en varm disk) kan markeras i gult.A disk with an I/O rate that periodically runs at its maximum limit over short periods (a warm disk) can be highlighted in yellow.
  • En disk som visar normal användning kan visas i grönt.A disk that's exhibiting normal usage can be displayed in green.

Observera att för ett instrumentpanelssystem ska fungera effektivt måste det ha rådata att arbeta med.Note that for a dashboard system to work effectively, it must have the raw data to work with. Om du skapar ett eget instrumentpanelssystem eller använder en instrumentpanel som utvecklats av någon annan organisation ska du vara medveten om vilka instrumentationsdata du behöver hämta, vid vilka kornighetsnivåer och hur de bör formateras så att instrumentpanelen kan förbruka dem.If you are building your own dashboard system, or using a dashboard developed by another organization, you must understand which instrumentation data you need to collect, at what levels of granularity, and how it should be formatted for the dashboard to consume.

En bra instrumentpanel visar inte bara information, utan tillåter också att analytiker ställer ad hoc-frågor om informationen.A good dashboard does not only display information, it also enables an analyst to pose ad hoc questions about that information. Vissa system har hanteringsverktyg som en operatör kan utföra de här uppgifterna och utforska underliggande data med.Some systems provide management tools that an operator can use to perform these tasks and explore the underlying data. Beroende på vilken lagringsplats som används till att lagra information kan det också vara möjligt att skicka frågedata direkt eller importera dem till verktygen som Microsoft Excel-ark för ytterligare analys och rapportering.Alternatively, depending on the repository that's used to hold this information, it might be possible to query this data directly, or import it into tools such as Microsoft Excel for further analysis and reporting.

Anteckning

Du bör begränsa åtkomsten till instrumentpanelen till auktoriserad personal, eftersom den här informationen kan vara kommersiellt känslig.You should restrict access to dashboards to authorized personnel, because this information might be commercially sensitive. Du bör också skydda underliggande data för instrumentpaneler, så att användare inte kan ändra dem.You should also protect the underlying data for dashboards to prevent users from changing it.

Skicka aviseringarRaising alerts

Aviseringar är analyseringsprocessen för övervakning och instrumentationsdata samt generering av aviseringar om en betydande händelse upptäcks.Alerting is the process of analyzing the monitoring and instrumentation data and generating a notification if a significant event is detected.

Med hjälp av aviseringar kan du säkerställa att systemet förblir felfritt, dynamiskt och säkert.Alerting helps ensure that the system remains healthy, responsive, and secure. En viktig del av ett system är att garantera användarna prestanda, tillgänglighet och sekretess då data kan behöva aktiveras omedelbart.It's an important part of any system that makes performance, availability, and privacy guarantees to the users where the data might need to be acted on immediately. En operatör kan behöva meddelas om händelsen som utlöste aviseringen.An operator might need to be notified of the event that triggered the alert. Aviseringar kan också användas till att anropa systemfunktioner, till exempel autoskalning.Alerting can also be used to invoke system functions such as autoscaling.

Aviseringar beror vanligtvis på följande instrumentationsdata:Alerting usually depends on the following instrumentation data:

  • Säkerhets händelser.Security events. Om händelseloggen visar att autentisering och/eller auktorisering misslyckats upprepade gånger kan det innebära att systemet är under attack och en operatör bör informeras.If the event logs indicate that repeated authentication and/or authorization failures are occurring, the system might be under attack and an operator should be informed.
  • Prestanda mått.Performance metrics. Systemet måste snabbt svara om ett visst prestandamått överskrider ett angivet tröskelvärde.The system must quickly respond if a particular performance metric exceeds a specified threshold.
  • Tillgänglighets information.Availability information. Om ett fel upptäcks kan det vara nödvändigt att snabbt starta om ett eller flera undersystem eller växla till en säkerhetskopieringsresurs.If a fault is detected, it might be necessary to quickly restart one or more subsystems, or fail over to a backup resource. Upprepade fel i ett undersystem kan betyda att allvarligare fel finns.Repeated faults in a subsystem might indicate more serious concerns.

Operatörer kan ta emot aviseringsinformation via flera leveranskanaler, till exempel e-postmeddelande, sökarenhet eller ett SMS.Operators might receive alert information by using many delivery channels such as email, a pager device, or an SMS text message. En avisering kan också inkludera en indikation på hur allvarlig en situation är.An alert might also include an indication of how critical a situation is. Många aviseringssystem har stöd för prenumerationsgrupper och alla operatörer som är medlemmar i samma grupp kan få samma uppsättning aviseringar.Many alerting systems support subscriber groups, and all operators who are members of the same group can receive the same set of alerts.

Ett aviseringssystem ska anpassas och lämpliga värden från underliggande instrumentationsdata kan anges som parametrar.An alerting system should be customizable, and the appropriate values from the underlying instrumentation data can be provided as parameters. Med den här metoden kan en operatör filtrera data och fokusera på de tröskelvärden eller kombinationsvärden som är av intresse.This approach enables an operator to filter data and focus on those thresholds or combinations of values that are of interest. Observera att i vissa fall kan råa instrumentationsdata skickas till aviseringssystemet.Note that in some cases, the raw instrumentation data can be provided to the alerting system. I vissa situationer kan det vara mer effektivt att ange aggregerade data.In other situations, it might be more appropriate to supply aggregated data. (Till exempel kan en avisering aktiveras om processoranvändningen för en nod har överskridit 90 procent under de senaste 10 minuterna).(For example, an alert can be triggered if the CPU utilization for a node has exceeded 90 percent over the last 10 minutes). Informationen i aviseringssystemet bör innefatta all nödvändig information om sammanfattning och kontext.The details provided to the alerting system should also include any appropriate summary and context information. Dessa data kan minska risken för att falsk-positiva händelser utlöser en avisering.This data can help reduce the possibility that false-positive events will trip an alert.

RapporteringReporting

Rapportering används till att generera en översiktlig vy av systemet.Reporting is used to generate an overall view of the system. Förutom den aktuella informationen kan detta innefatta historiska data.It might incorporate historical data in addition to current information. Själva rapporteringskraven är indelade i två kategorier: driftsrapportering och säkerhetsrapportering.Reporting requirements themselves fall into two broad categories: operational reporting and security reporting.

Driftsrapportering omfattar vanligtvis följande aspekter:Operational reporting typically includes the following aspects:

  • Aggregera statistik som du kan använda för att förstå resursutnyttjande för det övergripande systemet eller angivna under system under en angiven tids period.Aggregating statistics that you can use to understand resource utilization of the overall system or specified subsystems during a specified time window.
  • Identifiera trender i resursanvändningen för det övergripande systemet eller angivna under system under en angiven period.Identifying trends in resource usage for the overall system or specified subsystems during a specified period.
  • Övervakning av undantag som har inträffat i systemet eller i angivna under system under en angiven period.Monitoring the exceptions that have occurred throughout the system or in specified subsystems during a specified period.
  • Att fastställa effektiviteten för programmet med avseende på de distribuerade resurserna och att förstå om mängden resurser (och deras associerade kostnader) kan minskas utan att prestanda påverkas i onödan.Determining the efficiency of the application in terms of the deployed resources, and understanding whether the volume of resources (and their associated cost) can be reduced without affecting performance unnecessarily.

Säkerhetsrapportering innebär spårning av kundens systemanvändning.Security reporting is concerned with tracking customers' use of the system. Det kan omfatta:It can include:

  • Granska användar åtgärder.Auditing user operations. Det här kräver att enskilda begäranden som vardera användare utför registreras tillsammans med datum och tid.This requires recording the individual requests that each user performs, together with dates and times. Data bör struktureras så att en administratör snabbt kan återskapa åtgärdssekvenser som användare utför under en angiven period.The data should be structured to enable an administrator to quickly reconstruct the sequence of operations that a user performs over a specified period.
  • Spårar resurs användning per användare.Tracking resource use by user. Det är obligatoriskt att registrera hur ett begärande om en användare använder de olika resurserna som utgör systemet och hur länge.This requires recording how each request for a user accesses the various resources that compose the system, and for how long. En administratör måste kunna använda dessa data till att generera en användarrapport under en angiven period, möjligtvis för faktureringssyften.An administrator must be able to use this data to generate a utilization report by user over a specified period, possibly for billing purposes.

Ofta kan batchprocesser generera rapporter enligt ett definierat schema.In many cases, batch processes can generate reports according to a defined schedule. (Svars tid är normalt ett problem.) Men de bör också vara tillgängliga för generering av ad hoc-basis vid behov.(Latency is not normally an issue.) But they should also be available for generation on an ad hoc basis if needed. Om du exempelvis lagrar data i en relationsdatabas, som Azure SQL Database, kan du extrahera och formatera data samt presentera dem som en uppsättning rapporter med hjälp av ett verktyg som SQL Server Reporting Services.As an example, if you are storing data in a relational database such as Azure SQL Database, you can use a tool such as SQL Server Reporting Services to extract and format data and present it as a set of reports.

  • I Autoscaling guidance (Vägledning för automatisk skalning) beskrivs hur du minskar hanteringen av merarbete genom att minska behovet av att en operatör regelbundet övervakar systemets prestanda och tar beslut om att lägga till eller ta bort resurser.Autoscaling guidance describes how to decrease management overhead by reducing the need for an operator to continually monitor the performance of a system and make decisions about adding or removing resources.
  • Övervaknings mönster för hälso slut punkt beskriver hur du implementerar funktions kontroller i ett program som externa verktyg kan komma åt via exponerade slut punkter med jämna mellanrum.Health Endpoint Monitoring pattern describes how to implement functional checks within an application that external tools can access through exposed endpoints at regular intervals.
  • Mönster för prioritets kön visar hur du prioriterar köade meddelanden så att brådskande begär Anden tas emot och kan bearbetas före färre brådskande meddelanden.Priority Queue pattern shows how to prioritize queued messages so that urgent requests are received and can be processed before less urgent messages.

Nästa stegNext steps