Ajánlott eljárások a felhőalapú alkalmazások figyeléséhezBest practices for monitoring cloud applications

A felhőben futó elosztott alkalmazások és szolgáltatások jellegükből adódóan összetett szoftverek, amelyek számos mozgó részből tevődnek össze.Distributed applications and services running in the cloud are, by their nature, complex pieces of software that comprise many moving parts. Éles környezetben fontos nyomon követni, hogy a felhasználók miként használják a rendszerét, nyomon követni az erőforrások kihasználtságát, és általában figyelik a rendszer állapotát és teljesítményét.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. Ezeknek a diagnosztikai információknak a segítségével észlelheti és javíthatja a problémákat, valamint felderítheti a potenciális problémákat, és megelőzheti azok bekövetkezését.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.

Monitorozási és diagnosztikai forgatókönyvekMonitoring and diagnostics scenarios

A monitorozás segítségével betekintést nyerhet abba, hogy mennyire jól működik a rendszer.You can use monitoring to gain an insight into how well a system is functioning. A monitorozás kritikus szerepet játszik a szolgáltatásminőségi célok elérésében.Monitoring is a crucial part of maintaining quality-of-service targets. Általános forgatókönyvek a monitorozási adatok gyűjtésére:Common scenarios for collecting monitoring data include:

  • A rendszer megfelelő állapotának biztosítása.Ensuring that the system remains healthy.
  • A rendszer és összetevői rendelkezésre állásának nyomon követése.Tracking the availability of the system and its component elements.
  • A megfelelő teljesítmény fenntartása, hogy a rendszer feldolgozási képessége ne romoljon le váratlanul a munkamennyiség növekedésével.Maintaining performance to ensure that the throughput of the system does not degrade unexpectedly as the volume of work increases.
  • Annak szavatolása, hogy a rendszer megfeleljen az ügyfelekkel kötött szolgáltatásiszint-szerződéseknek (service-level agreement, SLA).Guaranteeing that the system meets any service-level agreements (SLAs) established with customers.
  • A rendszer, a felhasználók és a felhasználói adatok védelmének és biztonságának biztosítása.Protecting the privacy and security of the system, users, and their data.
  • A naplózási és szabályozási céllal végzett műveletek nyomon követése.Tracking the operations that are performed for auditing or regulatory purposes.
  • A rendszer mindennapos használatának nyomon követése, és a trendek észlelése, amelyek megfelelő ellenintézkedések hiányában problémákat okozhatnak.Monitoring the day-to-day usage of the system and spotting trends that might lead to problems if they're not addressed.
  • A felmerülő hibák nyomon követése a kezdeti jelentéstől a lehetséges okok elemzéséig, javításig, a hibákból fakadó szoftverfrissítésekig és üzembe helyezésig.Tracking issues that occur, from initial report through to analysis of possible causes, rectification, consequent software updates, and deployment.
  • A műveletek nyomon követése, és a szoftverkiadások hibáinak elhárítása.Tracing operations and debugging software releases.

Megjegyzés

A fenti lista nem tekintendő átfogónak.This list is not intended to be comprehensive. A dokumentum ezekre a forgatókönyvekre, mint a leggyakoribb monitorozási helyzetekre összpontosít.This document focuses on these scenarios as the most common situations for performing monitoring. Természetesen lehetnek más forgatókönyvek is, amelyek kevésé gyakoriak, vagy csak az adott környezetre jellemzőek.There might be others that are less common or are specific to your environment.

Az alábbi szakaszokban részletesebben tárgyaljuk ezeket a forgatókönyveket.The following sections describe these scenarios in more detail. Az egyes forgatókönyvekkel kapcsolatos információkat az alábbi formában ismertetjük:The information for each scenario is discussed in the following format:

  1. A forgatókönyv rövid áttekintése.A brief overview of the scenario.
  2. A forgatókönyv jellemző követelményei.The typical requirements of this scenario.
  3. A forgatókönyv támogatásához szükséges nyers rendszerállapot-adatok és az információk lehetséges forrásai.The raw instrumentation data that's required to support the scenario, and possible sources of this information.
  4. A nyers adatok elemzése és kombinálása értelmes diagnosztikai információk létrehozásához.How this raw data can be analyzed and combined to generate meaningful diagnostic information.

ÁllapotfigyelésHealth monitoring

A rendszer állapota akkor megfelelő, ha a rendszer fut, és képes kéréseket feldolgozni.A system is healthy if it is running and capable of processing requests. Az állapotmonitorozás célja, hogy egy pillanatképet készítsen a rendszer aktuális állapotáról, amely alapján ellenőrizheti, hogy a rendszer minden összetevője a várt módon működik-e.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.

Az állapotmonitorozásra vonatkozó követelményekRequirements for health monitoring

Az operátoroknak gyorsan (pár másodpercen belül) értesülnie kell, ha a rendszer bármely részének működése nem megfelelőnek tekinthető.An operator should be alerted quickly (within a matter of seconds) if any part of the system is deemed to be unhealthy. Az operátornak meg kell tudnia állapítani, hogy a rendszer mely részei működnek megfelelően, és mely részekben tapasztalhatók problémák.The operator should be able to ascertain which parts of the system are functioning normally, and which parts are experiencing problems. A rendszerállapot jelzőlámpás megoldással jeleníthető meg:System health can be highlighted through a traffic-light system:

  • Vörös jelzi a meghibásodást (a rendszer leállt).Red for unhealthy (the system has stopped)
  • Sárga jelzi a részleges meghibásodást (a rendszer kevesebb funkciót biztosítva fut).Yellow for partially healthy (the system is running with reduced functionality)
  • Zöld jelzi a teljesen kifogástalan működést.Green for completely healthy

Az átfogó állapotmonitorozási rendszer segítségével az operátor részletesen elemezheti a rendszer állapotát egészen az alrendszerek és az összetevők állapotáig.A comprehensive health-monitoring system enables an operator to drill down through the system to view the health status of subsystems and components. Ha például a rendszer általános állapota részlegesen megfelelőként jelenik meg, az operátornak képesnek kell lennie a nagyításra, és annak megállapítására, hogy épp melyik funkció nem érhető el.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.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

Az állapotmonitorozás támogatásához szükséges nyers adatok a következők eredményeként hozhatók létre:The raw data that's required to support health monitoring can be generated as a result of:

  • A felhasználói kérések végrehajtásának nyomon követése.Tracing execution of user requests. Ezeknek az információknak a segítségével határozható meg, hogy mely kérések voltak sikeresek és melyek nem, és hogy mennyi ideig tart az egyes kérések végrehajtása.This information can be used to determine which requests have succeeded, which have failed, and how long each request takes.
  • Szintetikus felhasználómonitorozás.Synthetic user monitoring. Ez a folyamat a felhasználó által végrehajtott lépéseket szimulálja, és előre meghatározott lépések sorát követi.This process simulates the steps performed by a user and follows a predefined series of steps. Az egyes lépések eredményét rögzíteni kell.The results of each step should be captured.
  • Kivételek, hibák és figyelmeztetések naplózása.Logging exceptions, faults, and warnings. Ezek az információk az alkalmazás kódjába ágyazott nyomkövetési utasítások eredményeként, valamint a rendszer által hivatkozott szolgáltatások eseménynaplóiból lekért adatok alapján rögzíthetők.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.
  • A rendszer által használt külső szolgáltatások állapotának monitorozása.Monitoring the health of any third-party services that the system uses. Az ilyen monitorozás során szükség lehet az érintett szolgáltatások által biztosított állapotadatok lekérésére és elemzésére.This monitoring might require retrieving and parsing health data that these services supply. Ezek az adatok számos különféle formátumban fordulhatnak elő.This information might take a variety of formats.
  • Végpont-monitorozás.Endpoint monitoring. Ezt a mechanizmust „A rendelkezésre állás monitorozása” című szakasz ismerteti részletesebben.This mechanism is described in more detail in the "Availability monitoring" section.
  • Környezeti teljesítményadatok gyűjtése, például a háttérbeli processzorhasználatra vagy I/O-tevékenységekre (beleértve a hálózati tevékenységeket is) vonatkozóan.Collecting ambient performance information, such as background CPU utilization or I/O (including network) activity.

Állapotadatok elemzéseAnalyzing health data

Az állapotmonitorozás elsődleges célja annak gyors jelzése, hogy a rendszer fut-e.The primary focus of health monitoring is to quickly indicate whether the system is running. A közvetlen adatok azonnali elemzése riasztást válthat ki, ha egy kritikus összetevő állapotát a monitorozás nem megfelelőnek ítéli.Hot analysis of the immediate data can trigger an alert if a critical component is detected as unhealthy. (Nem válaszol egy egymást követő pingelésre, például:.) A kezelő ezután elvégezheti a megfelelő javítási műveleteket.(It fails to respond to a consecutive series of pings, for example.) The operator can then take the appropriate corrective action.

A fejlettebb rendszerek előrejelzési elemmel is rendelkezhetnek, amelyek a legutóbbi és az aktuális számítási feladatok hideg elemzése alapján működnek.A more advanced system might include a predictive element that performs a cold analysis over recent and current workloads. A hideg elemzés képes észlelni a tendenciákat, és meghatározni, hogy a rendszer várhatóan megfelelő állapotú marad-e, és hogy van-e szüksége további erőforrásokra.A cold analysis can spot trends and determine whether the system is likely to remain healthy or whether the system will need additional resources. Az előrejelzési elemnek kritikus teljesítménymutatók alapján kell működnie, például:This predictive element should be based on critical performance metrics, such as:

  • Az egyes szolgáltatásokra vagy alrendszerekre irányuló kérések mennyisége.The rate of requests directed at each service or subsystem.
  • Az ilyen kérések válaszideje.The response times of these requests.
  • Az egyes szolgáltatásokba be- és onnan kilépő adatok mennyisége.The volume of data flowing into and out of each service.

Ha valamelyik metrika értéke meghaladja a meghatározott küszöbértéket, a rendszer riasztást küldhet, hogy az operátor vagy az automatikus skálázás (ha van) megtehesse a rendszer megfelelő állapotának fenntartásához szükséges megelőző intézkedéseket.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. Ilyen intézkedések lehetnek az erőforrások hozzáadása, egy vagy több meghibásodott szolgáltatás újraindítása, vagy az alacsonyabb prioritású kérések szabályozása.These actions might involve adding resources, restarting one or more services that are failing, or applying throttling to lower-priority requests.

A rendelkezésre állás monitorozásaAvailability monitoring

Egy valóban kifogástalan állapotú rendszerhez elengedhetetlen, hogy a rendszert alkotó összetevők és alrendszerek rendelkezésre álljanak.A truly healthy system requires that the components and subsystems that compose the system are available. A rendelkezésre állás monitorozása szorosan kapcsolódik az állapotmonitorozáshoz.Availability monitoring is closely related to health monitoring. Amíg azonban az állapotmonitorozás a rendszer aktuális állapotának azonnali helyzetét jeleníti meg, a rendelkezésre állás monitorozása a rendszer és a rendszer összetevőinek rendelkezésre állását követi nyomon, és statisztikákat készít a rendszer üzemidejére vonatkozóan.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.

Számos rendszerben bizonyos összetevők (például az adatbázisok) beépített redundanciával vannak konfigurálva, így gyors feladatátvételt tesznek lehetővé súlyos hibák vagy a kapcsolat megszakadása esetén.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. Ideális esetben a felhasználók nem is tudhatják, hogy ilyen hiba történt.Ideally, users should not be aware that such a failure has occurred. A rendelkezésre állás monitorozása szempontjából azonban a lehető legtöbb információt kell gyűjteni az ilyen hibákkal kapcsolatban, hogy megállapíthatók legyenek az okok, és végre lehessen hajtani a korrekciós műveleteket a hibák ismételt előfordulásának elkerülésére.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.

A rendelkezésre állás nyomon követéséhez szükséges adatok számos alacsonyabb szintű tényezőtől függhetnek.The data that's required to track availability might depend on a number of lower-level factors. Ezeknek a tényezőknek jelentős része az adott alkalmazásra, rendszerre vagy környezetre lehet jellemző.Many of these factors might be specific to the application, system, and environment. A hatékony monitorozási rendszerek az ezeknek az alacsony szintű tényezőknek megfelelő rendelkezésreállási adatokat rögzítik, majd azokat összesítve átfogó képet biztosítanak a rendszerről.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. Egy e-kereskedelmi rendszerben például az ügyfelek általi rendelést lehetővé tevő üzleti funkció függhet a megrendelések adatait tároló adattártól, valamint a megrendelések kifizetésére vonatkozó pénzügyi tranzakciókat kezelő fizetési rendszertől.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. A rendszer rendelési részének rendelkezésre állása ezért az adattár és a fizetési alrendszer rendelkezésre állásának függvénye.The availability of the order-placement part of the system is therefore a function of the availability of the repository and the payment subsystem.

A rendelkezésre állás monitorozására vonatkozó követelményekRequirements for availability monitoring

Az operátornak meg kell tudnia tekinteni az egyes rendszerek és alrendszerek rendelkezésreállási előzményadatait is, és ezeknek az információknak a segítségével ki kell tudniuk mutatni a tendenciákat, amelyek egy vagy több alrendszer rendszeres meghibásodását okozhatják.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. (A szolgáltatások egy olyan adott napszakban kezdenek meghibásodni, amely a feldolgozási csúcsidőszaknak felel meg?)(Do services start to fail at a particular time of day that corresponds to peak processing hours?)

A monitorozási megoldásoknak azonnali és előzményadatokat tartalmazó nézeteket is biztosítaniuk kell az egyes alrendszerek rendelkezésre állásával vagy rendelkezésre nem állásával kapcsolatban.A monitoring solution should provide an immediate and historical view of the availability or unavailability of each subsystem. Emellett képesnek kell lennie gyorsan riasztani az operátort, amikor egy vagy több szolgáltatás meghibásodik, vagy ha a felhasználók nem érik el a szolgáltatásokat.It should also be capable of quickly alerting an operator when one or more services fail or when users can't connect to services. Ehhez nem csupán az egyes szolgáltatások monitorozása szükséges, hanem a felhasználók által végrehajtott műveletek vizsgálata is, ha ezek a műveletek meghiúsulnak, amikor kommunikálni próbálnak a szolgáltatással.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. A csatlakozási hibák bizonyos mértékig normálisnak tekinthetők, és átmeneti hibák miatt léphetnek fel.To some extent, a degree of connectivity failure is normal and might be due to transient errors. Hasznos lehet azonban engedélyezni a rendszer számára, hogy riasztást küldjön egy adott alrendszerhez kapcsolódóan egy adott időszakban fellépő kapcsolathibák számáról.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.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

Az állapotmonitorozáshoz hasonlóan, a rendelkezésre állás monitorozásának a támogatásához szükséges nyers adatok is a szintetikus felhasználómonitorozás, valamint a kivételek, hibák és figyelmeztetések naplózásának az eredményeként hozhatók létre.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. A rendelkezésreállási adatok emellett végpont-monitorozásból is beszerezhetők.In addition, availability data can be obtained from performing endpoint monitoring. Az alkalmazás egy vagy több állapotvégpontot is elérhetővé tehet a rendszer egy funkcionális területe elérésének teszteléséhez.The application can expose one or more health endpoints, each testing access to a functional area within the system. A monitorozási rendszer pingelheti az egyes végpontokat egy meghatározott ütemezés szerint, és gyűjtheti ennek eredményét (sikeres vagy sikertelen).The monitoring system can ping each endpoint by following a defined schedule and collect the results (success or fail).

Az összes időtúllépést, hálózati kapcsolathibát és újrapróbált kapcsolódást rögzíteni kell.All timeouts, network connectivity failures, and connection retry attempts must be recorded. Az összes adatbélyegzőnek kell lennie.All data should be timestamped.

A rendelkezésreállási adatok elemzéseAnalyzing availability data

A rendszerállapot-adatokat összesíteni és korrelálni kell a következő elemzéstípusok támogatásához:The instrumentation data must be aggregated and correlated to support the following types of analysis:

  • A rendszer és az alrendszerek közvetlen rendelkezésre állása.The immediate availability of the system and subsystems.
  • A rendszer és az alrendszerek rendelkezésreállási hibáinak aránya.The availability failure rates of the system and subsystems. Ideális esetben az operátornak képesnek kell lennie a hibák korrelálására az adott tevékenységekkel: mi történt, amikor a rendszer meghibásodott?Ideally, an operator should be able to correlate failures with specific activities: what was happening when the system failed?
  • A rendszer vagy az alrendszerek meghibásodási arányainak előzménynézete adott időszakra vonatkozóan, valamint a rendszer terhelése (például a felhasználói kérések száma) a hiba bekövetkezésekor.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.
  • A rendszer vagy egy alrendszer rendelkezésre nem állásának okai.The reasons for unavailability of the system or any subsystems. Ilyen ok lehet például, ha a szolgáltatás nem fut, ha megszakad a kapcsolat, ha létrejön a kapcsolat, de időtúllépés történik, vagy ha létrejön a kapcsolat, de hibát ad vissza.For example, the reasons might be service not running, connectivity lost, connected but timing out, and connected but returning errors.

A szolgáltatások adott időszakra vetített százalékos rendelkezésre állását az alábbi képlettel számíthatja ki: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

Ez az SLA szempontjából hasznos.This is useful for SLA purposes. (Az SLA figyelését az útmutató későbbi részében részletesebben ismertetjük.) Az állásidő definíciója a szolgáltatástól függ.(SLA monitoring is described in more detail later in this guidance.) The definition of downtime depends on the service. A Visual Studio Team Services Build Service például azon időtartamként (halmozott percek teljes száma) határozza meg az állásidőt, ameddig a Build Service nem állt rendelkezésre.For example, Visual Studio Team Services Build Service defines downtime as the period (total accumulated minutes) during which Build Service is unavailable. Egy perc akkor tekintendő rendelkezésre nem állónak, ha az adott percben a Build Service számára küldött, ügyfél által kezdeményezett műveletek végrehajtására irányuló, egymást követő HTTP-kérések hibakódot eredményeznek vagy nem adnak vissza választ.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.

