Állapot végponti monitorozását végző mintaHealth Endpoint Monitoring pattern

Rendszeres időközönként működés-ellenőrzéseket implementálhat egy alkalmazásban, amelyhez az elérhetővé tett végpontokon keresztül hozzáférhetnek külső eszközök.Implement functional checks in an application that external tools can access through exposed endpoints at regular intervals. Ennek segítségével ellenőrizheti, hogy az alkalmazások és szolgáltatások megfelelően működnek-e.This can help to verify that applications and services are performing correctly.

Kontextus és problémaContext and problem

A webalkalmazások és háttérszolgáltatások monitorozása bevált gyakorlat, és gyakran üzleti elvárás is. Ezzel biztosítható, hogy elérhetőek legyenek és megfelelően működjenek.It's a good practice, and often a business requirement, to monitor web applications and back-end services, to ensure they're available and performing correctly. A felhőben futó szolgáltatások monitorozása azonban bonyolultabb, mint a helyszíni szolgáltatásoké.However, it's more difficult to monitor services running in the cloud than it is to monitor on-premises services. Nem rendelkezik például teljes körű hozzáféréssel az üzemeltetési környezethez, emellett a szolgáltatások általában más, platformszolgáltatók és mások által biztosított szolgáltatásoktól függnek.For example, you don't have full control of the hosting environment, and the services typically depend on other services provided by platform vendors and others.

Számos tényező befolyásolja a felhőben üzemeltetett alkalmazásokat, például a hálózati késés, a mögöttes számítási és tárolórendszerek teljesítménye és rendelkezésre állása, valamint a köztük lévő hálózati sávszélesség.There are many factors that affect cloud-hosted applications such as network latency, the performance and availability of the underlying compute and storage systems, and the network bandwidth between them. E tényezők miatt a szolgáltatás működése részben vagy teljesen meghiúsulhat.The service can fail entirely or partially due to any of these factors. Ezért rendszeres időközönként ellenőriznie kell, hogy a szolgáltatás megfelelően működik-e, hogy biztosítsa a szükséges szintű rendelkezésre állást, amely része lehet a szolgáltatói szerződésnek (SLA).Therefore, you must verify at regular intervals that the service is performing correctly to ensure the required level of availability, which might be part of your service level agreement (SLA).

MegoldásSolution

Az alkalmazás végpontjaira való kérések küldésével megvalósíthatja az állapotmonitorozást.Implement health monitoring by sending requests to an endpoint on the application. Az alkalmazásnak el kell végeznie a szükséges ellenőrzéseket, és vissza kell adnia egy jelzést az állapotra vonatkozóan.The application should perform the necessary checks, and return an indication of its status.

Az állapotmonitorozási ellenőrzés általában két tényezőt ötvöz:A health monitoring check typically combines two factors:

  • Az alkalmazás vagy szolgáltatás által, az állapot-ellenőrzési végpontra küldött kérésre válaszul végrehajtott ellenőrzések (ha van ilyen).The checks (if any) performed by the application or service in response to the request to the health verification endpoint.
  • Az állapotellenőrzést végző eszköz vagy keretrendszer által végrehajtott eredményelemzés.Analysis of the results by the tool or framework that performs the health verification check.

A válaszkód jelzi az alkalmazás és igény szerint az alkalmazás által használt bármely összetevő vagy szolgáltatás állapotát.The response code indicates the status of the application and, optionally, any components or services it uses. A késleltetés vagy válaszidő ellenőrzését a monitorozó eszköz vagy keretrendszer végzi.The latency or response time check is performed by the monitoring tool or framework. Az ábra áttekintést nyújt a mintáról.The figure provides an overview of the pattern.

A minta áttekintése

Az egyéb ellenőrzések, amelyeket az állapotmonitorozási kód végrehajthat az alkalmazásban többek között a következők lehetnek:Other checks that might be carried out by the health monitoring code in the application include:

  • Felhőalapú tárolók vagy adatbázisok rendelkezésre állásának és válaszidejének ellenőrzése.Checking cloud storage or a database for availability and response time.
  • Az alkalmazásban vagy máshol található (de az alkalmazás által használt) egyéb erőforrások vagy szolgáltatások ellenőrzése.Checking other resources or services located in the application, or located elsewhere but used by the application.