TeljesítményfigyelésPerformance monitoring

A rendszer egyre nagyobb terhelése esetén (a felhasználók mennyiségének növekedésével), a felhasználók által elért adathalmazok mérete egyre nő, és egyre valószínűbbé válik egy vagy több összetevő meghibásodása.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. Az összetevők meghibásodását gyakran a teljesítmény csökkenése előzi meg.Frequently, component failure is preceded by a decrease in performance. Ha képes észlelni az ilyen teljesítménycsökkenéseket, proaktív lépéseket tehet a helyzet orvoslására.If you're able detect such a decrease, you can take proactive steps to remedy the situation.

A rendszer teljesítménye számos tényezőtől függ.System performance depends on a number of factors. Az egyes tényezőket általában fő teljesítménymutatókkal (KPI) mérik, ilyen például az adatbázis-tranzakciók másodpercenkénti száma vagy a sikeresen kiszolgált hálózati kérések mennyisége egy adott időszakban.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. A KPI-k némelyike önálló teljesítménymutatóként érhető el, mások mérőszámok kombinációjából állnak.Some of these KPIs might be available as specific performance measures, whereas others might be derived from a combination of metrics.

Megjegyzés

A gyenge vagy a jó teljesítmény meghatározásához ismerni kell azt a teljesítményszintet, amelyen a rendszernek képesnek kell lennie üzemelni.Determining poor or good performance requires that you understand the level of performance at which the system should be capable of running. Ehhez meg kell figyelni a rendszert, miközben átlagos terhelés mellett működik, és rögzíteni kell az egyes KPI-k adatait egy időszakra vonatkozóan.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. Ez a rendszernek szimulált terhelés mellett, tesztkörnyezetben történő futtatásával, és a vonatkozó adatok gyűjtésével is járhat, mielőtt éles környezetben telepítené a rendszert.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.

Gondoskodnia kell arról, hogy a teljesítmény monitorozása ne váljon teherré a rendszer számára.You should also ensure that monitoring for performance purposes does not become a burden on the system. A teljesítménymonitorozási folyamat által gyűjtött adatok részletességi szintjét érdemes lehet dinamikusan változtathatóvá tenni.You might be able to dynamically adjust the level of detail for the data that the performance monitoring process gathers.

A teljesítmény monitorozására vonatkozó követelményekRequirements for performance monitoring

A rendszer teljesítményének vizsgálatához az operátornak általában az alábbi információkra van szüksége:To examine system performance, an operator typically needs to see information that includes:

  • A felhasználói kérések megválaszolásának sebessége.The response rates for user requests.
  • Az egyidejű felhasználói kérések száma.The number of concurrent user requests.
  • A hálózati forgalom mennyisége.The volume of network traffic.
  • Az üzleti tranzakciók teljesítésének sebessége.The rates at which business transactions are being completed.
  • A kérések átlagos feldolgozási ideje.The average processing time for requests.

Hasznos lehet olyan eszközökkel is ellátni az operátorokat, amelyek segítenek kimutatni az alábbiak közötti összefüggéseket, például:It can also be helpful to provide tools that enable an operator to help spot correlations, such as:

  • Az egyidejű felhasználók száma és a kérések késése (mennyi ideig tart egy kérés feldolgozásának a megkezdése, miután a felhasználó elküldte azt).The number of concurrent users versus request latency times (how long it takes to start processing a request after the user has sent it).
  • Az egyidejű felhasználók száma és az átlagos válaszidő (mennyi ideig tart egy kérés befejezése, miután elkezdődött annak feldolgozása).The number of concurrent users versus the average response time (how long it takes to complete a request after it has started processing).
  • A kérések mennyisége és a feldolgozási hibák száma.The volume of requests versus the number of processing errors.

Az ilyen magas szintű működési információk mellett az operátornak a rendszer egyes összetevőinek a teljesítményéről is részletes képet kell kapnia.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. Ezek az adatok általában alsó szintű teljesítményszámlálók használatával biztosíthatók, amelyek az alábbi információkat követik nyomon:This data is typically provided through low-level performance counters that track information such as:

  • Memóriahasználat.Memory utilization.
  • Szálak száma.Number of threads.
  • Processzor feldolgozási ideje.CPU processing time.
  • Kérésvárólista hossza.Request queue length.
  • Lemez vagy hálózat I/O-sebessége és -hibái.Disk or network I/O rates and errors.
  • Az írt vagy olvasott bájtok száma.Number of bytes written or read.
  • Köztes szoftverek mutatói, például az üzenetsor hossza.Middleware indicators, such as queue length.

Minden megjelenítésnek lehetővé kell tennie az operátor számára egy időtartam megadását.All visualizations should allow an operator to specify a time period. A megjelenített adatok az aktuális helyzet pillanatképe és/vagy a teljesítmény előzménynézete lehetnek.The displayed data might be a snapshot of the current situation and/or a historical view of the performance.

Az operátornak tudnia kell riasztást küldenie bármely megadott érték tetszőleges időintervallumra vonatkozó teljesítménymutatója alapján.An operator should be able to raise an alert based on any performance measure for any specified value during any specified time interval.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

A rendszerre érkező és azon áthaladó felhasználói kérések állapotának monitorozásával magas szintű teljesítményadatokat gyűjthet (átviteli sebesség, egyidejű felhasználók száma, üzleti tranzakciók száma, hibaarányok és hasonlók).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. Ehhez nyomkövetési utasításokat kell az alkalmazáskód kulcspontjain elhelyezni időzítési információkkal együtt.This involves incorporating tracing statements at key points in the application code, together with timing information. Minden hibát, kivételt és figyelmeztetést elegendő mennyiségű adattal kell rögzíteni az őket okozó kérésekkel való korrelálás érdekében.All faults, exceptions, and warnings should be captured with sufficient data for correlating them with the requests that caused them. Az Internet Information Services (IIS) naplója egy másik hasznos forrás.The Internet Information Services (IIS) log is another useful source.

Amennyiben lehetséges, az alkalmazás által használt külső rendszerek teljesítményadatait is rögzíteni kell.If possible, you should also capture performance data for any external systems that the application uses. A külső rendszerek biztosíthatnak saját teljesítményszámlálókat vagy egyéb funkciókat a teljesítményadatok lekéréséhez.These external systems might provide their own performance counters or other features for requesting performance data. Ha ez nem lehetséges, rögzítse az olyan információkat, mint a külső rendszerre felé irányuló kérések kezdési és befejezési időpontja, valamint a művelet állapota (sikeres, sikertelen vagy figyelmeztetés).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. A kérésidők méréséhez használhat például egy stopperóra jellegű módszert: a kérés indításakor indítson el egy időmérőt, a befejezésekor pedig állítsa le.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.

A rendszerek egyes összetevőinek alacsony szintű teljesítményadatai olyan funkciókon és szolgáltatásokon keresztül érhetők el, mint a Windows-teljesítményszámlálók és az 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.

Teljesítményadatok elemzéseAnalyzing performance data

Az elemzési munka nagy részét a teljesítményadatoknak a felhasználói kérés típusa és/vagy azon alrendszer vagy szolgáltatás alapján való összesítése teszi ki, amely számára az egyes kérések el lettek küldve.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. Felhasználói kérés lehet például egy cikk hozzáadása egy bevásárlókosárhoz vagy a fizetési folyamat végrehajtása egy e-kereskedelmi rendszerben.An example of a user request is adding an item to a shopping cart or performing the checkout process in an e-commerce system.

Egy másik gyakori követelmény a kiválasztott percentilisekben található teljesítményadatok összegzése.Another common requirement is summarizing performance data in selected percentiles. Az operátor például meghatározhatja a kérések 99 százalékának, a kérések 95 százalékának és a kérések 70 százalékának a válaszidejét.For example, an operator might determine the response times for 99 percent of requests, 95 percent of requests, and 70 percent of requests. Az egyes percentilisekre SLA-célok vagy más célkitűzések vonatkozhatnak.There might be SLA targets or other goals set for each percentile. A folyamatos eredményeket közel valós időben kell jelenteni, hogy észlelhetők legyenek az azonnali problémák.The ongoing results should be reported in near real time to help detect immediate issues. Az eredményeket emellett hosszabb időre vonatkozóan is összesíteni kell statisztikai célokból.The results should also be aggregated over the longer time for statistical purposes.

Amennyiben késési problémák vetnék vissza a teljesítményt, az operátornak gyorsan kell tudnia azonosítani a szűk keresztmetszet okát az egyes kérések által végrehajtott egyes lépések késésének vizsgálatával.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. A teljesítményadatoknak így lehetőséget kell biztosítaniuk az egyes lépések teljesítménymutatóinak korrelálására, hogy az adott kérésekhez lehessen kötni azokat.The performance data must therefore provide a means of correlating performance measures for each step to tie them to a specific request.

A megjelenítés követelményeitől függően érdemes lehet létrehozni és menteni egy adatkockát, amely a nyers adatok nézeteit tartalmazza.Depending on the visualization requirements, it might be useful to generate and store a data cube that contains views of the raw data. Az adatkocka lehetővé teszi a teljesítményadatok komplex ad hoc lekérdezését és elemzését.This data cube can allow complex ad hoc querying and analysis of the performance information.

A biztonság monitorozásaSecurity monitoring

A bizalmas adatokat kezelő kereskedelmi rendszerek mindegyikében meg kell valósítani egy biztonsági struktúrát.All commercial systems that include sensitive data must implement a security structure. A biztonsági mechanizmus összetettségét általában az adatok bizalmassága határozza meg.The complexity of the security mechanism is usually a function of the sensitivity of the data. A felhasználói hitelesítést igénylő rendszerekben az alábbiakat kell rögzíteni:In a system that requires users to be authenticated, you should record:

  • Az összes bejelentkezési kísérletet, függetlenül attól, hogy sikeresek vagy sikertelenek voltak.All sign-in attempts, whether they fail or succeed.
  • A által végrehajtott összes művelet — , valamint a hitelesített felhasználó által elért összes erőforrás részletei — .All operations performed by—and the details of all resources accessed by—an authenticated user.
  • A munkamenet felhasználó általi befejezésének és a felhasználó kijelentkezésének időpontja.When a user ends a session and signs out.

A monitorozás segítséget nyújthat a rendszert érő támadások észlelésében.Monitoring might be able to help detect attacks on the system. Ha például magas a sikertelen bejelentkezési kísérletek száma, az találgatásos támadásra utalhat.For example, a large number of failed sign-in attempts might indicate a brute-force attack. A kérések számának váratlan megugrása elosztott szolgáltatásmegtagadásos (DDoS-) támadás eredménye lehet.An unexpected surge in requests might be the result of a distributed denial-of-service (DDoS) attack. Fel kell készülnie arra, hogy az erőforrások mindegyikére irányuló összes kérést monitorozza azok forrásától függetlenül.You must be prepared to monitor all requests to all resources regardless of the source of these requests. A bejelentkezéshez kapcsolódó biztonsági réssel rendelkező rendszerek véletlenül elérhetővé tehetik az erőforrásokat a külvilág számára anélkül, hogy a felhasználónak ténylegesen be kellene jelentkeznie.A system that has a sign-in vulnerability might accidentally expose resources to the outside world without requiring a user to actually sign in.

A biztonság monitorozására vonatkozó követelményekRequirements for security monitoring

A biztonság monitorozásának legfontosabb szempontjait figyelembe véve, az operátornak képesnek kell lennie gyorsan:The most critical aspects of security monitoring should enable an operator to quickly:

  • észlelni a nem hitelesített entitások általi behatolási kísérleteket;Detect attempted intrusions by an unauthenticated entity.
  • azonosítani az entitások kísérleteit olyan adatokra irányuló műveletek végrehajtására, amelyekhez az entitások nem rendelkeznek hozzáféréssel;Identify attempts by entities to perform operations on data for which they have not been granted access.
  • megállapítani, ha a rendszer vagy annak egy része külső vagy belső támadás alatt áll.Determine whether the system, or some part of the system, is under attack from outside or inside. (Például egy rosszindulatú hitelesített felhasználó megpróbálja leállítani a rendszert.)(For example, a malicious authenticated user might be attempting to bring the system down.)

A követelmények támogatásához az operátornak értesítést kell kapnia, ha:To support these requirements, an operator should be notified if:

  • Egy fiók egy adott időszakon belül ismétlődő sikertelen bejelentkezési kísérleteket tesz lehetővé.One account makes repeated failed sign-in attempts within a specified period.
  • Egy hitelesített fiók többször megpróbál hozzáférni egy tiltott erőforráshoz egy adott időszakban.One authenticated account repeatedly tries to access a prohibited resource during a specified period.
  • Egy adott időszakban nagy számú nem hitelesített vagy jogosulatlan kérelem fordul elő.A large number of unauthenticated or unauthorized requests occur during a specified period.

Az operátor rendelkezésére bocsátott információknak tartalmaznia kell az egyes kérések forrásának gazdagépcímét.The information that's provided to an operator should include the host address of the source for each request. Ha egy adott címtartománnyal kapcsolatban rendszeresen merülnek fel biztonsági megsértések, ezeket a gazdagépeket érdemes lehet blokkolni.If security violations regularly arise from a particular range of addresses, these hosts might be blocked.

A rendszer biztonságának fenntartásában kulcsszerepet játszik a szokásos mintáktól eltérő műveletek gyors észlelése.A key part in maintaining the security of a system is being able to quickly detect actions that deviate from the usual pattern. A sikertelen és/vagy sikeres bejelentkezési kérések számára vonatkozó információk vizuális megjelenítésével például könnyebben észlelhető, ha szokatlan időpontban hajtanak végre nagy számú tevékenységet.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. (Például a felhasználók hajnali 3:00 órakor bejelentkeznek, és nagy számú műveletet hajtanak végre, holott a munkaidejük csak reggel 9:00 órakor kezdődik.)(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). Ezen információkkal egyszerűbben konfigurálható az időalapú automatikus skálázás is.This information can also be used to help configure time-based autoscaling. Ha például az operátor észreveszi, hogy sok felhasználó jelentkezik be rendszeresen egy adott napszakban, további hitelesítési szolgáltatásokat indíthat el a megnövekedett munkamennyiség kezelésére, majd leállíthatja a szolgáltatások a csúcsidőszak végét követően.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.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

A legtöbb elosztott rendszer esetében a biztonság mindenre kiterjedő szempont.Security is an all-encompassing aspect of most distributed systems. A kapcsolódó adatok létrehozása valószínűleg a rendszer több pontján történik.The pertinent data is likely to be generated at multiple points throughout a system. Érdemes lehet bevezetni egy biztonságiadat- és eseménykezelési (Security Information and Event Management, SIEM) megközelítést az alkalmazás, a hálózati berendezések, a kiszolgálók, a tűzfalak, a víruskereső szoftverek és az egyéb behatolásmegelőzési elemek által létrehozott eseményekből eredő, biztonsággal kapcsolatos adatok gyűjtésére.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.

A biztonság monitorozása az alkalmazás részét nem képező eszközökről származó adatokra is kiterjedhet.Security monitoring can incorporate data from tools that are not part of your application. Ezek az eszközök lehetnek a külső ügynökségek portkeresési tevékenységeit azonosító segédprogramok, vagy az alkalmazásra és az adatokra irányuló, nem hitelesített hozzáférésre tett kísérleteket észlelő hálózati szűrők.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.

Bármiről is legyen szó, az összegyűjtött adatok segítségével a rendszergazda meghatározhatja a támadás természetét, és megteheti a megfelelő ellenintézkedéseket.In all cases, the gathered data must enable an administrator to determine the nature of any attack and take the appropriate countermeasures.

Biztonsággal kapcsolatos adatok elemzéseAnalyzing security data

A biztonság monitorozásának egyik jellemzője, hogy az adatok rengeteg különböző forrásból származhatnak.A feature of security monitoring is the variety of sources from which the data arises. A különböző formátumok és részletességi szintek miatt gyakran szükség van a rögzített adatok összetett elemzésére és egy összefüggő információszállá való összefűzésükre.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. A legegyszerűbb esetektől (például a nagyszámú sikertelen bejelentkezéstől, vagy a kritikus erőforrásokhoz való sorozatos, jogosulatlan hozzáférésre tett kísérletek észlelésétől) eltekintve előfordulhat, hogy a biztonsággal kapcsolatos adatok bonyolult automatikus feldolgozása nem lehetséges.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. Ehelyett érdemes lehet megírni ezeket az adatlapokat, de az eredeti formájában más formában is a biztonságos tárházba, hogy lehetővé váljon a szakértői manuális elemzés.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.

Az SLA monitorozásaSLA monitoring

A fizető ügyfeleket kiszolgáló számos kereskedelmi rendszer SLA-k formájában szavatolja a rendszer teljesítményét.Many commercial systems that support paying customers make guarantees about the performance of the system in the form of SLAs. Az SLA-k lényegében azt jelentik ki, hogy a rendszer képes egy meghatározott munkamennyiséget kezelni egy egyeztetett időkereten belül, a kritikus adatok elvesztése nélkül.Essentially, SLAs state that the system can handle a defined volume of work within an agreed time frame and without losing critical information. Az SLA monitorozása annak biztosítására irányul, hogy a rendszer megfelel a mérhető SLA-knak.SLA monitoring is concerned with ensuring that the system can meet measurable SLAs.

Megjegyzés

Az SLA monitorozása szorosan kapcsolódik a teljesítmény monitorozásához.SLA monitoring is closely related to performance monitoring. Amíg azonban a teljesítmény monitorozásának célja a rendszer optimális működésének biztosítása, az SLA monitorozását egy szerződéses kötelezettség szabályozza, amely meghatározza, hogy az optimális ténylegesen mit is jelent.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.

Az SLA-kat általában az alábbiak vonatkozásában határozzák meg:SLAs are often defined in terms of:

  • A rendszer általános rendelkezésre állása.Overall system availability. Előfordulhat például, hogy egy szolgáltató a rendszer 99,9%-os rendelkezésre állását szavatolja.For example, an organization might guarantee that the system will be available for 99.9 percent of the time. Ez azt jelenti, hogy a rendszer évente legfeljebb 9 órát állhat, azaz hetente körülbelül 10 percet.This equates to no more than 9 hours of downtime per year, or approximately 10 minutes a week.
  • Működési teljesítmény.Operational throughput. Ezt általában egy vagy több felső határértékkel fejezik ki, például annak szavatolásával, hogy a rendszer képes akár 100 000 egyidejű felhasználói kérés támogatására, vagy 10 000 egyidejű üzleti tranzakció kezelésére.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.
  • Működési válaszidő.Operational response time. A rendszer a kérések feldolgozásának sebességére is vállalhat kötelezettséget.The system might also make guarantees for the rate at which requests are processed. Például: az üzleti tranzakciók 99 százalékát a rendszer 2 másodpercen belül feldolgozza, és egyetlen tranzakció feldolgozása sem tart 10 másodpercnél hosszabb ideig.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.

Megjegyzés

Egyes kereskedelmi rendszerek szerződései az ügyfélszolgálatra vonatkozó SLA-kat is tartalmazhatnak.Some contracts for commercial systems might also include SLAs for customer support. Egy példa arra, hogy az összes ügyfélszolgálati kérelem öt percen belül kiváltja a választ, és az összes probléma 99%-a teljes mértékben az 1 munkanapon belül fog foglalkozni.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. A hatékony problémakövetés (a jelen szakasz egy későbbi része ismerteti) kritikus fontosságú az ezekhez hasonló SLA-k eléréséhez.Effective issue tracking (described later in this section) is key to meeting SLAs such as these.

Az SLA monitorozására vonatkozó követelményekRequirements for SLA monitoring

A legfelső szinten az operátornak egy pillantásra meg kell tudnia állapítani, hogy a rendszer teljesíti-e a megállapodásba foglalt SLA-kat vagy sem.At the highest level, an operator should be able to determine at a glance whether the system is meeting the agreed SLAs or not. Ha nem, az operátornak képesnek kell lennie részletes elemzést végezni, és megvizsgálni a mögöttes tényezőket a teljesítménycsökkenés okainak meghatározásához.And if not, the operator should be able to drill down and examine the underlying factors to determine the reasons for substandard performance.

A vizuálisan ábrázolható, jellemző magas szintű mutatók az alábbiak lehetnek:Typical high-level indicators that can be depicted visually include:

  • A hasznos üzemidő százalékos aránya.The percentage of service uptime.
  • Az alkalmazás átviteli sebessége (a másodpercenkénti sikeres tranzakciók és/vagy műveletek mennyiségében kifejezve).The application throughput (measured in terms of successful transactions and/or operations per second).
  • A sikeres/sikertelen alkalmazáskérések száma.The number of successful/failing application requests.
  • Az alkalmazás- és rendszerhibák, kivételek és figyelmeztetések száma.The number of application and system faults, exceptions, and warnings.

A mutatók mindegyikének szűrhetőnek kell lennie adott időszak alapján.All of these indicators should be capable of being filtered by a specified period of time.

A felhőalkalmazások vélhetően több alrendszerből és összetevőből állnak.A cloud application will likely comprise a number of subsystems and components. Az operátornak az egyes felső szintű mutatókat kiválasztva meg kell tudnia tekinteni, hogy a mutató hogyan tevődik össze a mögöttes elemek állapota alapján.An operator should be able to select a high-level indicator and see how it's composed from the health of the underlying elements. Ha például a teljes rendszer üzemideje egy elfogadható érték alá csökken, az operátornak képesnek kell lennie a nagyításra, és annak megállapítására, hogy mely elemek járultak hozzá a hibához.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.

Megjegyzés

A rendszer üzemidejét gondosan kell meghatározni.System uptime needs to be defined carefully. A maximális rendelkezésre állást redundancia használatával biztosító rendszerekben az elemek egyes példányai meghibásodhatnak ugyan, a rendszer azonban továbbra is működőképes marad.In a system that uses redundancy to ensure maximum availability, individual instances of elements might fail, but the system can remain functional. A rendszer az állapotmonitorozás által kimutatott üzemidejének az egyes elemek összesített üzemidejét kell mutatnia, és nem feltétlenül azt, hogy a rendszer ténylegesen leállt-e.System uptime as presented by health monitoring should indicate the aggregate uptime of each element and not necessarily whether the system has actually halted. Emellett a hibák elkülöníthetők.Additionally, failures might be isolated. Így ha egy adott alrendszer nem is áll rendelkezésre, a rendszer többi része továbbra is rendelkezésre állhat, jóllehet kevesebb funkciót biztosítva.So even if a specific system is unavailable, the remainder of the system might remain available, although with decreased functionality. (Egy e-kereskedelmi rendszerben például az egyik alrendszer hibája miatt a vevő esetleg nem küldhet megrendelést, azonban a termékkatalógust továbbra is böngészheti.)(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.)

Riasztási célokból a rendszernek képesnek kell lennie eseményt létrehozni, ha a felső szintű mutatók bármelyike meghalad egy adott küszöbértéket.For alerting purposes, the system should be able to raise an event if any of the high-level indicators exceed a specified threshold. A felső szintű mutatókat alkotó különféle összetevők alacsonyabb szintű adatainak környezetfüggő adatként elérhetőnek kell lenniük a riasztást létrehozó rendszer számára.The lower-level details of the various factors that compose the high-level indicator should be available as contextual data to the alerting system.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

Az SLA monitorozásának támogatásához szükséges nyers adatok hasonlóak a teljesítmény, és bizonyos szempontokból az állapot és a rendelkezésre állás monitorozásának nyers adataihoz.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. (További részletekért tekintse meg ezeket a részeket.) Ezeket az adatmennyiségeket a következővel rögzítheti:(See those sections for more details.) You can capture this data by:

  • A végpontok monitorozása.Performing endpoint monitoring.
  • Kivételek, hibák és figyelmeztetések naplózása.Logging exceptions, faults, and warnings.
  • A felhasználói kérések végrehajtásának nyomon követése.Tracing the execution of user requests.
  • A rendszer által használt külső szolgáltatások rendelkezésre állásának monitorozása.Monitoring the availability of any third-party services that the system uses.
  • Teljesítmény-mérőszámok és -számlálók használata.Using performance metrics and counters.

Az összes adatértéknek időzítettnek és időbélyegnek kell lennie.All data must be timed and timestamped.

Az SLA-adatok elemzéseAnalyzing SLA data

A rendszerállapot-adatokat összesíteni kell a rendszer átfogó teljesítményének megjelenítéséhez.The instrumentation data must be aggregated to generate a picture of the overall performance of the system. Az összesített adatoknak a részletes elemzést is lehetővé kell tenniük a mögöttes alrendszerek teljesítményének vizsgálatához.Aggregated data must also support drill-down to enable examination of the performance of the underlying subsystems. Például az alábbiakra kell képesnek lennie:For example, you should be able to:

  • Az adott időszakban kezdeményezett felhasználói kérések teljes számának megállapítása, valamint a sikeres és sikertelen kérések arányának meghatározása.Calculate the total number of user requests during a specified period and determine the success and failure rate of these requests.
  • Átfogó kép kialakítása a rendszer válaszidejéről a felhasználói kérések válaszidejének összesítésével.Combine the response times of user requests to generate an overall view of system response times.
  • A felhasználói kérések állapotnak elemzése a kérések átfogó válaszidejének a kérést alkotó egyes munkaelemek válaszidejére való lebontásához.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.
  • A rendszer átfogó rendelkezésre állásának meghatározása az üzemidőt százalékos arányként kifejezve egy adott időszakra vonatkozóan.Determine the overall availability of the system as a percentage of uptime for any specific period.
  • A rendszer egyes összetevőinek és szolgáltatásainak az idő százalékában kifejezett rendelkezésre állásának elemzése.Analyze the percentage time availability of the individual components and services in the system. Ehhez esetleg szükség lehet a külső szolgáltatások által létrehozott naplók elemzésére.This might involve parsing logs that third-party services have generated.

Számos kereskedelmi rendszernek jelentenie kell a tényleges teljesítményadatokat a megállapodásban foglalt SLA-k alapján egy adott időtartamra, általában egy hónapra vonatkozóan.Many commercial systems are required to report real performance figures against agreed SLAs for a specified period, typically a month. Az információk segítségével számítható ki az ügyfeleket illető jóváírás vagy egyéb visszatérítés, ha az SLA-k nem teljesültek az adott időszakban.This information can be used to calculate credits or other forms of repayments for customers if the SLAs are not met during that period. Az egyes szolgáltatások rendelkezésre állását A rendelkezésreállási adatok elemzése című szakaszban bemutatott módszerrel számíthatja ki.You can calculate availability for a service by using the technique described in the section Analyzing availability data.

A vállalatok a szolgáltatások meghibásodását okozó incidensek számát és természetét is követhetik belső használatra.For internal purposes, an organization might also track the number and nature of incidents that caused services to fail. A problémák gyors megoldásának vagy teljes kiküszöbölésének elsajátításával csökkenthető az állásidő, és teljesíthetők az SLA-k.Learning how to resolve these issues quickly, or eliminate them completely, will help to reduce downtime and meet SLAs.

NaplózásAuditing

Az alkalmazás jellegétől függően a törvényi vagy egyéb jogi rendelkezések megszabhatnak a felhasználói műveletek naplózására és az összes adatelérés rögzítésére vonatkozó követelményeket.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. A naplózás az ügyfeleket az egyes kérésekhez kötő bizonyítékot biztosíthat.Auditing can provide evidence that links customers to specific requests. A letagadhatatlanság fontos tényező számos e-üzleti rendszer számára, hogy megőrizze a bizalmat az ügyfél és az alkalmazásért vagy szolgáltatásért felelős szervezet között.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.

A naplózásra vonatkozó követelményekRequirements for auditing

Az elemzőknek nyomon kell tudniuk követni a felhasználók által végrehajtott üzleti műveletek sorát, hogy rekonstruálhassák a felhasználók műveleteit.An analyst must be able to trace the sequence of business operations that users are performing so that you can reconstruct users' actions. Előfordulhat, hogy erre egyszerűen a nyilvántartás miatt van szükség, vagy pedig egy törvényszéki vizsgálat részeként.This might be necessary simply as a matter of record, or as part of a forensic investigation.

A naplóadatok rendkívül bizalmasak.Audit information is highly sensitive. Valószínűleg olyan adatokat is tartalmaznak, amelyek azonosítják a rendszer felhasználóit és az általuk végrehajtott feladatokat.It will likely include data that identifies the users of the system, together with the tasks that they're performing. A naplóadatok emiatt leginkább a kizárólag a megbízható elemzők számára elérhető jelentések formájában állnak rendelkezésre, nem pedig a grafikai műveletek részletes elemzését lehetővé tévő interaktív rendszerként.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. Az elemzőnek különböző jelentéseket kell tudniuk létrehozni.An analyst should be able to generate a range of reports. A jelentések például listázhatják az adott időszakban bekövetkezett felhasználó tevékenységeket, részletes kronológiát biztosíthatnak egy adott felhasználó tevékenységéről, vagy listázhatják az egy vagy több erőforrásra vonatkozóan végrehajtott műveletek sorát.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.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

A naplózáshoz használt információk elsődleges forrásai az alábbiak lehetnek:The primary sources of information for auditing can include:

  • A felhasználók hitelesítését kezelő biztonsági rendszer.The security system that manages user authentication.
  • A felhasználók tevékenységét rögzítő nyomkövetési naplók.Trace logs that record user activity.
  • Az azonosítható és azonosíthatatlan hálózati kéréseket nyomon követő biztonsági naplók.Security logs that track all identifiable and unidentifiable network requests.

A naplóadatok formátumára és tárolásuk módjára szabályozási követelmények vonatkozhatnak.The format of the audit data and the way in which it's stored might be driven by regulatory requirements. Előfordulhat például, hogy az adatok semmilyen módon nem törölhetők.For example, it might not be possible to clean the data in any way. (Az eredeti formátumban kell rögzíteni.) A jogosulatlan hozzáférés megakadályozása érdekében védeni kell a tárolót, ahol a birtokában van.(It must be recorded in its original format.) Access to the repository where it's held must be protected to prevent tampering.

A naplóadatok elemzéseAnalyzing audit data

Az elemzőknek el kell tudniuk érni a nyers adatok egészét, azok eredeti formájában.An analyst must be able to access the raw data in its entirety, in its original form. Az általános naplózási jelentések készítésének igénye mellett az adatok elemzésére szolgáló eszközök valószínűleg specializáltak lesznek, és a rendszeren kívül vannak elhelyezve.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.

A használat monitorozásaUsage monitoring

A használat monitorozása az alkalmazás funkcióinak és összetevőinek használatát követi nyomon.Usage monitoring tracks how the features and components of an application are used. Az operátor az alábbiakat teheti az összegyűjtött adatok használatával:An operator can use the gathered data to:

  • A gyakran használt funkcióknak és a rendszer potenciálisan kritikus pontjainak az azonosítása.Determine which features are heavily used and determine any potential hotspots in the system. A nagy forgalmú elemek működése javítható funkcionális particionálással vagy akár replikációval a terhelés egyenletesebb elosztása érdekében.High-traffic elements might benefit from functional partitioning or even replication to spread the load more evenly. Az operátor ezen információk használatával megállapíthatja, hogy melyek azok ritkán használt funkciók, amelyeket érdemes lehet kivezetni vagy a rendszer egy jövőbeli verziójában lecserélni.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.

  • Információk beszerzése a rendszer működési eseményeivel kapcsolatban a normál használat során.Obtain information about the operational events of the system under normal use. Például egy e-kereskedelmi webhely a tranzakciók számával és az azokért felelős ügyfelek mennyiségével kapcsolatos statisztikai adatokat rögzíthet.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. Ezek az adatok a kapacitástervezéshez használhatók az ügyfelek számának növekedésével.This information can be used for capacity planning as the number of customers grows.

  • A rendszer teljesítményével vagy funkcióival kapcsolatos felhasználói elégedettség észlelése (lehetőleg közvetetten).Detect (possibly indirectly) user satisfaction with the performance or functionality of the system. HA például egy e-kereskedelmi rendszer ügyfelei rendszeresen, nagy számban hagyják félbe a vásárlást, annak oka a fizetési funkcióval kapcsolatos probléma lehet.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.

  • Számlázási információk létrehozása.Generate billing information. A kereskedelmi alkalmazások és a több-bérlős szolgáltatások díjakat számíthatnak fel az ügyfeleknek az általuk használt erőforrásokért.A commercial application or multitenant service might charge customers for the resources that they use.

  • Kvóták érvényesítése.Enforce quotas. Ha egy több-bérlős rendszer valamelyik felhasználója meghaladja a feldolgozási időre vagy erőforrás-használatra vonatkozó, kifizetett kvótát egy adott időszak során, a hozzáférése korlátozható vagy a feldolgozási teljesítmény szabályozható.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.

A használat monitorozására vonatkozó követelményekRequirements for usage monitoring

A rendszerhasználat vizsgálatához az operátornak általában az alábbiakat magukban foglaló információkat kell látnia:To examine system usage, an operator typically needs to see information that includes:

  • Az egyes alrendszerek által feldolgozott és az egyes erőforrásokhoz továbbított kérések száma.The number of requests that are processed by each subsystem and directed to each resource.
  • Az egyes felhasználók által végzett munka.The work that each user is performing.
  • Az egyes felhasználók által foglalt adattárterület.The volume of data storage that each user occupies.
  • Az egyes felhasználók által elért erőforrások.The resources that each user is accessing.

Az operátornak diagramokat is létre kell tudnia hozni.An operator should also be able to generate graphs. A grafikonokon például megjeleníthetők a leginkább erőforrás-igényes felhasználók, vagy a leggyakrabban elért erőforrások vagy rendszerfunkciók.For example, a graph might display the most resource-hungry users, or the most frequently accessed resources or system features.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

A használat monitorozása viszonylag magas szinten végezhető.Usage tracking can be performed at a relatively high level. Képes feljegyezni az egyes kérések kezdési és befejezési időpontját és a kérés jellegét (olvasás, írás stb., az adott erőforrástól függően).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). Ezek az információk az alábbi módokon szerezhetők be:You can obtain this information by:

  • Felhasználói tevékenység nyomon követése.Tracing user activity.
  • Az egyes erőforrások használatát mérő teljesítményszámlálók rögzítése.Capturing performance counters that measure the utilization for each resource.
  • Az egyes felhasználók erőforrás-felhasználásának monitorozása.Monitoring the resource consumption by each user.

Mérési célokra azt is meg kell tudnia, hogy mely felhasználók felelősek a műveletek végrehajtásához, valamint a műveletek által használt erőforrások azonosításához.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. A gyűjtött információknak megfelelően részletezettnek kell lennie a pontos számlázáshoz.The gathered information should be detailed enough to enable accurate billing.

ProblémakövetésIssue tracking

Az ügyfelek és egyéb felhasználók problémákat jelenthetnek, ha váratlan esemény vagy működés következik be a rendszerben.Customers and other users might report issues if unexpected events or behavior occurs in the system. A problémakövetés az ilyen problémák kezelésével foglalkozik, a problémákat a rendszerben rejlő alapvető hibák elhárítására irányuló törekvésekhez társítva, valamint tájékoztatja a felhasználókat a lehetséges megoldásokkal kapcsolatban.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.

A problémakövetésre vonatkozó követelményekRequirements for issue tracking

Az operátorok gyakran külön rendszer használatával végzik a problémakövetést, amelyeken rögzíthetik és jelenthetik a felhasználók által jelentett problémák részleteit.Operators often perform issue tracking by using a separate system that enables them to record and report the details of problems that users report. Ezek a részletek a felhasználók által megkísérelt feladatokat, a problémák tüneteit, az események sorozatát, valamint a küldött hiba- és figyelmeztető üzeneteket foglalhatják például magukban.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.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