Elérhetők olyan szolgáltatások és eszközök is, amelyek azáltal monitorozzák a webalkalmazásokat, hogy kérést küldenek egy konfigurálható végpontkészletre, és konfigurálható szabályok alapján kiértékelik az eredményeket.Services and tools are available that monitor web applications by submitting a request to a configurable set of endpoints, and evaluating the results against a set of configurable rules. Viszonylag egyszerű olyan szolgáltatásvégpontot létrehozni, amelynek egyetlen célja az, hogy funkcióteszteket hajtson végre a rendszeren.It's relatively easy to create a service endpoint whose sole purpose is to perform some functional tests on the system.

A monitorozási eszközökkel elvégezhető általános ellenőrzések:Typical checks that can be performed by the monitoring tools include:

  • A válaszkód ellenőrzése.Validating the response code. Például a 200-as (OK) kódú HTTP-válasz azt jelzi, hogy az alkalmazás hiba nélkül válaszolt.For example, an HTTP response of 200 (OK) indicates that the application responded without error. Elképzelhető, hogy a monitorozási rendszer más válaszkódokat is ellenőriz annak érdekében, hogy átfogóbb eredményeket adjon vissza.The monitoring system might also check for other response codes to give more comprehensive results.
  • A válasz tartalmának ellenőrzése a hibák észlelése érdekébe, még akkor is, ha a rendszer 200-as (OK) állapotkódot adott vissza.Checking the content of the response to detect errors, even when a 200 (OK) status code is returned. Ezáltal észlelhetők olyan hibák, amelyek a weblap vagy szolgáltatás visszaadott válaszának csak egy részét érintik.This can detect errors that affect only a section of the returned web page or service response. Ilyen például az oldalak címének ellenőrzése, vagy adott kifejezés keresése, amely azt jelzi, hogy a megfelelő oldal lett visszaadva.For example, checking the title of a page or looking for a specific phrase that indicates the correct page was returned.
  • A válaszidő mérése, amely a hálózati késésből és az alkalmazás által, a kérés végrehajtásához felhasznált időből tevődik össze.Measuring the response time, which indicates a combination of the network latency and the time that the application took to execute the request. A növekvő érték egy probléma megjelenését jelezheti az alkalmazásban vagy a hálózatban.An increasing value can indicate an emerging problem with the application or network.
  • Az alkalmazáson kívüli erőforrások vagy szolgáltatások ellenőrzése, ilyen például a tartalomkézbesítési hálózat, amelyet az alkalmazás globális gyorsítótárakból származó tartalmak továbbítására használ.Checking resources or services located outside the application, such as a content delivery network used by the application to deliver content from global caches.
  • SSL-tanúsítványok lejáratának ellenőrzése.Checking for expiration of SSL certificates.
  • Az alkalmazás URL-címére irányuló DNS-címkeresés válaszidejének mérése, amellyel a DNS-késés és DNS-hibák mérhetők.Measuring the response time of a DNS lookup for the URL of the application to measure DNS latency and DNS failures.
  • A DNS-címkeresés által visszaadott URL-cím ellenőrzése, amellyel biztosítható, hogy a bejegyzések helyesek.Validating the URL returned by the DNS lookup to ensure correct entries. Ezzel elkerülhető a DNS-kiszolgáló elleni sikeres támadással indított rosszindulatú kérelemátirányítás.This can help to avoid malicious request redirection through a successful attack on the DNS server.

Emellett ahol lehetséges, hasznos lehet lefuttatni ezeket az ellenőrzéseket különböző helyszíni vagy üzemeltetési helyeken a válaszidők mérésének és összehasonlításának érdekében.It's also useful, where possible, to run these checks from different on-premises or hosted locations to measure and compare response times. Ha lehetséges, olyan helyekről monitorozza az alkalmazásokat, amelyek az ügyfelek közelében találhatók, hogy pontos képet kapjon az egyes helyek teljesítményéről.Ideally you should monitor applications from locations that are close to customers to get an accurate view of the performance from each location. Amellett, hogy ez hatékonyabb ellenőrzési mechanizmust biztosít, az eredmények alapján dönthet az alkalmazás üzembehelyezési helyéről, és arról, hogy telepíti-e egynél több adatközpontban.In addition to providing a more robust checking mechanism, the results can help you decide on the deployment location for the application—and whether to deploy it in more than one datacenter.