A problémakövetési adatok kezdeti forrása a felhasználó, aki a problémát először jelentette.The initial data source for issue-tracking data is the user who reported the issue in the first place. A felhasználó további adatokat is biztosíthat, például:The user might be able to provide additional data such as:

  • Összeomlási memóriakép (ha az alkalmazás tartalmaz a felhasználó asztali gépén futó összetevőt).A crash dump (if the application includes a component that runs on the user's desktop).
  • Képernyő-pillanatfelvétel.A screen snapshot.
  • A hiba bekövetkezésének dátuma és időpontja az egyéb környezeti adatokkal, például a felhasználó tartózkodási helyével együtt.The date and time when the error occurred, together with any other environmental information such as the user's location.

Ezek az adatok felhasználhatók a hibakeresési tevékenység során, valamint a segítségükkel összeállítható a fejlesztendő funkciók listája a szoftver jövőbeli kiadásaihoz.This information can be used to help the debugging effort and help construct a backlog for future releases of the software.

A problémakövetési adatok elemzéseAnalyzing issue-tracking data

Előfordulhat, hogy több felhasználó is jelenti ugyanazt a problémát.Different users might report the same problem. A problémakövetési rendszernek társítania kell az azonos jelentéseket.The issue-tracking system should associate common reports.

A hibakeresési tevékenység előrehaladását rögzíteni kell az egyes hibajelentésekben.The progress of the debugging effort should be recorded against each issue report. Ha a probléma elhárítása megtörtént, az ügyfél tájékoztatható a megoldásról.When the problem is resolved, the customer can be informed of the solution.

Ha a felhasználó egy olyan problémát jelent, amelynek már létezik megoldása a problémakövetési rendszerben, az operátornak tudnia kell azonnal tájékoztatni a felhasználót a megoldásról.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.

A műveletek nyomon követése, és a szoftverkiadások hibáinak elhárításaTracing operations and debugging software releases

Amikor egy felhasználó hibát jelez, a felhasználó gyakran csak a működésük azonnali hatásáról értesül.When a user reports an issue, the user is often only aware of the immediate effect that it has on their operations. A felhasználó csak az általa tapasztalt működés eredményét tudja jelenteni a rendszer karbantartásáért felelős operátor számára.The user can only report the results of their own experience back to an operator who is responsible for maintaining the system. Ezek a tapasztalatok rendszerint csak a látható tünetei egy vagy több alapvető problémáknak.These experiences are usually just a visible symptom of one or more fundamental problems. Sok esetben egy elemzőnek alaposan át kell tekintenie a mögöttes műveletek kronológiáját a probléma kiváltó okának meghatározásához.In many cases, an analyst will need to dig through the chronology of the underlying operations to establish the root cause of the problem. Ezt az eljárást a kiváltó okok elemzésének nevezik.This process is called root cause analysis.

Megjegyzés

A kiváltó okok elemzése feltárhatja az alkalmazás tervezési hiányosságait.Root cause analysis might uncover inefficiencies in the design of an application. Ilyen esetekben át lehet dolgozni az érintett elemeket, és egy későbbi kiadás részeként telepíteni lehet azokat.In these situations, it might be possible to rework the affected elements and deploy them as part of a subsequent release. Ez a folyamat alapos tervezést igényel, és a frissített összetevőket gondosan monitorozni kell.This process requires careful control, and the updated components should be monitored closely.

A nyomkövetésre és hibakeresésre vonatkozó követelményekRequirements for tracing and debugging

A váratlan események és egyéb problémák követéséhez létfontosságú, hogy a monitorozási adatok elegendő információt biztosítsanak az elemző számára a problémák eredetének visszakövetéséhez és a bekövetkezett események sorának rekonstruálásához.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. Elegendő információnak kell rendelkezésre állnia ahhoz, hogy az elemző diagnosztizálhassa a problémák kiváltó okait.This information must be sufficient to enable an analyst to diagnose the root cause of any problems. A fejlesztők ezután elvégezhetik a szükséges módosításokat a problémák újbóli bekövetkezésének a megakadályozásához.A developer can then make the necessary modifications to prevent them from recurring.

Adatforrások, rendszerállapot-adatok és adatgyűjtési követelményekData sources, instrumentation, and data-collection requirements

A hibaelhárításnak része lehet az egyes műveletek keretében meghívott összes metódus (és azok paramétereinek) nyomon követése, így felépíthető egy fa, amely a rendszeren végighaladó logikai folyamatot ábrázolja, amikor egy ügyfél egy adott kérést kezdeményez.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. A rendszer által a folyamat eredményeként létrehozott kivételeket és figyelmeztetéseket rögzíteni és naplózni kell.Exceptions and warnings that the system generates as a result of this flow need to be captured and logged.

A hibakeresés támogatása érdekében a rendszer hurkokat biztosíthat, amelyek segítségével az operátor rögzítheti a rendszer kritikus pontjainak állapotadatait.To support debugging, the system can provide hooks that enable an operator to capture state information at crucial points in the system. Másik megoldásként a rendszer biztosíthat információkat minden lépésről, miközben a kiválasztott műveletek zajlanak.Or, the system can deliver detailed step-by-step information as selected operations progress. Az ilyen részletességi szintű adatok rögzítése további terhelést jelenthet a rendszer számára, ezért ideiglenes folyamatnak kell lennie.Capturing data at this level of detail can impose an additional load on the system and should be a temporary process. Az operátorok főleg akkor alkalmazzák ezt a folyamatot, amikor rendkívül szokatlan események nehezen megismételhető sorozata következik be, vagy ha a rendszerben újonnan bevezetett egy vagy több elemet gondosan monitorozni kell annak biztosításához, hogy az elemek az elvárt módon működnek.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.

A monitorozási és diagnosztikai folyamatThe monitoring and diagnostics pipeline

A kiterjedt, elosztott rendszerek megfigyelése meglehetősen nehéz.Monitoring a large-scale distributed system poses a significant challenge. Az előző szakaszban leírt forgatókönyveket nem feltétlenül egymástól elkülönítve kell alkalmazni.Each of the scenarios described in the previous section should not necessarily be considered in isolation. Az egyes helyzetekhez szükséges monitorozási és diagnosztikai adatok vélhetően jelentős átfedésben lesznek, jóllehet előfordulhat, hogy az adatokat különböző módon kell feldolgozni és megjeleníteni.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. Ebből kifolyólag a monitorozást és a diagnosztikát holisztikus módon kell szemlélni.For these reasons, you should take a holistic view of monitoring and diagnostics.

A teljes monitorozási és diagnosztikai folyamatot egy folyamatként érdemes elképzelni, amely az 1. ábrán látható szakaszokat foglalja magában.You can envisage the entire monitoring and diagnostics process as a pipeline that comprises the stages shown in Figure 1.

A monitorozási és diagnosztikai folyamat szakaszai

1. ábra – a monitorozási és diagnosztikai folyamat fázisai.Figure 1 - The stages in the monitoring and diagnostics pipeline.

Az 1. ábra rámutat arra, hogy a monitorozási és diagnosztikai adatok számos különféle adatforrásból származhatnak.Figure 1 highlights how the data for monitoring and diagnostics can come from a variety of data sources. A rendszerállapot-megfigyelési és az adatgyűjtési szakasz feladata a rögzítendő adatok forrásainak azonosítása, a rögzítendő adatoknak, a rögzítés módjának és az adatok könnyű vizsgálhatóságot lehetővé tevő formátumának meghatározása.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. Az elemzés/diagnosztika szakasz a nyers adatokat felhasználva hasznos adatokat hoz létre, amelyek segítségével az operátor meghatározhatja a rendszer állapotát.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. Az operátor ezen információk alapján döntéseket hozhat a lehetséges intézkedésekre vonatkozóan, majd az eredményeket visszaküldheti a rendszerállapot-figyelési és az adatgyűjtési szakaszba.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. A megjelenítési/riasztási szakasz hasznavehető képet biztosít a rendszer állapotáról.The visualization/alerting stage phase presents a consumable view of the system state. Különféle irányítópultokon közel valós idejű információkat jeleníthet meg.It can display information in near real time by using a series of dashboards. Emellett jelentések, diagramok és grafikonok létrehozásával a hosszú távú trendek azonosítását segítő adatok előzménynézetét biztosíthatja.And it can generate reports, graphs, and charts to provide a historical view of the data that can help identify long-term trends. Ha az adatok azt jelzik, hogy egy KPI valószínűleg meghaladja majd az elfogadható határértékeket, ez a szakasz riasztást is küldhet az operátornak.If information indicates that a KPI is likely to exceed acceptable bounds, this stage can also trigger an alert to an operator. Bizonyos esetekben a riasztással automatikus folyamat is indítható, amely korrekciós művelet, például automatikus skálázás végrehajtására tesz kísérletet.In some cases, an alert can also be used to trigger an automated process that attempts to take corrective actions, such as autoscaling.

Vegye figyelembe, hogy a lépéseket egy összefüggő folyamatot alkotnak, amelyben a szakaszok egymással párhuzamosan zajlanak.Note that these steps constitute a continuous-flow process where the stages are happening in parallel. Ideális esetben a szakaszok dinamikusan konfigurálhatók.Ideally, all the phases should be dynamically configurable. Bizonyos pontokon, különösen ha a rendszer újonnan lett üzembe helyezve vagy problémákba ütközik, nagyobb gyakorisággal lehet szükség többféle adat gyűjtésére.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. Máskor azonban vissza kell tudni állni csak a lényeges információk alapszintű gyűjtésére a rendszer megfelelő működésének ellenőrzéséhez.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.

Ezenfelül a teljes monitorozási folyamatot egy folyamatosan működő megoldásnak kell tekinteni, amely finomhangolásra és fejlesztésre szorul a visszajelzések alapján.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. Előfordulhat például, hogy induláskor esetleg rengeteg tényezőt mér a rendszer állapotának meghatározásához.For example, you might start with measuring many factors to determine system health. Idővel az elemzés révén finomítható a működés, a nem releváns mérések elvethetők, és pontosabban összpontosíthat a valóban szükséges adatokra, miközben a háttérzaj minimalizálható.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.

A monitorozási és diagnosztikai adatok forrásaiSources of monitoring and diagnostic data

A monitorozási folyamat által használt által információk számos különböző forrásból származhatnak, amint az az 1. ábrán is látható.The information that the monitoring process uses can come from several sources, as illustrated in Figure 1. Az alkalmazás szintjén az információk a rendszer kódjába ágyazott nyomkövetési naplókból származnak.At the application level, information comes from trace logs incorporated into the code of the system. A fejlesztőknek érdemes egy standard megközelítést alkalmazni a vezérlési folyam nyomon követésére a kódban.Developers should follow a standard approach for tracking the flow of control through their code. A metódusokba való belépéskor például kibocsátható egy nyomkövetési üzenet, amely megadja a metódus nevét, az aktuális időpontot, az egyes paraméterek értékét és minden egyéb releváns információt.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. A be- és kilépési idők rögzítése szintén hasznosnak bizonyulhat.Recording the entry and exit times can also prove useful.

Az összes kivételt és figyelmeztetést naplózni kell, és gondoskodni kell a beágyazott kivételek és figyelmeztetések teljes nyomkövetésének a megőrzéséről.You should log all exceptions and warnings, and ensure that you retain a full trace of any nested exceptions and warnings. Ideális esetben a kódot futtató felhasználót azonosító adatokat is rögzíteni kell, a tevékenységek korrelálására szolgáló adatokkal egyetemben (a kérések nyomon követésére, miközben áthaladnak a rendszeren).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). Emellett naplózni kell az erőforrások, például az üzenetsorok, adatbázisok, fájlok és egyéb függő szolgáltatások elérésére tett kísérleteket is.And you should log attempts to access all resources such as message queues, databases, files, and other dependent services. Ezek az információk mérési és naplózási célokra használhatók.This information can be used for metering and auditing purposes.

Számos alkalmazás könyvtárakat és keretrendszert használ olyan gyakori feladatok elvégzéséhez, mint például az adattár elérése vagy a hálózaton keresztüli kommunikáció.Many applications use libraries and frameworks to perform common tasks such as accessing a data store or communicating over a network. Ezek a keretrendszerek konfigurálhatók saját nyomkövetési üzenetek és nyers diagnosztikai információk biztosítására, ilyen például a tranzakciók sebessége vagy az adatátvitel sikeressége és sikertelensége.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.

Megjegyzés

Számos modern keretrendszer automatikusan közzéteszi a teljesítményt és a nyomkövetési eseményeket.Many modern frameworks automatically publish performance and trace events. Ezen információk rögzítéséhez csupán eszközt kell biztosítani a lekérésükhöz, és olyan helyen kell tárolni őket, ahol feldolgozhatók és elemezhetők.Capturing this information is simply a matter of providing a means to retrieve and store it where it can be processed and analyzed.

Az alkalmazást futtató operációs rendszer olyan alsó szintű rendszerinformációk forrásaként szolgálhat, mint az I/O-sebességet, a memória- és a processzorhasználatot jelző teljesítményszámlálók.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. Az operációs rendszer hibái (például egy fájl megfelelő megnyitásának sikertelensége) szintén jelenthetők.Operating system errors (such as the failure to open a file correctly) might also be reported.

A rendszert futtató mögöttes infrastruktúrát és összetevőket is számításba kell venni.You should also consider the underlying infrastructure and components on which your system runs. A virtuális gépek, virtuális hálózatok és tárolószolgáltatások mind szolgálhatnak fontos, infrastruktúraszintű teljesítményszámlálók és egyéb diagnosztikai adatok forrásául.Virtual machines, virtual networks, and storage services can all be sources of important infrastructure-level performance counters and other diagnostic data.

Ha az alkalmazás egyéb külső szolgáltatásokat, például webkiszolgálót vagy adatbázis-kezelési rendszert is használ, ezek a szolgáltatások saját nyomkövetési adatokat, naplókat és teljesítményszámlálókat tehetnek közzé.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. Ilyenek például az SQL Server dinamikus felügyeleti nézetei az SQL Server-adatbázisra irányulóan végrehajtott műveletek nyomon követésére, és az IIS nyomkövetési naplói a webkiszolgálóhoz intézett kérések rögzítésére.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.

A rendszer összetevőinek módosításával és az újabb verziók üzembe helyezésével fontos, hogy a problémák, események és mérőszámok az egyes verziókhoz rendelhetők legyenek.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. Ezeket az információkat a kiadási folyamathoz kell kötni, hogy az összetevők adott verziójával kapcsolatos problémák gyorsan felderíthetők és javíthatók legyenek.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.

Biztonsági problémák a rendszer bármelyik pontján felléphetnek.Security issues might occur at any point in the system. Egy felhasználó például megpróbálhat érvénytelen felhasználói azonosítóval vagy jelszóval bejelentkezni.For example, a user might attempt to sign in with an invalid user ID or password. Egy hitelesített felhasználó megpróbálhat jogosulatlan hozzáférést szerezni egy erőforráshoz.An authenticated user might try to obtain unauthorized access to a resource. Vagy egy felhasználó megpróbálhat egy érvénytelen vagy elavult kulcsot megadni a titkosított adatok eléréséhez.Or a user might provide an invalid or outdated key to access encrypted information. A sikeres és sikertelen kérések biztonsággal kapcsolatos adatait mindig naplózni kell.Security-related information for successful and failing requests should always be logged.