Érdemes teszteket futtatni az ügyfelek által használt összes szolgáltatáspéldányon, hogy meggyőződjön róla, az alkalmazás minden ügyfél esetében megfelelően működik.Tests should also be run against all the service instances that customers use to ensure the application is working correctly for all customers. Ha például az ügyfél tárfiókja több mint egy tárfiókra kiterjed, a monitorozási folyamatnak az összeset ellenőriznie kell.For example, if customer storage is spread across more than one storage account, the monitoring process should check all of these.

Problémák és megfontolandó szempontokIssues and considerations

A minta megvalósítása során az alábbi pontokat vegye figyelembe:Consider the following points when deciding how to implement this pattern:

A válasz érvényesítésének módja.How to validate the response. Például elég csupán egyetlen 200-as (OK) állapotkód annak ellenőrzésére, hogy megfelelően működik-e az alkalmazás?For example, is just a single 200 (OK) status code sufficient to verify the application is working correctly? Habár ez az alkalmazás rendelkezésre állásának legegyszerűbb mérési módja, illetve a minta legalapvetőbb implementációja, kevés információt biztosít a műveletekről, trendekről és az alkalmazásban lehetségesen felmerülő hibákról.While this provides the most basic measure of application availability, and is the minimum implementation of this pattern, it provides little information about the operations, trends, and possible upcoming issues in the application.

Győződjön meg arról, hogy az alkalmazás csak akkor ad vissza 200 (OK) állapotkódot, amikor a rendszer megtalálta és feldolgozta a célerőforrást.Make sure that the application correctly returns a 200 (OK) only when the target resource is found and processed. Egyes forgatókönyvekben, például akkor, amikor mesteroldalt használ a célweboldal üzemeltetéséhez, a kiszolgáló a 404-es (Nem található) kód helyett a 200-as (OK) állapotkódot küldi vissza, még akkor is, ha a céltartalomoldal nem található.In some scenarios, such as when using a master page to host the target web page, the server sends back a 200 (OK) status code instead of a 404 (Not Found) code, even when the target content page was not found.

Az alkalmazás számára elérhető végpontok száma.The number of endpoints to expose for an application. Az egyik lehetőség elérhetővé tenni legalább egy végpontot az alkalmazás által használt alapszolgáltatások számára, és egy másikat az alacsonyabb prioritású szolgáltatások számára, hogy különböző fontossági szintek legyenek hozzárendelve az egyes monitorozási eredményekhez.One approach is to expose at least one endpoint for the core services that the application uses and another for lower priority services, allowing different levels of importance to be assigned to each monitoring result. Emellett érdemes lehet elérhetővé tenni több végpontot, például egyet minden alapszolgáltatás számára, hogy a monitorozás még részletesebb legyen.Also consider exposing more endpoints, such as one for each core service, for additional monitoring granularity. Az állapotellenőrzések például ellenőrizhetik az adatbázist, a tárolót és az alkalmazás által használt külső geokódolási szolgáltatásokat, amelyek mindegyike különböző szintű üzemidőt és válaszidőt igényel.For example, a health verification check might check the database, storage, and an external geocoding service that an application uses, with each requiring a different level of uptime and response time. Az alkalmazás akkor is megfelelő állapotban lehet, ha a geokódolási szolgáltatás vagy valamely másik háttérfeladat nem érhető el néhány percig.The application could still be healthy if the geocoding service, or some other background task, is unavailable for a few minutes.

Használható-e az általános hozzáférésre használt végpont monitorozásra, de az állapot-ellenőrzésekre tervezett egyedi elérési úton, például /HealthCheck/{GUID}/ az általános hozzáférési végponton?Whether to use the same endpoint for monitoring as is used for general access, but to a specific path designed for health verification checks, for example, /HealthCheck/{GUID}/ on the general access endpoint. Ez lehetővé teszi, hogy a monitorozási eszközök lefuttassanak néhány funkciótesztet az alkalmazásban (ilyen például az új felhasználói regisztrációk hozzáadása, a bejelentkezés és a tesztmegrendelés felvétele), miközben ellenőrzik, hogy az általános hozzáférési végpont elérhető-e.This allows some functional tests in the application to be run by the monitoring tools, such as adding a new user registration, signing in, and placing a test order, while also verifying that the general access endpoint is available.