A Rendszerállapot-figyelés az alkalmazásban szakasz további útmutatást nyújt azon információkkal kapcsolatban, amelyeket rögzíteni kell.The section Instrumenting an application contains more guidance on the information that you should capture. Az információk gyűjtésére azonban többféle stratégia használható:But you can use a variety of strategies to gather this information:

  • Alkalmazás-/rendszermonitorozás.Application/system monitoring. Ez a stratégia az alkalmazáson, alkalmazás-keretrendszereken, operációs rendszereken és infrastruktúrán belüli forrásokat használ.This strategy uses internal sources within the application, application frameworks, operating system, and infrastructure. Az alkalmazás kódja is létrehozhat saját monitorozási adatokat az ügyfélkérések életciklusának fontosabb pontjain.The application code can generate its own monitoring data at notable points during the lifecycle of a client request. Az alkalmazás nyomkövetési utasításokat is tartalmazhat, amelyek szelektíven engedélyezhetők vagy tilthatók le a körülményeknek megfelelően.The application can include tracing statements that might be selectively enabled or disabled as circumstances dictate. Diagnosztika is beszúrható dinamikusan diagnosztikai keretrendszer használatával.It might also be possible to inject diagnostics dynamically by using a diagnostics framework. Ezek a keretrendszerek általában olyan beépülő modulokat biztosítanak, amelyek a kód különböző rendszerállapot-figyelési pontjaihoz csatlakozva rögzítik a pontok nyomkövetési adatait.These frameworks typically provide plug-ins that can attach to various instrumentation points in your code and capture trace data at these points.

    Emellett a kód és/vagy a mögöttes infrastruktúra is létrehozhat eseményeket a kritikus pontokon.Additionally, your code and/or the underlying infrastructure might raise events at critical points. Az események figyelésére konfigurált monitorozási ügynökök rögzíthetik az eseményadatokat.Monitoring agents that are configured to listen for these events can record the event information.

  • Valódi felhasználómonitorozás.Real user monitoring. Ez a megközelítés a felhasználó és az alkalmazás közötti interakciót rögzíti, és az egyes kérések és válaszok útját figyeli.This approach records the interactions between a user and the application and observes the flow of each request and response. Ezek az információk két célra alkalmazhatók: az egyes felhasználók általi használat mérésére, valamint annak meghatározására, hogy a felhasználók megfelelő szolgáltatásminőséget kapnak-e (például gyors válaszidők, alacsony késés és minimális számú hiba).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). A rögzített adatok használatával azonosíthatók a problémás területek, ahol a hibák leggyakrabban fellépnek.You can use the captured data to identify areas of concern where failures occur most often. Az adatok alapján azonosíthatók azok az elemek is, ahol a rendszer lelassul, vélhetően az alkalmazás forgalmas pontjai vagy a szűk keresztmetszet más formái miatt.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. Ha körültekintően alkalmazza ezt a megközelítést, a felhasználóknak az alkalmazásban követett útja esetleg rekonstruálható lesz hibakeresési és tesztelési célokra.If you implement this approach carefully, it might be possible to reconstruct users' flows through the application for debugging and testing purposes.

    Fontos

    A valódi felhasználók monitorozásával rögzített adatokat rendkívül kényes adatként kell kezelni, mivel bizalmas információkat is tartalmazhatnak.You should consider the data that's captured by monitoring real users to be highly sensitive because it might include confidential material. Ha menti a rögzített adatokat, biztonságosan tárolja azokat.If you save captured data, store it securely. Ha az adatokat a teljesítmény monitorázáshoz vagy hibakereséshez szeretné használni, először távolítsa el a személyes azonosításra alkalmas adatok mindegyikét.If you want to use the data for performance monitoring or debugging purposes, strip out all personally identifiable information first.

  • Szintetikus felhasználói figyelés.Synthetic user monitoring. Ebben a megközelítésben saját tesztügyfelet ír, amely szimulálja a felhasználókat, és egy konfigurálható, de általános műveletsort hajt végre.In this approach, you write your own test client that simulates a user and performs a configurable but typical series of operations. A tesztügyfél teljesítményének nyomon követésével meghatározhatja a rendszer állapotát.You can track the performance of the test client to help determine the state of the system. A tesztügyfél több példányát egy terheléstesztelési művelet részeként használva megállapítható, hogyan reagál a rendszer a magas terhelés alatt, és milyen monitorozási adatok keletkeznek ilyen körülmények közt.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.

    Megjegyzés

    A valódi és szintetikus felhasználómonitorozás olyan kód alkalmazásával valósítható meg, amely a metódushívásokat és az alkalmazás egyéb kritikus részeit követi nyomon és látja el időadatokkal.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.

  • Profilkészítés.Profiling. Ez a megközelítés elsősorban az alkalmazásteljesítmény monitorozását és javítását célozza.This approach is primarily targeted at monitoring and improving application performance. Ahelyett, hogy a valódi és szintetikus felhasználómonitorozás funkcionális szintjén működne, alacsonyabb szintű információkat rögzít az alkalmazás futása során.Rather than operating at the functional level of real and synthetic user monitoring, it captures lower-level information as the application runs. A profilkészítés az alkalmazások végrehajtási állapotának rendszeres mintavételezésével (az alkalmazás által az adott pillanatban futtatott kódrészlet meghatározásával) valósítható meg.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). Olyan rendszerállapot-figyelést is alkalmazhat, amely mintavételezőket szúr be a kód kritikus elágazásain (például a metódushívások indításánál és befejezésénél), és rögzíti, hogy mely metódusok lettek meghívva, mikor, és mennyi ideig tartottak az egyes hívások.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. Az adatok elemzésével aztán meghatározható, hogy az alkalmazás mely részei okozhatnak teljesítményproblémákat.You can then analyze this data to determine which parts of the application might cause performance problems.

  • Végpontok figyelése.Endpoint monitoring. Ez a módszer egy vagy több diagnosztikai végpontot alkalmaz, amelyeket az alkalmazás kifejezetten a monitorozás lehető tétele céljából tesz elérhetővé.This technique uses one or more diagnostic endpoints that the application exposes specifically to enable monitoring. A végpontok egy utat biztosítanak az alkalmazás kódjába, és információkat adhatnak vissza a rendszer állapotával kapcsolatban.An endpoint provides a pathway into the application code and can return information about the health of the system. Különböző végpontok a működés különböző aspektusaira fókuszálhatnak.Different endpoints can focus on various aspects of the functionality. Írhat saját diagnosztikai ügyfelet, amely rendszeresen kéréseket küld ezekre a végpontokra, és feldolgozza a válaszokat.You can write your own diagnostics client that sends periodic requests to these endpoints and assimilate the responses. További információ: állapot végpont figyelési mintája.For more information, see the Health Endpoint Monitoring pattern.

A maximális lefedettség érdekében érdemes ezeknek a módszereknek valamilyen kombinációját alkalmaznia.For maximum coverage, you should use a combination of these techniques.

Rendszerállapot-figyelés az alkalmazásbanInstrumenting an application

A rendszerállapot-figyelés a monitorozási folyamat kritikus részét képezi.Instrumentation is a critical part of the monitoring process. A rendszer teljesítményével és állapotával kapcsolatban csak úgy hozhat megalapozott döntéseket, ha előbb rögzíti azokat az adatokat, amelyek lehetővé teszik ezen döntések meghozatalát.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. A rendszerállapot-figyelés segítségével gyűjtött információknak elegendőnek kell lenniük a teljesítmény értékeléséhez, a problémák diagnosztizálásához és a döntések meghozatalához anélkül, hogy be kellene jelentkezni egy távoli éles kiszolgálóra a nyomkövetés (és a hibakeresés) manuális végrehajtásához.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. A rendszerállapot-adatok általában mérőszámokból és a nyomkövetési naplókba írt információkból állnak.Instrumentation data typically comprises metrics and information that's written to trace logs.

A nyomkövetési napló tartalmát képezhetik az alkalmazás által írt szöveges adatok vagy a nyomkövetési események eredményeként keletkező bináris adatok (ha az alkalmazás Windows esemény-nyomkövetést (ETW) alkalmaz).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). Ezeket az adatokat az infrastruktúra részein, például a webkiszolgálón létrejövő eseményeket rögzítő rendszernaplók is létrehozhatják.They can also be generated from system logs that record events arising from parts of the infrastructure, such as a web server. A szöveges naplóüzenetek gyakran a felhasználók számára olvashatók, azonban olyan formátumban kell írni őket, amely lehetővé teszi az egyszerű elemzésüket is az automatikus rendszerek számára.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.

A naplókat kategorizálni is kell.You should also categorize logs. Ne írjon minden nyomkövetési adatot ugyanabba a naplóba, hanem külön naplókba rögzítse a rendszer különböző működési területeinek nyomkövetési eredményeit.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. Így gyorsan szűrheti majd a naplóüzeneteket, ha azokat a megfelelő naplóból olvassa be, és nem egyetlen hosszú fájlt kell feldolgoznia.You can then quickly filter log messages by reading from the appropriate log rather than having to process a single lengthy file. Ne írjon különböző biztonsági követelményekkel rendelkező információt (például naplózási információkat és hibakeresési adatokat) ugyanazon naplóba.Never write information that has different security requirements (such as audit information and debugging data) to the same log.

Megjegyzés

A napló lehet egy fájl a fájlrendszerben, vagy menthető más formátumba is, például blobként a Blob Storage-tárolóban.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. A naplóadatok tárolhatók strukturáltabb módon is, például egy tábla soraiként.Log information might also be held in more structured storage, such as rows in a table.

A mérőszámok általában a rendszer egy adott aspektusára vagy erőforrására és egy adott időpontra vonatkozó mérések vagy darabszámok, amelyek egy vagy több hozzárendelt címkével vagy dimenzióval rendelkeznek (ezeket néha mintának is szokás nevezni).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). A mérőszámok egyes példányai önmagukban általában nem használhatók,A single instance of a metric is usually not useful in isolation. hanem hosszabb időtartamra vonatkozóan kell rögzíteni őket.Instead, metrics have to be captured over time. A legfontosabb azt figyelembe venni, hogy pontosan mely mérőszámokat és milyen gyakorisággal kell rögzíteni.The key issue to consider is which metrics you should record and how frequently. A mérőszámadatok túl gyakori gyűjtése jelentős további terhelést jelent a rendszer számára, míg a túl ritka gyűjtés esetén lemaradhat az egyes jelentős események keletkezését okozó körülményekről.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. A szempontok mérőszámonként eltérőek lehetnek.The considerations will vary from metric to metric. A processzorhasználat egy kiszolgálón például egyik másodpercről a másikra változhat, de a magas kihasználtság csak akkor válik problémává, ha hosszan, több percen keresztül tart.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.

Információk az adatok korrelálásáhozInformation for correlating data

Egyszerűen monitorozhatja az egyes rendszerszintű teljesítményszámlálókat, rögzítheti az erőforrások mérőszámait, és szerezhet be alkalmazás-nyomkövetési információkat a különböző naplófájlokból.You can easily monitor individual system-level performance counters, capture metrics for resources, and obtain application trace information from various log files. A monitorozás bizonyos formái esetén azonban szükség van egy elemzési és diagnosztikai szakaszra a monitorozási folyamatban a különféle forrásokból származó adatok korrelálásához.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. Ezek az adatok különféle formákat ölthetnek a nyers adatokban, és az elemzési folyamatot el kell látni megfelelő mennyiségű rendszerállapot-adattal, hogy képes legyen leképezni ezeket a különféle formákat.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. Tegyük fel például, hogy az alkalmazás-keretrendszer szintjén az egyes feladatokat egy szálazonosító azonosítja.For example, at the application framework level, a task might be identified by a thread ID. Az alkalmazáson belül ugyanazon feladat az azt végrehajtó felhasználó felhasználói azonosítójához társítható.Within an application, the same work might be associated with the user ID for the user who is performing that task.

Emellett nem is valószínű, hogy 1:1 leképezés hozható létre a szálak és a felhasználói kérések között, mivel az aszinkron műveletek ugyanannak a szálnak a használatával több felhasználó nevében is végezhetnek műveleteket.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. A dolgot tovább bonyolítja, hogy egyetlen kérést több szál is kezelhet, ahogy a végrehajtás végighalad a rendszeren.To complicate matters further, a single request might be handled by more than one thread as execution flows through the system. Amennyiben lehetséges, az egyes kérésekhez egy egyedi tevékenységazonosítót társítson, amelyet a végrehajtás propagál a rendszeren a kérés környezetének részeként.If possible, associate each request with a unique activity ID that's propagated through the system as part of the request context. (A tevékenységazonosítóknak létrehozásának és nyomkövetési adatokba való foglalásának módszere a nyomkövetési adatok rögzítésére szolgáló technológiától függ.)(The technique for generating and including activity IDs in trace information depends on the technology that's used to capture the trace data.)

Az összes megfigyelési adattal azonos módon kell időbélyeget adni.All monitoring data should be timestamped in the same way. A konzisztencia érdekében minden dátumot és időpontot az egyezményes világidő (UTC) használatával rögzítsen.For consistency, record all dates and times by using Coordinated Universal Time. Ez megkönnyíti az eseménysorozatok nyomon követését.This will help you more easily trace sequences of events.

Megjegyzés

Előfordulhat, hogy a különböző időzónákban és hálózatokon működő számítógépek nincsenek szinkronizálva.Computers operating in different time zones and networks might not be synchronized. A több gépre kiterjedő rendszerállapot-adatok korrelációjának hiánya nem függ egymástól.Don't depend on using timestamps alone for correlating instrumentation data that spans multiple machines.

A rendszerállapot-adatokba foglalandó információkInformation to include in the instrumentation data

Amikor mérlegeli, hogy milyen információkat kell gyűjtenie, vegye figyelembe az alábbi szempontokat:Consider the following points when you're deciding which instrumentation data you need to collect:

  • Gondoskodjon róla, hogy a nyomkövetési események által rögzített információk gépi és emberi olvasásra egyaránt alkalmasak legyenek.Make sure that information captured by trace events is machine and human readable. Alkalmazzon jól meghatározott sémákat az ilyen információkhoz, hogy megkönnyítse a naplóadatok automatizált feldolgozását a különféle rendszereken, valamint hogy biztosítsa a konzisztenciát a naplókat használó üzemeltetési és fejlesztési személyzet számára.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. Az információkat egészítse ki környezeti adatokkal, például a telepítési környezetre, a folyamatot futtató gépre, a folyamat részleteire és a hívási veremre vonatkozó adatokkal.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.

  • A profilkészítést csak abban az esetben engedélyezze, ha valóban szükséges, mivel jelentős többletterhelésnek teheti ki a rendszert.Enable profiling only when necessary because it can impose a significant overhead on the system. A rendszerállapot-adatokat használó profilkészítés minden egyes alkalommal rögzíti az eseményeket (például a metódushívásokat) azok előfordulásakor, míg a mintavételezés csak a kiválasztott eseményeket rögzíti.Profiling by using instrumentation records an event (such as a method call) every time it occurs, whereas sampling records only selected events. A kijelölés időalapú (akár n másodpercenkénti), vagy gyakoriság-alapú (egyszeres n kérelmek esetén).The selection can be time-based (once every n seconds), or frequency-based (once every n requests). Ha túl gyakran történnek események, a rendszerállapot-adatokat használó profilkészítés túl nagy terhet jelenthet, és negatív hatással lehet az általános teljesítményre.If events occur very frequently, profiling by instrumentation might cause too much of a burden and itself affect overall performance. Ebben az esetben a mintavételezéses módszer használata előnyösebb lehet.In this case, the sampling approach might be preferable. Ha azonban az események gyakorisága alacsony, előfordulhat, hogy a mintavételezés lemarad róluk.However, if the frequency of events is low, sampling might miss them. Ebben az esetben a rendszerállapot-figyelés bizonyulhat a hatékonyabb megközelítésnek.In this case, instrumentation might be the better approach.

  • Biztosítson elegendő kontextust, amely alapján a fejlesztők és rendszergazdák megállapíthatják az egyes kérések forrását.Provide sufficient context to enable a developer or administrator to determine the source of each request. A kontextus tartalmazhat például valamilyen tevékenységazonosítót, amely azonosítja a kérés egy adott példányát.This might include some form of activity ID that identifies a specific instance of a request. Emellett tartalmazhat olyan információkat is, amelyek használatával a tevékenység korrelálható az elvégzett számítási munkával és a használt erőforrásokkal.It might also include information that can be used to correlate this activity with the computational work performed and the resources used. Vegye figyelembe, hogy a munka esetleg túlnyúlik a folyamatok és a gépek határain.Note that this work might cross process and machine boundaries. Mérés esetén a kontextusnak tartalmaznia kell (közvetlenül vagy más korrelált információkon keresztül közvetve) a kérés létrehozását kiváltó felhasználóra vonatkozó hivatkozást is.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. A kontextus értékes információkat biztosít az alkalmazásnak a monitorozási adatok rögzítésének időpontjában érvényes állapotára vonatkozóan.This context provides valuable information about the application state at the time that the monitoring data was captured.

  • Minden kérést rögzíteni kell, a kérések kezdeményezésének helyével vagy régiójával együtt.Record all requests, and the locations or regions from which these requests are made. Ezen információk segíthetnek annak meghatározásában, hogy vannak-e helyspecifikus kritikus pontok a rendszerben.This information can assist in determining whether there are any location-specific hotspots. Az információk hasznosak lehetnek annak meghatározásához is, hogy érdemes-e az alkalmazást vagy az általa használt adatokat újraparticionálni.This information can also be useful in determining whether to repartition an application or the data that it uses.

  • A kivételek adatait szintén gondosan rögzíteni kell.Record and capture the details of exceptions carefully. A kritikus fontosságú hibakeresési információk gyakran elvesznek a kivételek nem megfelelő kezelésének eredményeként.Often, critical debug information is lost as a result of poor exception handling. Az alkalmazás által jelentett kivételek minden adatát rögzíteni kell, beleértve a belső kivételekre vonatkozó és az egyéb környezeti információkat is.Capture the full details of exceptions that the application throws, including any inner exceptions and other context information. Ha lehetséges, a hívási vermet is rögzíteni kell.Include the call stack if possible.

  • Az alkalmazás különböző elemei által rögzített adatoknak konzisztensnek kell lenniük, ez ugyanis segíthet az események elemzésében, és azoknak a felhasználói kérésekkel való korrelálásában.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. Vegye fontolóra egy átfogó és konfigurálható naplózási csomag alkalmazását az információk gyűjtésére, és inkább nem számítson arra, hogy a fejlesztők ugyanazt a megközelítést alkalmazzák majd a rendszer különböző részeinek megvalósítása során.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. Gyűjtse a kulcsfontosságú teljesítményszámlálók adatait, például a végrehajtott I/O-műveletek mennyiségét, a hálózathasználatot, a kérések számát, a memóriahasználatot és a processzorhasználatot.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. Egyes infrastruktúraszolgáltatások saját teljesítményszámlálókat is biztosíthatnak, például az adatbázisokkal létesített kapcsolatok számát, a tranzakciók végrehajtási sebességét, valamint a sikeres vagy sikertelen tranzakciók számát.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. Emellett az alkalmazások is meghatározhatnak saját teljesítményszámlálókat.Applications might also define their own specific performance counters.

  • Naplózza a külső szolgáltatásokra, például adatbázisrendszerekre, webszolgáltatásokra vagy az infrastruktúra részét képező egyéb rendszerszintű szolgáltatásokra irányuló összes hívást.Log all calls made to external services, such as database systems, web services, or other system-level services that are part of the infrastructure. Rögzítse az egyes hívások végrehajtásához szükséges időkkel, valamint a hívások sikerességével vagy sikertelenségével kapcsolatos információkat is.Record information about the time taken to perform each call, and the success or failure of the call. Amennyiben lehetséges, rögzítse az összes újrapróbálkozási kísérletet és hibát is az előforduló átmeneti hibák esetén.If possible, capture information about all retry attempts and failures for any transient errors that occur.

A telemetriarendszerekkel való kompatibilitás biztosításaEnsuring compatibility with telemetry systems

Sok esetben a rendszerállapot-figyelés által létrehozott információk események sorozataként jönnek létre, amelyeket egy telemetriarendszer vesz át feldolgozásra és elemzésre.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. A telemetriarendszerek általában mindenféle alkalmazástól vagy topológiától függetlenek, de elvárják, hogy az információk egy specifikus, általában valamilyen séma alapján meghatározott formátumot kövessenek.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. A séma lényegében egy megállapodást jelent, amely meghatározza azon adatmezőket és -típusokat, amelyeket a telemetriarendszer fogadni képes.The schema effectively specifies a contract that defines the data fields and types that the telemetry system can ingest. A sémát érdemes általánosítani, hogy a különféle platformokról és eszközökről érkező adatok mindegyikét kezelni tudja.The schema should be generalized to allow for data arriving from a range of platforms and devices.

Az általános sémának tartalmaznia kell az összes rendszerállapot-figyelési eseményben megtalálható lévő mezőket, például az esemény nevét, az esemény időpontját, a küldő IP-címét, valamint a más eseményekkel való korreláláshoz szükséges adatokat (például a felhasználóazonosítót, eszközazonosítót és alkalmazásazonosítót).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). Ne feledje, hogy a legkülönfélébb eszközök hozhatnak létre eseményeket, ezért a sémának nem szabad függenie az eszköztípustól.Remember that any number of devices might raise events, so the schema should not depend on the device type. Emellett a különböző eszközök ugyanarra az alkalmazásra vonatkozó eseményeket hozhatnak létre, ezért az alkalmazásnak támogatnia kell a barangolást vagy a különböző eszközök közötti terjesztés valamilyen más formáját.Additionally, various devices might raise events for the same application; the application might support roaming or some other form of cross-device distribution.

A séma tartalmazhat tartományi mezőket is, amelyek a különböző alkalmazásokban közös forgatókönyvre jellemzők.The schema might also include domain fields that are relevant to a particular scenario that's common across different applications. A mezők tartalmazhatnak a kivételekkel, az alkalmazásindítási és -bezárási eseményekkel, valamint a webszolgáltatás API-hívásainak sikerével és/vagy sikertelenségével kapcsolatos információk.This might be information about exceptions, application start and end events, and success and/or failure of web service API calls. Az ugyanazon tartományi mezőket használó alkalmazások mindegyikének ugyanazokat az eseményeket kell kibocsátania, ami lehetővé teszi a közös jelentések és elemzések létrehozását.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.

Végül a séma tartalmazhat egyéni mezőket is az alkalmazásspecifikus események adatainak a rögzítéséhez.Finally, a schema might contain custom fields for capturing the details of application-specific events.

Ajánlott eljárások az alkalmazásokban zajló rendszerállapot-figyeléshezBest practices for instrumenting applications

Az alábbi lista a felhőben futó elosztott alkalmazás rendszerállapot-figyelésére vonatkozó ajánlott eljárásokat foglalja össze.The following list summarizes best practices for instrumenting a distributed application running in the cloud.

  • A naplók legyenek könnyen olvashatók és elemezhetők.Make logs easy to read and easy to parse. Alkalmazzon strukturált naplózást, ahol lehetséges.Use structured logging where possible. A naplóüzenetek legyenek tömörek és leíró jellegűek.Be concise and descriptive in log messages.

  • Minden naplóban azonosítsa a forrást, és biztosítson környezeti és időadatokat az egyes bejegyzések írásakor.In all logs, identify the source and provide context and timing information as each log record is written.

  • Ugyanazt az időzónát és formátumot használja az összes időbélyeghez.Use the same time zone and format for all timestamps. Így könnyebben korrelálhatja az olyan műveletek eseményeit, amelyek különböző régiókban futó hardvereken és szolgáltatásokon futnak.This will help to correlate events for operations that span hardware and services running in different geographic regions.

  • Kategorizálja a naplókat, és írja az üzeneteket a megfelelő naplófájlba.Categorize logs and write messages to the appropriate log file.

  • Ne tegye közzé a rendszerrel kapcsolatos bizalmas adatokat és a felhasználók személyes adatait.Do not disclose sensitive information about the system or personal information about users. A naplózás előtt tisztítsa meg az adatokat ezektől az információktól, azonban a releváns részleteket mindenképpen őrizze meg.Scrub this information before it's logged, but ensure that the relevant details are retained. Törölje például az azonosítót és a jelszót minden adatbázis-kapcsolati sztringből, a megmaradt információkat azonban írja a naplóba, így az elemzők megállapíthatják, hogy a rendszer a megfelelő adatbázist éri-e el.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. Naplózza az összes kritikus kivételt, azonban tegye lehetővé a rendszergazda számára a naplózás be-/kikapcsolását az alacsonyabb szintű kivételek és figyelmeztetések esetén.Log all critical exceptions, but enable the administrator to turn logging on and off for lower levels of exceptions and warnings. Rögzítse és naplózza az újrapróbálkozási logikával kapcsolatos összes információt is.Also, capture and log all retry logic information. Ezek az adatok hasznosnak bizonyulhatnak a rendszer átmeneti állapotának a monitorozása során.This data can be useful in monitoring the transient health of the system.

  • Kövesse a folyamatokon kívülre indított hívásokat, például a külső webszolgáltatásokra és adatbázisokra irányuló kéréseket.Trace out of process calls, such as requests to external web services or databases.

  • Ne keverje a különböző biztonsági szintű naplóüzeneteket ugyanabban a naplófájlban.Don't mix log messages with different security requirements in the same log file. Ne írja például a hibakeresési és a naplózási információkat ugyanabba a naplófájlba.For example, don't write debug and audit information to the same log.

  • A naplózási eseményeket kivéve, gondoskodjon róla, hogy az összes naplóhívás egyszeri művelet legyen, amely nem gátolja az üzleti tevékenységek végrehajtását.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. A naplózási események azért kivételesek, mivel üzleti szempontból kulcsfontosságúak, és az üzleti tevékenységek alapvető részének tekinthetők.Auditing events are exceptional because they are critical to the business and can be classified as a fundamental part of business operations.

  • Gondoskodjon róla, hogy a naplózás bővíthető legyen, és ne függjön közvetlenül semmilyen konkrét céltól.Make sure that logging is extensible and does not have any direct dependencies on a concrete target. Például ahelyett, hogy a System.Diagnostics.Trace használatával írná az adatokat, definiáljon egy absztrakt felületet (például ILogger), amely naplózási metódusokat tesz elérhetővé, és amely bármilyen megfelelő módszerrel megvalósítható.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.

  • Gondoskodjon róla, hogy a naplózás hibamentes legyen, és ne váltson ki sorozatosan egymásra épülő hibákat.Make sure that all logging is fail-safe and never triggers any cascading errors. A naplózásnak nem szabad kivételeket jelentenie.Logging must not throw any exceptions.

  • A rendszerállapot-figyelést egy folyamatosan zajló, iteratív folyamatként kell kezelni, és a naplókat rendszeresen át kell tekinteni, nem csupán probléma esetén.Treat instrumentation as an ongoing iterative process and review logs regularly, not just when there is a problem.

Az adatok gyűjtése és tárolásaCollecting and storing data

A monitorozási folyamat adatgyűjtési szakaszának feladata a rendszerállapot-figyelés során létrehozott információk lekérése, az adatok formázása az elemzési/diagnosztikai szakaszban történő könnyebb feldolgozás céljából, valamint az átalakított adatok mentése egy megbízható tárolóba.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. Az elosztott rendszerek különböző részeiből gyűjtött rendszerállapot-adatok különféle helyeken és különböző formátumokban tárolhatók.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. Az alkalmazás kódja például nyomkövetési naplófájlokat és az alkalmazáseseményekhez kapcsolódó naplóadatokat hozhat elő, míg az alkalmazás által használt infrastruktúra kritikus pontjait monitorozó teljesítményszámlálók más technológiákkal rögzíthetők.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. Az alkalmazás által használt külső összetevők és szolgáltatások eltérő formátumokban biztosíthatják a rendszerállapot-adatokat külön profilelemzési fájlok, blobtárolók vagy akár egyéni adattárak használatával.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.

Az adatgyűjtés gyakran a rendszerállapot-adatokat létrehozó alkalmazástól függetlenül futtatható adatgyűjtési szolgáltatás használatával történik.Data collection is often performed through a collection service that can run autonomously from the application that generates the instrumentation data. A 2. ábrán erre az architektúrára látható egy példa, amely kiemeli a rendszerállapot-adatokat gyűjtő alrendszert.Figure 2 illustrates an example of this architecture, highlighting the instrumentation data-collection subsystem.

Példa a rendszerállapot-adatok gyűjtésére

2. ábra – a rendszerállapot-adatok gyűjtése.Figure 2 - Collecting instrumentation data.

Vegye figyelembe, hogy ez egy egyszerűsített ábra.Note that this is a simplified view. Az adatgyűjtési szolgáltatás nem feltétlenül egyetlen folyamat, és akár különböző gépeken futó több összetevőből is állhat, amint azt a következő szakaszok ismertetik.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. Továbbá, ha bizonyos telemetriaadatok elemzését gyorsan kell elvégezni (forró elemzés, a dokumentum későbbi, a Forró, meleg és hideg elemzés támogatása című szakaszban leírtak szerint), az adatgyűjtési szolgáltatáson kívül működő helyi összetevők azonnal elvégezhetik az elemzési feladatokat.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. A 2. ábra ezt a helyzetet ábrázolja a kiválasztott eseményekre vonatkozóan.Figure 2 depicts this situation for selected events. Az elemzést követően az eredmények közvetlenül a megjelenítési és riasztási alrendszerbe küldhetők.After analytical processing, the results can be sent directly to the visualization and alerting subsystem. A meleg vagy hideg elemzésnek alávetett adatokat a tároló tárolja, amíg feldolgozásra várnak.Data that's subjected to warm or cold analysis is held in storage while it awaits processing.

Az Azure-alkalmazások és -szolgáltatások esetében az Azure Diagnostics egyetlen lehetséges megoldást kínál az adatok rögzítésére.For Azure applications and services, Azure Diagnostics provides one possible solution for capturing data. Az Azure Diagnostics az egyes számítási csomópontok alábbi forrásaiból gyűjti az adatokat, majd összesíti azokat, és feltölti az Azure Storage-ba:Azure Diagnostics gathers data from the following sources for each compute node, aggregates it, and then uploads it to Azure Storage:

  • IIS-naplókIIS logs
  • sikertelen kéréseket tartalmazó IIS-naplók,IIS Failed Request logs
  • Windows-eseménynaplókWindows event logs
  • TeljesítményszámlálókPerformance counters
  • Összeomlási memóriaképekCrash dumps
  • Azure Diagnostics-infrastruktúranaplókAzure Diagnostics infrastructure logs
  • Egyéni hibanaplókCustom error logs
  • .NET EventSource,.NET EventSource
  • jegyzékalapú ETW.Manifest-based ETW

További információért tekintse meg az Azure-ban használt telemetria alapjait és hibaelhárítását ismertető cikket.For more information, see the article Azure: Telemetry Basics and Troubleshooting.

A rendszerállapot-adatok gyűjtésére vonatkozó stratégiákStrategies for collecting instrumentation data

Figyelembe véve a felhő rugalmas jellegét, és elkerülendő, hogy a telemetriaadatokat manuálisan kelljen lekérni a rendszer minden egyes csomópontjáról, gondoskodjon arról, hogy a rendszer egy központi helyre továbbítsa és ott konszolidálja az adatokat.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. A több adatközpontra is kiterjedő rendszerek esetén először hasznos lehet régiónként gyűjteni, konszolidálni és tárolni az adatokat, majd ezeket a regionális adatokat egyetlen központi rendszerbe összesíteni.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.

A sávszélesség-használat optimalizálása érdekében a kevésbé sürgős adatokat tömbökben, kötegekként is továbbíthatja.To optimize the use of bandwidth, you can elect to transfer less urgent data in chunks, as batches. Az adatokat azonban nem szabad a végtelenségig késleltetni, különösen ha időérzékeny információkat tartalmaznak.However, the data must not be delayed indefinitely, especially if it contains time-sensitive information.

A rendszerállapot-adatok lekérése és leküldésePulling and pushing instrumentation data

A rendszerállapot-adatokat gyűjtő alrendszer aktívan lekérheti a rendszerállapot-adatokat a különféle naplókból és egyéb forrásokból az alkalmazás egyes példányaira vonatkozóan (lekéréses modell).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). Az alrendszer működhet passzív fogadóként is, amely azt várja, hogy az alkalmazás egyes példányait alkotó összetevők elküldjék az adatokat (leküldéses modell).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).

A lekéréses modell megvalósításának egyik módszere az alkalmazás egyes példányaival helyileg futó monitorozási ügynökök használata.One approach to implementing the pull model is to use monitoring agents that run locally with each instance of the application. A monitorozási ügynök egy külön folyamat, amely rendszeres időközönként beolvassa (lekéri) a helyi csomóponton gyűjtött telemetria-adatokat, és ezeket az információkat közvetlenül az alkalmazás összes példánya által közösen használt központi tárolóba írja.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. Az Azure Diagnostics ezt a mechanizmust valósítja meg.This is the mechanism that Azure Diagnostics implements. Az Azure webes vagy feldolgozói szerepköreinek minden példánya konfigurálható a helyben tárolt diagnosztikai és egyéb nyomkövetési adatok gyűjtésére.Each instance of an Azure web or worker role can be configured to capture diagnostic and other trace information that's stored locally. Az egyes példányok mellett futó monitorozási ügynökök átmásolják a meghatározott adatokat az Azure Storage-ba.The monitoring agent that runs alongside each instance copies the specified data to Azure Storage. A folyamattal kapcsolatban a diagnosztikának az Azure Cloud Services és a Virtual Machines szolgáltatásban való engedélyezésével foglalkozó cikk biztosít további információt.The article Enabling Diagnostics in Azure Cloud Services and Virtual Machines provides more details on this process. Bizonyos elemek, például az IIS-naplók, az összeomlási memóriaképek és az egyéni hibanaplók írása blobtárolókba történik.Some elements, such as IIS logs, crash dumps, and custom error logs, are written to blob storage. A Windows-eseménynaplók, ETW-események és a teljesítményszámlálók adatait pedig táblatárolók rögzítik.Data from the Windows event log, ETW events, and performance counters is recorded in table storage. A 3. ábra ezt a mechanizmust ábrázolja.Figure 3 illustrates this mechanism.

Az információk monitorozási ügynök használatával való lekérését és megosztott tárolóba való írását bemutató ábra.

3. ábra – az adatok lekérését és a megosztott tárolóba való írást figyelő ügynök használatával.Figure 3 - Using a monitoring agent to pull information and write to shared storage.

Megjegyzés

A monitorozási ügynökök ideális megoldást jelentenek az adatforrásokból magától értetődően lekért rendszerállapot-adatok rögzítéséhez.Using a monitoring agent is ideally suited to capturing instrumentation data that's naturally pulled from a data source. Ilyen adatok például az SQL Server dinamikus felügyeleti nézeteiből származó adatok vagy az Azure Service Bus-üzenetsor hossza.An example is information from SQL Server Dynamic Management Views or the length of an Azure Service Bus queue.

Az imént ismertetett megközelítés az egy helyen, korlátozott számú csomóponton futó, kisléptékű alkalmazás telemetriaadatainak tárolására is alkalmazható.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. Az összetett, nagy mértékben skálázható, globális, felhőalkalmazások azonban hatalmas mennyiségű adatot állíthatnak elő több száz webes és feldolgozói szerepkörből, adatbázis-szilánkból és egyéb szolgáltatásból.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. Az adatok ilyen mértékű áramlása könnyen túlterhelheti az egyetlen központi helyen rendelkezésre álló I/O-sávszélességet.This flood of data can easily overwhelm the I/O bandwidth available with a single, central location. A telemetriamegoldásnak ezért skálázhatónak kell lennie, nehogy szűk keresztmetszetet jelentsen a rendszer növekedése során.Therefore, your telemetry solution must be scalable to prevent it from acting as a bottleneck as the system expands. Ideális esetben a megoldásnak bizonyos fokú redundanciát is biztosítania kell, így csökkenthető a fontos monitorozási adatok (például a naplózási vagy számlázási adatok) elvesztésének kockázata a rendszer valamelyik részének meghibásodása esetén.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.

Ezen problémák megoldására megvalósítható a sorkezelés, amint az a 4. ábrán látható.To address these issues, you can implement queuing, as shown in Figure 4. Ebben az architektúrában a helyi monitorozási ügynök (ha megfelelően konfigurálható) vagy egy egyéni adatgyűjtési szolgáltatás (ha nem) az adatokat közzé teszi egy üzenetsorban.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. Egy aszinkron módon futó másik folyamat (a 4. ábrán bemutatott tárolóírási szolgáltatás) fogja az üzenetsorban lévő adatokat, és a megosztott tárolóba írja azokat.A separate process running asynchronously (the storage writing service in Figure 4) takes the data in this queue and writes it to shared storage. Az üzenetsorok megfelelő megoldást kínálnak az ilyen forgatókönyvekben, mivel a „legalább egyszeri” szemantikájuk révén biztosítják, hogy az üzenetsorba küldött adatok nem vesznek el a közzétételük után.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. A tárolóírási szolgáltatás egy külön feldolgozói szerepkör használatával valósítható meg.You can implement the storage writing service by using a separate worker role.

A rendszerállapot-adatok üzenetsorral való pufferelésének ábrája.

4. ábra – várólista használata a rendszerállapot-adat puffereléséhez.Figure 4 - Using a queue to buffer instrumentation data.

A helyi adatgyűjtési szolgáltatás közvetlenül a fogadásuk után hozzáadhatja az adatokat az üzenetsorhoz.The local data-collection service can add data to a queue immediately after it's received. Az üzenetsor pufferként szolgál, és így a tárolóírási szolgáltatás a saját tempójában kérheti le és írhatja az adatokat.The queue acts as a buffer, and the storage writing service can retrieve and write the data at its own pace. Alapértelmezés szerint az üzenetsorok érkezési sorrend alapján működnek.By default, a queue operates on a first-in, first-out basis. Az üzenetek azonban rangsorolhatók is, így a gyorsan kezelendő adatokat tartalmazó üzenetek gyorsabban haladhatnak végig az üzenetsoron.But you can prioritize messages to accelerate them through the queue if they contain data that must be handled more quickly. További információ: prioritási várólista mintája.For more information, see the Priority Queue pattern. Használhat más csatornákat (például Service Bus-témaköröket) is az adatok más célhelyekre való irányítására a szükséges elemzési módszertől függően.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.

A skálázhatóság érdekében a tárolóírási szolgáltatás több példányát is futtathatja.For scalability, you can run multiple instances of the storage writing service. Nagy mennyiségű esemény esetén az adatokat egy eseményközpont segítségével irányíthatja különböző számítási erőforrásokhoz feldolgozásra és tárolásra.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.