A szolgáltatásban a monitorozási kérésekre válaszul gyűjtendő információk típusa, és ezek visszaadásának módja.The type of information to collect in the service in response to monitoring requests, and how to return this information. A legtöbb meglévő eszköz és keretrendszer csak a végpont által visszaadott HTTP-állapotkódot figyeli.Most existing tools and frameworks look only at the HTTP status code that the endpoint returns. További információk visszaadásához és érvényesítéséhez elképzelhető, hogy létre kell hoznia egy egyéni monitorozási segédprogramot vagy szolgáltatást.To return and validate additional information, you might have to create a custom monitoring utility or service.

A gyűjtendő információ mennyisége.How much information to collect. Ha a rendszer túlzott mértékű feldolgozást végez az ellenőrzés alatt, az túlterhelheti az alkalmazást, és hatással lehet más felhasználókra.Performing excessive processing during the check can overload the application and impact other users. A szükséges idő meghaladhatja a monitorozási rendszer időkorlátját, így az nem elérhetőnek jelzi az alkalmazást.The time it takes might exceed the timeout of the monitoring system so it marks the application as unavailable. A legtöbb alkalmazásban találhatók például hibakezelők és teljesítményszámlálók, amelyek naplózzák a teljesítményt és a hibákkal kapcsolatos részletes információkat. Ez is elegendő lehet az állapotellenőrzésre vonatkozó bővebb információk visszaadása helyett.Most applications include instrumentation such as error handlers and performance counters that log performance and detailed error information, this might be sufficient instead of returning additional information from a health verification check.

A végpont állapotának gyorsítótárazása.Caching the endpoint status. Az állapot-ellenőrzés túl gyakori futtatása költséges lehet.It could be expensive to run the health check too frequently. Ha például az állapotjelentés egy irányítópulton keresztül történik, nem szeretnénk, hogy az irányítópultból érkező minden kérés állapot-ellenőrzést indítson el.If the health status is reported through a dashboard, for example, you don't want every request from the dashboard to trigger a health check. Helyette azt szeretnénk, hogy időszakosan ellenőrizze a rendszer állapotát és gyorsítótárazza azt.Instead, periodically check the system health and cache the status. Tegyen elérhetővé egy végpontot, amely visszaadja a gyorsítótárazott állapotot.Expose an endpoint that returns the cached status.

Hogyan konfiguráljuk a monitorozási végpontok biztonságát annak érdekében, hogy védve legyenek a nyilvános hozzáféréstől, amely rosszindulatú támadásoknak teheti ki az alkalmazást, bizalmas információkat szivárogtathat ki vagy szolgáltatásmegtagadási (DoS-) támadásokat vonzhat be.How to configure security for the monitoring endpoints to protect them from public access, which might expose the application to malicious attacks, risk the exposure of sensitive information, or attract denial of service (DoS) attacks. Ezt általában az alkalmazás konfigurációjában kell megadni, hogy könnyen frissíthető legyen az alkalmazás újraindítása nélkül.Typically this should be done in the application configuration so that it can be updated easily without restarting the application. Fontolja meg az alábbi módszerek alkalmazását:Consider using one or more of the following techniques:

  • Tegye biztonságossá a végpontot azáltal, hogy kötelezővé teszi a hitelesítést.Secure the endpoint by requiring authentication. Ezt egy hitelesítési biztonsági kulcs a kérés fejlécében való megadásával teheti meg, vagy úgy, hogy hitelesítő adatokat továbbít a kérelemmel együtt, feltéve, hogy a monitorozási szolgáltatás vagy az eszköz támogatja a hitelesítést.You can do this by using an authentication security key in the request header or by passing credentials with the request, provided that the monitoring service or tool supports authentication.

    • Használjon rejtett végpontot.Use an obscure or hidden endpoint. Például tegye elérhetővé a végpontot egy másik, az alapértelmezett alkalmazás URL-címétől eltérő IP-címen, konfigurálja a végpontot egy nem szabványos HTTP-porton, és/vagy használjon a tesztoldalra mutató összetett elérési utat.For example, expose the endpoint on a different IP address to that used by the default application URL, configure the endpoint on a nonstandard HTTP port, and/or use a complex path to the test page. Általában megadhat további végpontcímeket és -portokat az alkalmazás konfigurációjában, és hozzáadhatja e végpontok bejegyzéseit a DNS-kiszolgálóhoz, ha nem kívánja közvetlenül megadni az IP-címet.You can usually specify additional endpoint addresses and ports in the application configuration, and add entries for these endpoints to the DNS server if required to avoid having to specify the IP address directly.

    • Tegyen elérhetővé olyan metódusokat a végpontokon, amelyek olyan paramétereket fogadnak el, mint a kulcsértékek vagy a működési mód értékei.Expose a method on an endpoint that accepts a parameter such as a key value or an operation mode value. A paraméterhez megadott értéktől függően a kérés fogadásakor a kód elvégezhet egy adott tesztet vagy több tesztet, vagy ha a paraméter nem ismerhető fel, visszaadhatja a 404-es (Nem található) kódot.Depending on the value supplied for this parameter, when a request is received the code can perform a specific test or set of tests, or return a 404 (Not Found) error if the parameter value isn't recognized. A felismert paraméterek értékei beállíthatók az alkalmazás konfigurációjában.The recognized parameter values could be set in the application configuration.

      A DoS-támadások valószínűleg kisebb hatással lesznek egy különálló végpontra, amely anélkül végez alapszintű funkcióteszteket, hogy akadályozná az alkalmazás működését.DoS attacks are likely to have less impact on a separate endpoint that performs basic functional tests without compromising the operation of the application. Ha lehetséges, ne használjon olyan teszteket, amelyek kiszivárogtathatnak bizalmas információkat.Ideally, avoid using a test that might expose sensitive information. Ha olyan információt kell visszaadnia, amely hasznos lehet egy támadónak, gondolja át, hogyan fogja megvédeni a végpontot és az adatot a jogosulatlan hozzáféréstől.If you must return information that might be useful to an attacker, consider how you'll protect the endpoint and the data from unauthorized access. Ebben az esetben nem elég pusztán az elrejtésre támaszkodni.In this case just relying on obscurity isn't enough. Emellett érdemes lehet HTTPS-kapcsolatot alkalmazni, és titkosítani minden bizalmas adatot, bár ez meg fogja növelni a kiszolgáló terheltségét.You should also consider using an HTTPS connection and encrypting any sensitive data, although this will increase the load on the server.

  • Hogyan érhetők el az olyan végpontok, amelyek hitelesítés által védettek?How to access an endpoint that's secured using authentication. Nem minden eszköz és keretrendszer konfigurálható arra, hogy az állapot-ellenőrzési kérésbe belefoglalja a hitelesítő adatokat.Not all tools and frameworks can be configured to include credentials with the health verification request. A Microsoft Azure beépített állapot-ellenőrzési funkciói például nem képesek hitelesítő adatokat biztosítani.For example, Microsoft Azure built-in health verification features can't provide authentication credentials. Néhány alternatív, külső megoldás: Pingdom, Panopta, NewRelic és Statuscake.Some third-party alternatives are Pingdom, Panopta, NewRelic, and Statuscake.

  • Hogyan ellenőrizhető, hogy a figyelőügynök megfelelően működik-e?How to ensure that the monitoring agent is performing correctly. Az egyik lehetőség elérhetővé tenni egy végpontot, amely egyszerűen visszaad egy értéket az alkalmazás konfigurációjából, vagy egy véletlenszerű értéket, amellyel tesztelhető az ügynök.One approach is to expose an endpoint that simply returns a value from the application configuration or a random value that can be used to test the agent.

    Emellett bizonyosodjon meg arról, hogy a monitorozási rendszer önmagát is ellenőrzi (például önteszttel és beépített teszttel) annak érdekében, nehogy téves eredményeket adjon.Also ensure that the monitoring system performs checks on itself, such as a self-test and built-in test, to avoid it issuing false positive results.