Rendszerállapot-adatok konszolidálásaConsolidating instrumentation data

Az adatgyűjtési szolgáltatás által az egyes alkalmazáspéldányokról lekért rendszerállapot-adatok alapján az adott példány állapotára és teljesítményére vonatkozó helyi nézet hozható létre.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. A rendszer általános állapotának értékeléséhez az ilyen helyi nézetekben található adatok bizonyos szempontjait konszolidálni kell.To assess the overall health of the system, it's necessary to consolidate some aspects of the data in the local views. Ez az adatok tárolása után tehető meg, bizonyos esetekben azonban már az adatgyűjtés során is megvalósítható.You can perform this after the data has been stored, but in some cases, you can also achieve it as the data is collected. A megosztott tárolóba való közvetlen írás helyett a rendszerállapot-adatok áthaladhatnak egy külön adatkonszolidálási szolgáltatáson, amely egyesíti az adatokat, és egyfajta szűrő- és tisztítófolyamatként is működik.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. Az azonos korrelációs adatokat (például tevékenységazonosítót) tartalmazó rendszerállapot-adatok például egybeolvaszthatók.For example, instrumentation data that includes the same correlation information such as an activity ID can be amalgamated. (Lehetséges, hogy egy felhasználó elindít egy üzleti műveletet egy csomóponton, majd a csomópont meghibásodása esetén egy másik csomópontba kerül át, vagy attól függően, hogy a terheléselosztás hogyan van konfigurálva.) Ezzel a folyamattal észlelheti és eltávolíthatja a duplikált elemeket (mindig lehetősége van arra, hogy a telemetria szolgáltatás üzenetsor használatával leküldi a rendszerállapot-adategységeket a tárolóba).(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). Az 5. ábra erre a struktúrára mutat be egy példát.Figure 5 illustrates an example of this structure.

Példa szolgáltatás használatára a rendszerállapot-adatok konszolidálásához.

5. ábra – a rendszerállapot-adat összevonása és tisztítása külön szolgáltatás használatával.Figure 5 - Using a separate service to consolidate and clean up instrumentation data.

Rendszerállapot-adatok tárolásaStoring instrumentation data

Az előző fejtegetések meglehetősen egyszerű képet festettek a rendszerállapot-adatok tárolásának módjáról.The previous discussions have depicted a rather simplistic view of the way in which instrumentation data is stored. A valóságban azonban célszerű lehet a különböző típusú adatokat olyan technológiák használatával tárolni, amelyek a leginkább megfelelők az egyes típusok vélhető felhasználási módjának.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.

Például az Azure Blob Storage és Table Storage az elérésük szempontjából valamelyest hasonlóak.For example, Azure blob and table storage have some similarities in the way in which they're accessed. A használatukkal végrehajtható műveletek szempontjából azonban bizonyos korlátokkal rendelkeznek, és a bennük tárolt adatok részletessége is igen különböző.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. Ha további elemzési műveleteket kell végrehajtania, vagy teljes szöveges keresési képességekre van szüksége az adatok vonatkozásában, jobb megoldás lehet a különféle lekérdezés- és adathozzáférés-típusokra optimalizált képességeket biztosító adattárakat használni.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. Például:For example:

  • A teljesítményszámlálók adatainak SQL-adatbázisban való tárolása lehetővé teszi az ad hoc elemzést.Performance counter data can be stored in a SQL database to enable ad hoc analysis.
  • A nyomkövetési naplókat érdemesebb lehet az Azure Cosmos DB-ben tárolni.Trace logs might be better stored in Azure Cosmos DB.
  • A biztonsággal kapcsolatos információk a HDFS-be írhatók.Security information can be written to HDFS.
  • A teljes szöveges keresést igénylő információk az Elasticsearch használatával tárolhatók (ami a gazdag indexelésnek köszönhetően növelheti a keresések sebességét).Information that requires full-text search can be stored through Elasticsearch (which can also speed searches by using rich indexing).

Megvalósíthat egy további szolgáltatást is, amely rendszeres időközönként lekéri az adatokat a megosztott tárolóból, a céljuknak megfelelően particionálja és szűri azokat, majd a megfelelő adattárakba írja őket, amint az a 6. ábrán látható.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. Egy másik megközelítés ezen funkció belefoglalása a konszolidálási és tisztítási folyamatba, és az adatoknak közvetlenül ezen tárolókba, nem pedig egy közbenső megosztott tárterületre való írása a lekérésüket követően.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. Mindegyik megközelítésnek vannak előnyei és hátrányai.Each approach has its advantages and disadvantages. Egy külön particionálási szolgáltatás megvalósítása csökkenti a konszolidálási és tisztítási szolgáltatás terhelését, és lehetővé teszi, hogy szükség esetén legalább a particionált adatok egy részét újra létre lehessen hozni (attól függően, hogy mekkora a megosztott tárolóban megőrzött adatok mennyisége).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). Ez azonban további erőforrásokat használ fel.However, it consumes additional resources. Emellett elképzelhető, hogy a rendszerállapot-adatok később érkeznek meg az egyes alkalmazáspéldányokról, és később történik a gyakorlatban használható információkká való átalakításuk.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.

Az adatok particionálása és tárolása

6. ábra – az adatparticionálás az analitikai és a tárolási követelmények alapján.Figure 6 - Partitioning data according to analytical and storage requirements.

Ugyanazok a rendszerállapot-adatok több célból is szükségesek lehetnek.The same instrumentation data might be required for more than one purpose. A teljesítményszámlálók segítségével például megjeleníthető az idő múlásával tapasztalható rendszerteljesítmény előzménynézete.For example, performance counters can be used to provide a historical view of system performance over time. Ezeket az információkat más használati adatokkal egyesítve létrehozhatók az ügyfélre vonatkozó számlázási információk.This information might be combined with other usage data to generate customer billing information. Ilyen esetekben ugyanazokat az adatokat esetleg több célhelyre is továbbítani kell, például a számlázási információk hosszú távú tárolására szolgáló dokumentum-adatbázisba, és a komplex teljesítményelemzés kezelését lehetővé tevő többdimenziós tárolóba.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.

Azt is figyelembe kell venni, hogy mennyire sürgősen van szükség az adatokra.You should also consider how urgently the data is required. A riasztásokhoz szükséges információkat biztosító adatokat gyorsan kell elérni, ezért egy gyors adattárban, indexelve vagy strukturálva kell tárolni őket a riasztási rendszer által végrehajtott lekérdezések optimalizálásához.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. Egyes esetekben szükséges lehet, hogy az egyes csomópontokon az adatokat gyűjtő telemetriaszolgáltatás az adatokat helyben formázza és mentse, hogy a riasztási rendszer helyi példánya gyorsan értesíthesse a felhasználókat a problémákról.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. Ugyanezek az adatok elirányíthatók az előző ábrákon látható tárolóírási szolgáltatásnak, és központilag tárolhatók, ha más célokból is szükség lenne rájuk.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.

Az alaposabb elemzéshez, a jelentéskészítéshez és az előzménytrendek észleléséhez használt információk kevésbé sürgősek, és olyan módon tárolhatók, amely támogatja az adatbányászatot és az ad hoc lekérdezéseket.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. További információért tekintse meg a Forró, meleg és hideg elemzés támogatása című szakaszt a dokumentum későbbi részében.For more information, see the section Supporting hot, warm, and cold analysis later in this document.

Naplóváltás és adatmegőrzésLog rotation and data retention

A rendszerállapot-figyelés jelentős mennyiségű adatot hozhat létre.Instrumentation can generate considerable volumes of data. Ezek az adatok több helyen tárolhatók, az egyes csomópontokon rögzített nyers naplófájloktól, profilelemzési fájloktól és egyéb információktól a megosztott tárolóban található konszolidált, megtisztított és particionált nézetekig.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. Néhány esetben az eredeti nyers forrásadatok eltávolíthatók a csomópontokról az adatok feldolgozását és továbbítását követően.In some cases, after the data has been processed and transferred, the original raw source data can be removed from each node. Más esetekben azonban szükséges vagy egyszerűen csak hasznos lehet menteni a nyers adatokat.In other cases, it might be necessary or simply useful to save the raw information. A hibakeresési célból létrehozott adatokat például jobb lehet nyers formájukban meghagyni, azonban a hibák javítását követően gyorsan elvethetők.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.

A teljesítményadatok általában hosszabb életűek, mivel így felhasználhatók a teljesítménytrendek észlelésére és a kapacitástervezéshez.Performance data often has a longer life so that it can be used for spotting performance trends and for capacity planning. Az ilyen adatok konszolidált nézeteit szokás a gyorsabb elérés érdekében határozott ideig online megőrizni.The consolidated view of this data is usually kept online for a finite period to enable fast access. Ezt követően archiválhatók vagy elvethetők.After that, it can be archived or discarded. A mérési és számlázási célból gyűjtött adatokat néha határozatlan ideig meg kell őrizni.Data gathered for metering and billing customers might need to be saved indefinitely. Emellett szabályozási követelmények is előírhatják, hogy a naplózási és biztonsági célból gyűjtött információkat archiválni és menteni kell.Additionally, regulatory requirements might dictate that information collected for auditing and security purposes also needs to be archived and saved. Ezek az adatok bizalmasak is, és emiatt előfordulhat, hogy titkosítani vagy más módon védeni kell azokat az illetéktelen hozzáférés ellen.This data is also sensitive and might need to be encrypted or otherwise protected to prevent tampering. A felhasználók jelszavait és a személyazonossági csalások elkövetéséhez felhasználható egyéb adatait soha nem szabad rögzíteni.You should never record users' passwords or other information that might be used to commit identity fraud. Ezeket az információkat el kell távolítani az adatokból a mentésük előtt.Such details should be scrubbed from the data before it's stored.

A mintavételezés sebességének csökkentéseDown-sampling

Az előzményadatokat célszerű menteni a hosszú távú trendek felismerése érdekében.It's useful to store historical data so you can spot long-term trends. A régi adatok egészének való mentése helyett azonban csökkenthető az adatok mintavételezésének sebessége az adatok felbontásának és a tárolási költségeknek a csökkentéséhez.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. A percenkénti teljesítménymutatók mentése helyett konszolidálhatja az egy hónapnál régebbi adatokat egy órára lebontott nézet létrehozásához.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.

Ajánlott eljárások a naplózási információk gyűjtéséhez és tárolásáhozBest practices for collecting and storing logging information

Az alábbi lista a naplózási információk gyűjtésére és tárolására vonatkozó ajánlott eljárásokat foglalja össze:The following list summarizes best practices for capturing and storing logging information:

  • A monitorozási ügynököt vagy az adatgyűjtési szolgáltatást futtassa folyamaton kívüli szolgáltatásként, és legyenek egyszerűen üzembe helyezhetők.The monitoring agent or data-collection service should run as an out-of-process service and should be simple to deploy.

  • A monitorozási ügynök vagy az adatgyűjtési szolgáltatás minden kimenetének géptől, operációs rendszertől és hálózati protokolltól független semleges formátummal kell rendelkeznie.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. Az ETL/ETW helyett például az adatok kibocsáthatók egy önleíró formátumban, amilyen a JSON, a MessagePack vagy a Protobuf.For example, emit information in a self-describing format such as JSON, MessagePack, or Protobuf rather than ETL/ETW. A szabványos formátumok használata lehető teszi a rendszer számára feldolgozási folyamatok létrehozását. Az adatokat az egyeztetett formátumban olvasó, átalakító és küldő összetevők könnyen integrálhatók.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.

  • A monitorozási és adatgyűjtési folyamatnak hibamentesnek kell lennie, és nem válthat ki sorozatosan egymásra épülő hibákat.The monitoring and data-collection process must be fail-safe and must not trigger any cascading error conditions.

  • Az információk adatfogadóba való küldésének átmeneti hibája esetén a monitorozási ügynöknek vagy az adatgyűjtési szolgáltatásnak készen kell állni a telemetriaadatok újrarendezésére, hogy a legújabb információk küldése történjen meg először.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. (A monitorozási ügynök/adatgyűjtési szolgáltatás saját belátása szerint dönthet úgy, hogy a régebbi adatokat elveti, vagy helyben menti, és később továbbítja pótlólag.)(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.)

Az adatok elemzése és a problémák diagnosztizálásaAnalyzing data and diagnosing issues

A monitorozási és diagnosztikai folyamat fontos részét képezi a gyűjtött adatok elemzése a rendszer átfogó állapotát mutató kép létrehozása érdekében.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. Már meg kellett határoznia a KPI-ket és a teljesítmény mérőszámait, és fontos megértenie, hogy a gyűjtött adatokat hogyan strukturálhatja az elemzési igényeknek megfelelően.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. Fontos továbbá azt is megértenie, hogy a különböző mérőszámokban és naplófájlokban rögzített adatok korrelálása hogyan történik, mivel ezek az információk kulcsszerepet játszhatnak az események sorozatának nyomon követésében, és segíthetnek diagnosztizálni a felmerülő problémákat.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.

A Rendszerállapot-adatok konszolidálása szakaszban leírtak szerint a rendszer egyes részeire vonatkozó adatok rögzítése helyben történik, azonban általában egyesíteni kell azokat a rendszer részét képező egyéb helyeken keletkező adatokkal.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. Az ilyen információk esetén a korrelálást gondosan kell végezni, hogy az adatok egyesítése pontos legyen.This information requires careful correlation to ensure that data is combined accurately. Egy adott művelethez kapcsolódó használati adatok például magukban foglalhatnak egy olyan webhelyet futtató csomópontot, amelyhez a felhasználó csatlakozott, a művelet keretében elért önálló szolgáltatást futtató másik csomópontot, valamint egy harmadik csomóponton található adattárat.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. Ezeket az információkat össze kell kötni, hogy átfogó képet adjanak a művelet erőforrás- és feldolgozásikapacitás-használatáról.This information needs to be tied together to provide an overall view of the resource and processing usage for the operation. Előfordulhat, hogy az adatfeldolgozás és-szűrés olyan csomóponton történik, amelyen az adat rögzítve van, míg az Összesítés és a formázás nagyobb valószínűséggel egy központi csomóponton történik.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.

Forró, meleg és hideg elemzés támogatásaSupporting hot, warm, and cold analysis

Az adatok megjelenítési, jelentéskészítési és riasztási célú elemzése és újraformázása összetett folyamat lehet, amely saját erőforrásokat használ.Analyzing and reformatting data for visualization, reporting, and alerting purposes can be a complex process that consumes its own set of resources. A monitorozás egyes formái esetében az időtényező kritikus fontosságú, és az adatok azonnali elemzését igénylik.Some forms of monitoring are time-critical and require immediate analysis of data to be effective. Ez a forró elemzés.This is known as hot analysis. Példák erre a riasztásokhoz és a biztonsági monitorozás egyes szempontjaihoz (például a rendszer elleni támadás észlelése) szükséges elemzések.Examples include the analyses that are required for alerting and some aspects of security monitoring (such as detecting an attack on the system). Az ilyen célokból szükséges adatoknak gyorsan elérhetőnek és strukturáltnak kell lenniük a hatékony feldolgozás érdekében.Data that's required for these purposes must be quickly available and structured for efficient processing. Bizonyos esetekben szükség lehet az elemzések feldolgozását az adatokat tároló csomópontokra áthelyezni.In some cases, it might be necessary to move the analysis processing to the individual nodes where the data is held.

Más elemzési formák esetében az időtényező kevésbé fontos, és bizonyos számításokra és összesítésre lehet szükség a nyers adatok fogadását követően.Other forms of analysis are less time-critical and might require some computation and aggregation after the raw data has been received. Ezt nevezzük meleg elemzésnek.This is called warm analysis. A teljesítményelemzés gyakran ebbe a kategóriába esik.Performance analysis often falls into this category. Ebben az esetben egyetlen, elszigetelt teljesítményesemény statisztikailag valószínűleg semmilyen jelentőséggel nem bír.In this case, an isolated, single performance event is unlikely to be statistically significant. (Lehet, hogy hirtelen tüske vagy fénylik okozta.) Az események sorozatából álló adatoknak megbízhatóbb képet kell adniuk a rendszer teljesítményéről.(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.

A meleg elemzés segítséget nyújthat az állapotproblémák diagnosztizálásához is.Warm analysis can also be used to help diagnose health issues. Az állapotesemények feldolgozása általában forró elemzéssel történik, és az esemény azonnal létrehoznak riasztást.A health event is typically processed through hot analysis and can raise an alert immediately. Az operátornak képesnek kell lennie elemezni az állapotesemény okait a meleg folyamatból származó adatok vizsgálatával.An operator should be able to drill into the reasons for the health event by examining the data from the warm path. Ezeknek az adatoknak az állapoteseményt okozó problémához vezető eseményekkel kapcsolatos információkat kell tartalmazniuk.This data should contain information about the events leading up to the issue that caused the health event.

A monitorozás bizonyos típusai hosszabb távú adatokat állítanak elő.Some types of monitoring generate more long-term data. Ez az elemzés egy későbbi időpontban is végrehajtható, akár egy előre meghatározott ütemezés szerint is.This analysis can be performed at a later date, possibly according to a predefined schedule. Bizonyos esetekben az elemzés során hosszabb időn keresztül rögzített, nagy mennyiségű adat összetett szűrését kell végrehajtani.In some cases, the analysis might need to perform complex filtering of large volumes of data captured over a period of time. Ezt nevezzük hideg elemzésnek.This is called cold analysis. A legfontosabb követelmény, hogy az adatok biztonságos helyen legyenek tárolva a rögzítést követően.The key requirement is that the data is stored safely after it has been captured. A használat monitorozásához és a naplózáshoz a rendszer állapotáról rendszeres időközönként készült pontos képekre van szükség, azonban az ilyen állapotadatoknak nem kell azonnal rendelkezésre állniuk feldolgozásra az adatgyűjtést követően.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.

Az operátor hideg elemzéssel is biztosíthatja az adatokat a prediktív állapotelemzéshez.An operator can also use cold analysis to provide the data for predictive health analysis. Az operátor az aktuális állapotadatokat (ezek a forró elemzési folyamatból származnak) egy megadott időszakban gyűjtött előzményadatokkal kiegészítve derítheti fel azokat a trendeket, amelyek hamarosan állapotproblémákat okozhatnak.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. Ezekben az esetekben riasztás létrehozása lehet szükséges, hogy korrekciós műveleteket lehessen végrehajtani.In these cases, it might be necessary to raise an alert so that corrective action can be taken.

Az adatok korrelálásaCorrelating data

A rendszerállapot-figyelés által rögzített adatok pillanatképet biztosíthatnak a rendszer állapotáról, az elemzés célja azonban az, hogy ezek az adatok hasznosíthatók legyenek a gyakorlatban.The data that instrumentation captures can provide a snapshot of the system state, but the purpose of analysis is to make this data actionable. Például:For example:

  • Mi okozta az intenzív, rendszerszintű I/O-terhelést egy adott időpontban?What has caused an intense I/O loading at the system level at a specific time?
  • Nagyszámú adatbázis-művelet miatt volt?Is it the result of a large number of database operations?
  • Kimutathatók a hatásai az adatbázis válaszidejében, a tranzakciók másodpercenkénti számában, valamint az alkalmazás válaszidejében ugyanezen a csomóponton?Is this reflected in the database response times, the number of transactions per second, and application response times at the same juncture?

Ha igen, a terhelést csökkentő javítóintézkedés lehet az adatok szétosztása több kiszolgálóra.If so, one remedial action that might reduce the load might be to shard the data over more servers. Ezenkívül kivételek jöhetnek létre a rendszer valamelyik szintjén fellépő hiba eredményeként.In addition, exceptions can arise as a result of a fault in any level of the system. Egy adott szinten felmerülő kivétel gyakran egy újabb hibát vált ki az eggyel magasabb szinten.An exception in one level often triggers another fault in the level above.

Ebből kifolyólag az egyes szintek különböző típusú monitorozási adatait tudnia kell korrelálni a rendszer és az azon futó alkalmazások állapotát mutató átfogó kép létrehozásához.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. Ezután ezen információk segítségével eldöntheti, hogy a rendszer megfelelően működik-e vagy sem, és meghatározhatja a szükséges intézkedéseket a rendszer minőségének a javítására.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.

Az Információk az adatok korrelálásához című szakaszban leírtak szerint gondoskodjon arról, hogy a nyers rendszerállapot-adatok elegendő környezeti és tevékenységazonosító-információkat tartalmazzanak az események korrelálásához szükséges összesítések támogatásához.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. Az adatok tárolása emellett különböző formátumokban történhet, ezért szükség lehet az elemzésükre, így szabványos formátumba konvertálhatók elemzéshez.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.

Hibaelhárítás és a problémák diagnosztizálásaTroubleshooting and diagnosing issues

A diagnosztika elvégzéséhez meg kell tudni állapítani a hibák vagy a váratlan működés okait, például a kiváltó okok elemzésével.Diagnosis requires the ability to determine the cause of faults or unexpected behavior, including performing root cause analysis. Az ehhez szükséges információk általában az alábbiak:The information that's required typically includes:

  • Az eseménynaplókból és nyomkövetési adatokból származó részletes információk a rendszer egészére vagy egy adott alrendszerre vonatkozóan egy adott időszakból.Detailed information from event logs and traces, either for the entire system or for a specified subsystem during a specified time window.
  • A rendszerben vagy egy adott alrendszerben egy adott időszak során fellépő bármilyen adott szintű kivételek vagy hibák eredményeként keletkezett teljes hívásláncok.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.
  • A rendszerben bárhol vagy egy adott alrendszerben egy adott időszak során meghiúsult folyamatok összeomlási memóriaképei.Crash dumps for any failed processes either anywhere in the system or for a specified subsystem during a specified time window.
  • Az összes felhasználó vagy a kiválasztott felhasználók által egy adott időszakban végrehajtott műveleteket rögzítő tevékenységnaplók.Activity logs recording the operations that are performed either by all users or for selected users during a specified period.

Az adatok hibakeresési célú elemzéséhez gyakran a rendszer-architektúra és a megoldást alkotó különféle összetevők részletes műszaki ismerete szükséges.Analyzing data for troubleshooting purposes often requires a deep technical understanding of the system architecture and the various components that compose the solution. Ennek következtében az adatok értelmezéséhez, a hibák okainak megállapításához és a megfelelő javítási stratégia ajánlásához gyakran jelentős manuális beavatkozásra van szükség.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. Ezért célszerű lehet ezekről az információkról csupán egy másolatot tárolni az eredeti formátumban, és azt egy szakértőnek hideg elemzésre átadni.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.

Adatok megjelenítése és riasztások létrehozásaVisualizing data and raising alerts

Minden monitorozási rendszer fontos eleme az adatok olyan formában való megjelenítése, amelynek révén az operátor gyorsan észreveheti a trendeket vagy a problémákat.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. Emellett fontos az is, hogy az operátort gyorsan értesíteni lehessen, ha valami olyan jelentős esemény következik be, amely figyelmet igényelhet.Also important is the ability to quickly inform an operator if a significant event has occurred that might require attention.

Az adatok megjelenítése különféle formákat ölthet, beleértve az irányítópultokon való megjelenítést, a riasztásokat és a jelentéseket.Data presentation can take several forms, including visualization by using dashboards, alerting, and reporting.

Megjelenítés irányítópultok használatávalVisualization by using dashboards

Az adatok megjelenítésének leggyakoribb módja az irányítópultok használata, amelyek diagramokkal, grafikonokkal vagy egyéb ábrákkal jelenítik meg az információkat.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. Ezek az elemek paraméterekkel rendelkeznek, és az elemzőknek minden helyzethez ki kell tudniuk választani a fontos paramétereket (például az időszakot).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.

Az irányítópultok hierarchikusan rendezhetők.Dashboards can be organized hierarchically. A legfelső szintű irányítópultok átfogó képet adhatnak a rendszer egyes funkcióiról, azonban lehetővé teszik az operátor számára az adatok részletes elemzését.Top-level dashboards can give an overall view of each aspect of the system but enable an operator to drill down to the details. A rendszer lemezeinek átfogó I/O-teljesítményét ábrázoló irányítópulton például az elemzőnek meg kell tudnia tekinteni az egyes lemezek I/O-teljesítményét is, így megállapíthatja, hogy a nem egyenletes forgalomért egy vagy több eszköz-e a felelős.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. Ideális esetben az irányítópulton kapcsolódó információk is megjelennek, például az I/O-forgalmat létrehozó kérések forrása (a felhasználó vagy a tevékenység).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. Ezeknek az információknak a használatával meghatározható, hogy a terhelést egyenletesebben kell-e elosztani az eszközök között (és hogy miként), valamint hogy a rendszer jobban teljesítene-e az eszközök számának növelése esetén.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.

Az irányítópultokon színkódolás vagy valamilyen más vizuális jelölésrendszer is alkalmazható a rendellenes vagy a várt tartományon kívül eső értékek jelzésére.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. Az előző példával élve:Using the previous example:

  • A hosszabb időn keresztül a maximális kapacitáshoz közeli I/O-sebességgel üzemelő lemezek (forró lemez) vörös színnel jelölhetők.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.
  • Az időnként rövid ideig a maximális kapacitásnak megfelelő I/O-sebességgel üzemelő lemezek (meleg lemez) sárga színnel jelölhetők.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.
  • A normál használatot mutató lemezek zöld színnel jelölhetők.A disk that's exhibiting normal usage can be displayed in green.

Ahhoz, hogy egy irányítópult-rendszer hatékonyan működjön, rendelkeznie kell a feldolgozható nyers adatokkal.Note that for a dashboard system to work effectively, it must have the raw data to work with. Ha saját irányítópult-rendszert hoz létre, vagy egy másik vállalat által fejlesztett irányítópultot használ, tisztában kell lennie azzal, hogy milyen rendszerállapot-adatokat kell gyűjtenie, milyen részletességi szinten, és hogyan kell formázni azokat, hogy az irányítópult fel tudja használni őket.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.

Egy jó irányítópult nem csupán megjeleníti az információkat, hanem azt is lehetővé teszi, hogy az elemző ad hoc kérdéseket tegyen fel az információkkal kapcsolatban.A good dashboard does not only display information, it also enables an analyst to pose ad hoc questions about that information. Egyes rendszerek felügyeleti eszközöket is biztosítanak, amelyek használatával az operátor végrehajthatja ezeket a műveleteket, és áttekintheti a mögöttes adatokat.Some systems provide management tools that an operator can use to perform these tasks and explore the underlying data. Az információk tárolásához használt adattártól függően az is előfordulhat, hogy az adatok közvetlenül is lekérdezhetők, vagy további elemzés és jelentéskészítés céljával olyan eszközökbe importálhatók, mint a Microsoft Excel.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.

Megjegyzés

Az irányítópultokhoz való hozzáférést érdemes az arra jogosult személyekre korlátozni, mivel az információk üzleti szempontból bizalmasak lehetnek.You should restrict access to dashboards to authorized personnel, because this information might be commercially sensitive. Érdemes továbbá az irányítópultok alapjául szolgáló adatokat védeni, hogy a felhasználók ne módosíthassák azokat.You should also protect the underlying data for dashboards to prevent users from changing it.

Riasztások létrehozásaRaising alerts

A riasztás a monitorozási és rendszerállapot-adatok elemzésének, és jelentős esemény észlelése esetén értesítések létrehozásának a folyamata.Alerting is the process of analyzing the monitoring and instrumentation data and generating a notification if a significant event is detected.

A riasztás hozzájárul a rendszer megfelelő állapotának, válaszkészségének és biztonságának a fenntartásához.Alerting helps ensure that the system remains healthy, responsive, and secure. Fontos része minden olyan rendszernek, amely teljesítmény-, rendelkezésreállási és adatvédelmi garanciákat vállal a felhasználók felé, akiknek az adatok alapján azonnal cselekedni kell.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. Előfordulhat, hogy az operátort értesíteni kell a riasztást kiváltó eseményről.An operator might need to be notified of the event that triggered the alert. A riasztási használható az olyan rendszerfunkciók indítására is, mint az automatikus skálázás.Alerting can also be used to invoke system functions such as autoscaling.

A riasztási általában az alábbi rendszerállapot-adatoktól függ:Alerting usually depends on the following instrumentation data:

  • Biztonsági események.Security events. Ha az eseménynaplók azt jelzik, hogy ismételt hitelesítési és/vagy jogosultsági hibák lépnek fel, elképzelhető, hogy a rendszer támadás alatt áll, és az operátort tájékoztatni kell.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.
  • Teljesítmény-mérőszámok.Performance metrics. A rendszernek gyorsan kell reagálnia, ha egy adott teljesítmény-mérőszám meghalad egy megadott küszöbértéket.The system must quickly respond if a particular performance metric exceeds a specified threshold.
  • Rendelkezésre állási információk.Availability information. Hiba észlelése esetén szüksége lehet egy vagy több alrendszer gyors újraindítására, vagy egy másodlagos erőforrásra való feladatátvételre.If a fault is detected, it might be necessary to quickly restart one or more subsystems, or fail over to a backup resource. Amennyiben egyes alrendszerekben ismétlődő hibák tapasztalhatók, ez komolyabb problémákra utalhat.Repeated faults in a subsystem might indicate more serious concerns.

Az operátorok számos különféle csatornán keresztül kaphatják meg a riasztásokat, például e-mailben, személyhívón vagy SMS-üzenetben.Operators might receive alert information by using many delivery channels such as email, a pager device, or an SMS text message. A riasztások tartalmazhatnak a helyzet súlyosságára utaló adatokat is.An alert might also include an indication of how critical a situation is. Számos riasztási rendszer támogatja az előfizetői csoportokat, így az azonos csoportban lévő operátorok ugyanazokat a riasztásokat kapják meg.Many alerting systems support subscriber groups, and all operators who are members of the same group can receive the same set of alerts.

A riasztási rendszereknek testreszabhatónak kell lenniük, és ehhez a mögöttes rendszerállapot-adatok megfelelő értékei szolgálhatnak paraméterként.An alerting system should be customizable, and the appropriate values from the underlying instrumentation data can be provided as parameters. Ez a megközelítés lehetővé teszi, hogy az operátor az adatok szűrésével a fontos küszöbértékekre és értékkombinációkra összpontosíthasson.This approach enables an operator to filter data and focus on those thresholds or combinations of values that are of interest. Vegye figyelembe, hogy egyes esetekben a nyers rendszerállapot-adatok biztosíthatók a riasztási rendszer számára.Note that in some cases, the raw instrumentation data can be provided to the alerting system. Más esetekben azonban célszerűbb összesített adatokat biztosítani.In other situations, it might be more appropriate to supply aggregated data. (Egy riasztás kiváltására például akkor kerülhet sor, amikor a processzor kihasználtsága az elmúlt 10 percben meghaladta a 90 százalékot.)(For example, an alert can be triggered if the CPU utilization for a node has exceeded 90 percent over the last 10 minutes). A riasztási rendszernek biztosított információknak tartalmaznia kell a megfelelő összegzési és környezeti adatokat is.The details provided to the alerting system should also include any appropriate summary and context information. Az ilyen adatok segítségével csökkenthető a vakriasztások esélye.This data can help reduce the possibility that false-positive events will trip an alert.

JelentéskészítésReporting

A jelentéskészítés segítségével egy általános áttekintés készíthető a rendszerről.Reporting is used to generate an overall view of the system. Az áttekintés tartalmazhat előzményadatokat is az aktuális információk mellett.It might incorporate historical data in addition to current information. A jelentéskészítésre vonatkozó követelmények két nagyobb kategóriába sorolhatók: működési jelentések és biztonsági jelentések.Reporting requirements themselves fall into two broad categories: operational reporting and security reporting.

A működési jelentések általában az alábbi szempontokat érintik:Operational reporting typically includes the following aspects:

  • A statisztikai adatok összesítésével megismerheti a teljes rendszer vagy a megadott alrendszerek erőforrás-kihasználtságát egy adott időszakra vonatkozóan.Aggregating statistics that you can use to understand resource utilization of the overall system or specified subsystems during a specified time window.
  • Az erőforrás-használat trendjeinek azonosítása a teljes rendszer vagy a megadott alrendszerek esetében egy adott időszakban.Identifying trends in resource usage for the overall system or specified subsystems during a specified period.
  • A rendszer vagy a megadott alrendszerek során bekövetkezett kivételek figyelése egy adott időszakban.Monitoring the exceptions that have occurred throughout the system or in specified subsystems during a specified period.
  • Az alkalmazás hatékonyságának meghatározása a központilag telepített erőforrások tekintetében, és annak megértése, hogy az erőforrások mennyisége (és a hozzájuk kapcsolódó költségek) csökkenthető-e anélkül, hogy a teljesítmény szükségtelen lenne.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.

A biztonsági jelentések a rendszer felhasználók általi használatának nyomon követésével foglalkoznak.Security reporting is concerned with tracking customers' use of the system. Az alábbiakra terjedhetnek ki:It can include:

  • Felhasználói műveletek naplózása.Auditing user operations. Ehhez rögzíteni kell az egyes felhasználók által végrehajtott kéréseket, azok dátum- és időadataival együtt.This requires recording the individual requests that each user performs, together with dates and times. Az adatokat megfelelően strukturálni kell, hogy a rendszergazda gyorsan rekonstruálhassa az egyes felhasználók által az adott időszakban végrehajtott műveletek sorát.The data should be structured to enable an administrator to quickly reconstruct the sequence of operations that a user performs over a specified period.
  • A felhasználó által használt erőforrások nyomon követése.Tracking resource use by user. Ehhez rögzíteni kell, hogy egy adott felhasználó egyes kérései hogyan és milyen hosszan férnek hozzá a rendszert alkotó különböző erőforrásokhoz.This requires recording how each request for a user accesses the various resources that compose the system, and for how long. A rendszergazdának az adatok használatával képesnek kell lennie a használatról szóló, felhasználókon alapuló, adott időszakra vonatkozó jelentés létrehozására, például számlázási célból.An administrator must be able to use this data to generate a utilization report by user over a specified period, possibly for billing purposes.

Sok esetben kötegelt folyamatok is létrehozhatnak jelentéseket egy meghatározott ütemezés szerint.In many cases, batch processes can generate reports according to a defined schedule. (A késés általában nem jelent problémát.) Azonban szükség esetén az ad hoc alapon is elérhetőnek kell lenniük a létrehozáshoz.(Latency is not normally an issue.) But they should also be available for generation on an ad hoc basis if needed. Ha például az adatait egy relációs adatbázisban, például az Azure SQL Database-ben tárolja, egy eszköz, például az SQL Server Reporting Services segítségével kinyerheti és formázhatja az adatokat, és megjelenítheti azokat különféle jelentésekben.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.

  • Útmutató az automatikus skálázáshoz: azt ismerteti, hogy hogyan csökkenthetők a felügyeleti terhek, ha kevésbé van szükség olyan operátorra, aki folyamatosan monitorozza a rendszer teljesítményét, és döntéseket hoz az erőforrások hozzáadásáról vagy eltávolításáról.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.
  • Az állapot-végpont figyelési mintája leírja, hogyan kell végrehajtani a funkcionális ellenőrzéseket egy alkalmazáson belül, ha a külső eszközök rendszeres időközönként hozzáférhetnek a kitett végpontokon keresztül.Health Endpoint Monitoring pattern describes how to implement functional checks within an application that external tools can access through exposed endpoints at regular intervals.
  • A prioritási várólista mintája azt mutatja be, hogyan rangsorolhatja a várólistán lévő üzeneteket, hogy a rendszer sürgős kérelmeket fogadjon, és feldolgozza a kevésbé sürgős üzenetek előtt.Priority Queue pattern shows how to prioritize queued messages so that urgent requests are received and can be processed before less urgent messages.

Következő lépésekNext steps