Mikor érdemes ezt a mintát használni?When to use this pattern

Ez a minta az alábbi esetekben hasznos:This pattern is useful for:

  • Webhelyek és webalkalmazások monitorozása a rendelkezésre állás ellenőrzése érdekében.Monitoring websites and web applications to verify availability.
  • Webhelyek és webalkalmazások monitorozása a megfelelő működés ellenőrzése érdekében.Monitoring websites and web applications to check for correct operation.
  • Középső rétegű vagy megosztott szolgáltatások monitorozása azon hibák észlelése és elkülönítése érdekében, amelyek megzavarhatják a többi alkalmazást.Monitoring middle-tier or shared services to detect and isolate a failure that could disrupt other applications.
  • A meglévő alkalmazás kiegészítése például teljesítményszámlálókkal és hibakezelőkkel.Complementing existing instrumentation in the application, such as performance counters and error handlers. Az állapot-ellenőrzés nem helyettesíti a naplózást az alkalmazásban.Health verification checking doesn't replace the requirement for logging and auditing in the application. A rendszerállapot-megfigyelés értékes információkkal szolgálhat egy meglévő keretrendszerre vonatkozóan, amely monitorozza a számlálókat és a hibanaplókat a hibák vagy más problémák észlelése érdekében.Instrumentation can provide valuable information for an existing framework that monitors counters and error logs to detect failures or other issues. Ha azonban az alkalmazás nem érhető el, nem tud információkkal szolgálni.However, it can't provide information if the application is unavailable.

PéldaExample

Az alábbi példakódok a HealthCheckController osztályból származnak (egy, ezt a mintát bemutató mintakód elérhető a GitHubon), és azt mutatják be, hogyan lehet elérhetővé tenni a végpontokat különböző állapot-ellenőrzések elvégzéséhez.The following code examples, taken from the HealthCheckController class (a sample that demonstrates this pattern is available on GitHub), demonstrates exposing an endpoint for performing a range of health checks.

A CoreServices metódus, amely lent, C# nyelven látható, egy sor ellenőrzést hajt végre az alkalmazás által használt szolgáltatásokon.The CoreServices method, shown below in C#, performs a series of checks on services used in the application. Ha mindegyik teszt hiba nélkül lefut, a metódus 200-as (OK) állapotkódot ad vissza.If all of the tests run without error, the method returns a 200 (OK) status code. Ha bármelyik teszt kivételt jelez, a metódus 500-as (Belső hiba) állapotkódot ad vissza.If any of the tests raises an exception, the method returns a 500 (Internal Error) status code. A metódus opcionálisan további információkat adhat vissza, ha hiba történik, ha a figyelési eszköz vagy keretrendszer képes használni.The method could optionally return additional information when an error occurs, if the monitoring tool or framework is able to use it.

public ActionResult CoreServices()
{
  try
  {
    // Run a simple check to ensure the database is available.
    DataStore.Instance.CoreHealthCheck();

    // Run a simple check on our external service.
    MyExternalService.Instance.CoreHealthCheck();
  }
  catch (Exception ex)
  {
    Trace.TraceError("Exception in basic health check: {0}", ex.Message);

    // This can optionally return different status codes based on the exception.
    // Optionally it could return more details about the exception.
    // The additional information could be used by administrators who access the
    // endpoint with a browser, or using a ping utility that can display the
    // additional information.
    return new HttpStatusCodeResult((int)HttpStatusCode.InternalServerError);
  }
  return new HttpStatusCodeResult((int)HttpStatusCode.OK);
}

Az ObscurePath metódus azt mutatja be, hogyan olvashatók az elérési útvonalak az alkalmazás konfigurációjából, és hogyan használhatók végpontként a tesztekhez.The ObscurePath method shows how you can read a path from the application configuration and use it as the endpoint for tests. Ez a C# nyelven írt példa azt is bemutatja, hogyan fogadhatók el az azonosítók paraméterként és használhatók a kérések érvényességének ellenőrzésére.This example, in C#, also shows how you can accept an ID as a parameter and use it to check for valid requests.

public ActionResult ObscurePath(string id)
{
  // The id could be used as a simple way to obscure or hide the endpoint.
  // The id to match could be retrieved from configuration and, if matched,
  // perform a specific set of tests and return the result. If not matched it
  // could return a 404 (Not Found) status.

  // The obscure path can be set through configuration to hide the endpoint.
  var hiddenPathKey = CloudConfigurationManager.GetSetting("Test.ObscurePath");

  // If the value passed does not match that in configuration, return 404 (Not Found).
  if (!string.Equals(id, hiddenPathKey))
  {
    return new HttpStatusCodeResult((int)HttpStatusCode.NotFound);
  }

  // Else continue and run the tests...
  // Return results from the core services test.
  return this.CoreServices();
}

A TestResponseFromConfig metódus azt mutatja be, hogyan tehet elérhetővé olyan végpontot, amely egy adott konfigurációs beállítás értékét ellenőrzi.The TestResponseFromConfig method shows how you can expose an endpoint that performs a check for a specified configuration setting value.

public ActionResult TestResponseFromConfig()
{
  // Health check that returns a response code set in configuration for testing.
  var returnStatusCodeSetting = CloudConfigurationManager.GetSetting(
                                                          "Test.ReturnStatusCode");

  int returnStatusCode;

  if (!int.TryParse(returnStatusCodeSetting, out returnStatusCode))
  {
    returnStatusCode = (int)HttpStatusCode.OK;
  }

  return new HttpStatusCodeResult(returnStatusCode);
}

Végpontok monitorozása az Azure által üzemeltetett alkalmazásokbanMonitoring endpoints in Azure hosted applications

Néhány lehetőség a végpontok monitorozására az Azure-alkalmazásokban:Some options for monitoring endpoints in Azure applications are:

  • Használja az Azure beépített monitorozási funkcióit.Use the built-in monitoring features of Azure.

  • Használjon külső szolgáltatást vagy keretrendszert, például a Microsoft System Center Operations Managert.Use a third-party service or a framework such as Microsoft System Center Operations Manager.

  • Hozzon létre egyéni segédprogramot vagy szolgáltatást, amely saját vagy üzemeltetett kiszolgálón fut.Create a custom utility or a service that runs on your own or on a hosted server.

    Bár az Azure viszonylag átfogó monitorozási lehetőségeket kínál, részletes információkért további szolgáltatásokat és eszközöket is használhat.Even though Azure provides a reasonably comprehensive set of monitoring options, you can use additional services and tools to provide extra information. Az Azure Management Services egy beépített monitorozási mechanizmust biztosít a riasztási szabályokhoz.Azure Management Services provides a built-in monitoring mechanism for alert rules. Az Azure Portal felügyeleti szolgáltatási oldalának Riasztások szakasza előfizetésenként akár tíz riasztási szabály konfigurálását is lehetővé teszi a szolgáltatásokhoz.The alerts section of the management services page in the Azure portal allows you to configure up to ten alert rules per subscription for your services. Ezek a szabályok egy feltételt és egy küszöbértéket adnak meg az olyan szolgáltatásoknak, mint például a processzorhasználat, vagy meghatározzák a másodpercenkénti kérések vagy hibák számát, ezenkívül a szolgáltatás automatikusan e-mailes értesítéseket küldhet a szabályban megadott címekre.These rules specify a condition and a threshold value for a service such as CPU load, or the number of requests or errors per second, and the service can automatically send email notifications to addresses you define in each rule.

A monitorozható feltételek az alkalmazáshoz választott üzemeltetési mechanizmustól függően eltérőek lehetnek (például Web Sites, Cloud Services, Virtual Machines vagy Mobile Services), de ezek mindegyike képes riasztási szabályokat létrehozni, amelyek a szolgáltatás beállításaiban megadott webes végpontokat használják.The conditions you can monitor vary depending on the hosting mechanism you choose for your application (such as Web Sites, Cloud Services, Virtual Machines, or Mobile Services), but all of these include the ability to create an alert rule that uses a web endpoint you specify in the settings for your service. Ennek a végpontnak időben kell válaszolnia, hogy a riasztási rendszer észlelhesse, hogy az alkalmazás megfelelően működik.This endpoint should respond in a timely way so that the alert system can detect that the application is operating correctly.

További információ a riasztási értesítések létrehozásáról.Read more information about creating alert notifications.

Ha az Azure Cloud Services webes és feldolgozói szerepkörökben vagy Virtual Machines-környezetben üzemelteti az alkalmazást, kihasználhatja az egyik beépített Azure-szolgáltatás, a Traffic Manager előnyeit.If you host your application in Azure Cloud Services web and worker roles or Virtual Machines, you can take advantage of one of the built-in services in Azure called Traffic Manager. A Traffic Manager egy útválasztó- és terheléselosztási szolgáltatás, amely képes kéréseket szétosztani a Cloud Services által üzemeltetett alkalmazás adott példányai között különböző szabályok és beállítások alapján.Traffic Manager is a routing and load-balancing service that can distribute requests to specific instances of your Cloud Services hosted application based on a range of rules and settings.

Az útválasztási kérelmek mellett a Traffic Manager pingel egy URL-címet, egy portot és egy relatív elérési útvonalat, amelyeket rendszeres időközönként megadhat, hogy megállapítsa, az alkalmazás mely, a szabályokban megadott példányai aktívak és válaszolnak a kérésekre.In addition to routing requests, Traffic Manager pings a URL, port, and relative path that you specify on a regular basis to determine which instances of the application defined in its rules are active and are responding to requests. Ha a 200-as (OK) állapotkódot észleli, elérhetőnek jelöli az alkalmazást.If it detects a status code 200 (OK), it marks the application as available. A Traffic Manager minden más állapotkód esetén offline állapotúként jelöli az alkalmazást.Any other status code causes Traffic Manager to mark the application as offline. A Traffic Manager konzolján megtekintheti az állapotot, és konfigurálhatja a szabályt, hogy átirányítsa a kéréseket az alkalmazás más példányaira, amelyek válaszolnak.You can view the status in the Traffic Manager console, and configure the rule to reroute requests to other instances of the application that are responding.

A Traffic Manager azonban csak tíz másodpercig vár a monitorozó URL-cím válaszára.However, Traffic Manager will only wait ten seconds to receive a response from the monitoring URL. Éppen ezért győződjön meg róla, hogy a rendszer az időkorláton belül futtatja az állapot-ellenőrzési kódot, ezzel lehetővé téve a hálózaton belüli adatváltási késést a Traffic Managerből az alkalmazásba, majd pedig vissza.Therefore, you should ensure that your health verification code executes in this time, allowing for network latency for the round trip from Traffic Manager to your application and back again.

További információ a Traffic Manager alkalmazások monitorozására való használatáról.Read more information about using Traffic Manager to monitor your applications. A Traffic Managerről a több adatközpont üzembe helyezéséről szóló útmutatóban is olvashat.Traffic Manager is also discussed in Multiple Datacenter Deployment Guidance.

Az alábbi útmutató hasznos lehet ennek a mintának az implementálása során:The following guidance can be useful when implementing this pattern:

  • Rendszerállapot és telemetria – útmutató.Instrumentation and Telemetry Guidance. A szolgáltatások és összetevők állapotának ellenőrzése általában mintavétel útján történik, de emellett hasznos lehet érvényes információkkal rendelkezni az alkalmazásteljesítmény monitorozásához és a futtatás során bekövetkező események észleléséhez.Checking the health of services and components is typically done by probing, but it's also useful to have information in place to monitor application performance and detect events that occur at runtime. Ezeket az adatokat az állapotfigyeléssel kapcsolatos tovább információkként vissza lehet küldeni a monitorozási eszközökbe.This data can be transmitted back to monitoring tools as additional information for health monitoring. A rendszerállapotra és telemetriára vonatkozó útmutató bemutatja, hogyan lehet távolról az alkalmazások rendszerállapot-figyelése által gyűjtött diagnosztikai adatokat gyűjteni.Instrumentation and Telemetry Guidance explores gathering remote diagnostics information that's collected by instrumentation in applications.
  • Riasztási értesítések fogadása.Receiving alert notifications.
  • Ez a minta egy letölthető mintaalkalmazást tartalmaz.This pattern includes a downloadable sample application.