Application Insights rendelkezésreállási tesztek

Cikk
07/16/2024

A webalkalmazás vagy a webhely üzembe helyezése után ismétlődő teszteket állíthat be a rendelkezésre állás és a válaszképesség figyelésére. Az Application Insights rendszeres időközönként küld webes kéréseket az alkalmazásnak a világ minden tájáról. Riasztást küld, ha az alkalmazás nem válaszol vagy túl lassan válaszol. Az Application Insights-erőforrásonként legfeljebb 100 rendelkezésre állási tesztet hozhat létre.

A rendelkezésre állási tesztek nem igényelnek módosításokat a tesztelt webhelyen, és nem működnek a nyilvános internetről elérhető HTTP- vagy HTTPS-végpontok esetében. Tesztelheti a szolgáltatástól függő REST API rendelkezésre állását is.

Feljegyzés

A rendelkezésre állási teszteket az Azure-adattitkosítás a rest szabályzatok szerint titkosítva tárolja.

A rendelkezésre állási tesztek típusai

A rendelkezésre állási teszteknek négy típusa van:

Standard teszt: Ez a rendelkezésre állási teszt egy olyan típusa, amely egy webhely rendelkezésre állását ellenőrzi egyetlen kérés elküldésével, hasonlóan az elavult URL-ping teszthez. Amellett, hogy ellenőrzi, hogy egy végpont válaszol-e, és méri-e a teljesítményt, a standard tesztek közé tartozik a TLS/SSL-tanúsítvány érvényessége, a proaktív élettartam-ellenőrzés, a HTTP-kérési igék (például GET,HEAD, és), az egyéni fejlécek és POSTa HTTP-kéréshez társított egyéni adatok.
Egyéni TrackAvailability teszt: Ha úgy dönt, hogy létrehoz egy egyéni alkalmazást a rendelkezésre állási tesztek futtatásához, a TrackAvailability() metódussal elküldheti az eredményeket az Application Insightsnak.
(Elavult) Többlépéses webes teszt: Ezt a felvételt lejátszhatja egy webkérelmek sorozatáról az összetettebb forgatókönyvek teszteléséhez. A többlépéses webes tesztek a Visual Studio Enterprise-ban jönnek létre, és feltölthetők a portálra, ahol futtathatja őket.
(Elavult) URL-pingelési teszt: Ezt a tesztet az Azure Portalon hozhatja létre annak ellenőrzéséhez, hogy egy végpont válaszol-e, és méri-e a válaszhoz kapcsolódó teljesítményt. Az egyéni sikerességi feltételeket speciálisabb funkciókkal is párosíthatja, például elemezheti a függő kéréseket, és újrapróbálkozást tehet lehetővé.

Fontos

Két közelgő rendelkezésre állási teszt áll rendelkezésre:

Többlépéses webes tesztek: 2024. augusztus 31-én az Application Insights többlépéses webes tesztjei megszűnnek. Javasoljuk a felhasználóknak, hogy a nyugdíjazási dátum előtt váltanak alternatív rendelkezésre állási tesztekre. Ezt a dátumot követően le fogjuk bontani a mögöttes infrastruktúrát, amely megszakítja a fennmaradó többlépéses teszteket.
URL-pingelési tesztek: 2026. szeptember 30-án az Application Insights URL-pingelési tesztjei megszűnnek. A meglévő URL-pingelési tesztek törlődnek az erőforrásokból. Tekintse át a standard tesztek díjszabását , és váltson át 2026. szeptember 30-a előtt azok használatára, hogy továbbra is futtathasson egylépéses rendelkezésre állási teszteket az Application Insights-erőforrásokban.

Tipp.

Ha jelenleg más rendelkezésre állási teszteket, például URL-pingelési teszteket használ, a többi mellett standard teszteket is hozzáadhat. Ha standard teszteket szeretne használni a többi teszt helyett, adjon hozzá egy Standard tesztet, és törölje a régi tesztet.

Előfeltételek

Munkaterület-alapú Application Insights-erőforrás

Első lépések

Nyissa meg az Application Insights-erőforrást, és válassza a Rendelkezésre állás panelt .
Válassza a Standard teszt hozzáadása lehetőséget.

Adja meg a teszt nevét, URL-címét és az alábbi táblázatban ismertetett egyéb beállításokat. Ezután kattintson a Létrehozás elemre.

Beállítás	Leírás
URL-cím	Az URL-cím bármely tesztelni kívánt weblap lehet, de láthatónak kell lennie a nyilvános interneten. Az URL-cím tartalmazhat lekérdezési sztringet. Tehát például kísérletezhet egy kicsit az adatbázissal. Ha az URL feloldása egy átirányítást eredményez, legfeljebb 10 átirányításig követjük.
Függő kérések elemzése	A teszt képeket, szkripteket, stílusfájlokat és más fájlokat kér le, amelyek a vizsgált weblap részét képezik. A rögzített válaszidőbe a fájlok lekérése is beleszámít. A teszt meghiúsul, ha ezen erőforrások bármelyike nem tölthető le sikeresen a teljes teszt időtúllépése alatt. Ha a beállítás nincs kiválasztva, a teszt csak a megadott URL-címen kéri le a fájlt. A beállítás engedélyezése szigorúbb ellenőrzést eredményez. A teszt sikertelen lehet olyan esetekben, amelyek nem feltétlenül észlelhetők a webhely manuális böngészése során. Felhívjuk figyelmét, hogy legfeljebb 15 függő kérést elemezünk.
Újrapróbálkozás engedélyezése	Ha a teszt sikertelen, rövid idő elteltével újrapróbálkozott. Csak akkor jelent hibát, ha három egymást követő kísérlet meghiúsul. Ezután a rendszer a teszteket a szokásos tesztelési gyakorisággal végzi el. Az újrapróbálkozás ideiglenesen fel van függesztve a következő sikeres műveletig. Ez a szabály függetlenül van alkalmazva minden egyes teszthelyen. Ezt a lehetőséget javasoljuk. Átlagosan körülbelül a hibák 80%-a megszűnik az újrapróbálkozáskor.
SSL-tanúsítvány érvényesítési tesztje	A webhelyen ellenőrizheti az SSL-tanúsítványt, így meggyőződhet arról, hogy megfelelően van telepítve, érvényes, megbízható, és nem ad hibát egyik felhasználónak sem.
Proaktív élettartam-ellenőrzés	Ezzel a beállítással megadhatja az SSL-tanúsítvány lejárata előtt megadott időtartamot. A lejárat után a teszt sikertelen lesz.
Teszt gyakorisága	Beállítja, hogy a teszt milyen gyakran fusson az egyes teszthelyekről. Öt perces alapértelmezett gyakorisággal és öt teszthellyel a helyén átlagosan percenként egy teszt történik.
Tesztelési helyek	Kiszolgálóink ezekről a helyekről küldenek webes kéréseket az URL-címre. Az ajánlott teszthelyek minimális száma öt , hogy meg tudja különböztetni a webhely problémáit a hálózati problémáktól. Legfeljebb 16 hely választható ki.
Egyéni fejlécek	Az üzemeltetési paramétereket meghatározó kulcsértékpárok.
HTTP-kérési parancs	Adja meg, hogy milyen műveletet szeretne elvégezni a kéréssel.
Kérelem törzse	A HTTP-kérelemhez társított egyéni adatok. Feltöltheti saját fájljait, megadhatja a tartalmát, vagy letilthatja ezt a funkciót.

Sikeresség feltétele

Beállítás	Leírás
Tesztelési időtúllépés	Csökkentse ezt az értéket, hogy értesítést kapjon a lassú válaszokról. A teszt akkor számít hibának, ha a webhelyről érkező válaszok nem érkeztek meg ebben az időszakban. Ha a függő kérések elemzése lehetőséget választotta, az összes képnek, stílusfájlnak, szkriptnek és más függő erőforrásnak meg kell érkeznie ezen az időszakon belül.
HTTP-válasz	A visszaadott állapotkód, amely sikeresnek számít. A 200-es szám az a kód, amely azt jelzi, hogy a rendszer egy normál weblapot adott vissza.
Tartalomegyezés	Egy sztring, például "Üdvözöljük!" Teszteljük, hogy minden válaszban pontosan megkülönbözteti-e a kis- és nagybetűket. Egyszerű sztringnek kell lennie helyettesítő karakterek nélkül. Ne felejtse el, hogy ha a lap tartalma megváltozik, előfordulhat, hogy frissítenie kell. A tartalomegyeztetés csak angol karaktereket támogat.

Fontos

A TrackAvailability() használatához fejlesztői befektetésre van szükség az íráshoz és a potenciálisan összetett egyéni kód főtannoki létrehozásához.

A standard teszteket mindig érdemes használni, ha lehetséges, mivel kevés befektetést, karbantartást és néhány előfeltételt igényelnek.

Előfeltételek

Munkaterület-alapú Application Insights-erőforrás
Egy függvényalkalmazás forráskódjának elérése az Azure Functionsben
Fejlesztői szakértelem, amely képes egyéni kódot létrehozni a TrackAvailability() számára, az Ön konkrét üzleti igényeihez igazítva

Alapszintű kódminta

Feljegyzés

Ez a példa kizárólag az API-hívás azure-függvényeken TrackAvailability() belüli működésének mechanikáit mutatja be. Nem mutatja be, hogyan kell írni a mögöttes HTTP-tesztkódot vagy üzleti logikát, amely ahhoz szükséges, hogy ezt a példát teljesen működőképes rendelkezésre állási tesztté alakítsa.

Alapértelmezés szerint, ha végigvezeti ezt a példát, egy alapszintű rendelkezésre állási HTTP GET-tesztet fog létrehozni. Az utasítások követéséhez a dedikált csomaggal engedélyeznie kell a kód szerkesztését az App Service Editorban.

Időzítő triggerfüggvény létrehozása

Azure Functions-erőforrás létrehozása.
- Ha már rendelkezik Application Insights-erőforrásokkal:
  
  Az Azure Functions alapértelmezés szerint létrehoz egy Application Insights-erőforrást. Ha korábban létrehozott erőforrást szeretne használni, ezt a létrehozás során kell megadnia.
  
  Kövesse az Azure Functions-erőforrás létrehozásának lépéseit a következő módosítással:
  
  A Figyelés lapon válassza az Application Insights legördülő menüt, majd adja meg vagy válassza ki az erőforrás nevét:
- Ha még nem hozott létre Application Insights-erőforrást az időzítő által aktivált függvényhez:
  
  Az Azure Functions-alkalmazás létrehozásakor alapértelmezés szerint létrehoz egy Application Insights-erőforrást. Kövesse az Azure Functions-erőforrások létrehozásának utasításait.
Feljegyzés

A függvényeket használati, prémium vagy App Service-csomagban is üzemeltetheti. Ha virtuális hálózat mögött tesztel, vagy nem nyilvános végpontokat tesztel, a Használat csomag helyett a Prémium csomagot kell használnia. Válassza ki a csomagot az Üzemeltetés lapon. A függvényalkalmazás létrehozásakor győződjön meg arról, hogy a legújabb .NET-verzió van kiválasztva.
Időzítő triggerfüggvény létrehozása.
1. A függvényalkalmazásban válassza a Függvények lapot.
2. Válassza a Hozzáadás lehetőséget. A Függvény hozzáadása panelen válassza ki a következő konfigurációkat:
  - Fejlesztői környezet: Fejlesztés a portálon
  - Sablon kiválasztása: Időzítő eseményindító
3. Válassza a Hozzáadás lehetőséget az időzítő triggerfüggvényének létrehozásához.

Kód hozzáadása és szerkesztése az App Service-szerkesztőben

Nyissa meg az üzembe helyezett függvényalkalmazást, és a Fejlesztési eszközök területen válassza az App Service-szerkesztő lapot.

Új fájl létrehozásához kattintson a jobb gombbal az időzítő triggerfüggvénye (például TimerTrigger1) alatt, és válassza az Új fájl lehetőséget. Ezután adja meg a fájl nevét, és válassza az Enter billentyűt.

Hozzon létre egy function.proj nevű új fájlt, és illessze be a következő kódot:

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

Hozzon létre egy runAvailabilityTest.csx nevű új fájlt, és illessze be a következő kódot:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

Adja meg a REGION_NAME környezeti változót érvényes Azure-rendelkezésre állási helyként.

Futtassa az alábbi parancsot az Azure CLI-ben az elérhető régiók listázásához.
```
az account list-locations -o table
```

Másolja a következő kódot a run.csx fájlba. (Lecseréli a már meglévő kódot.)

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, please add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

Többlépéses webes tesztkódminta

Kövesse a fenti utasításokat, és illessze be a következő kódot a runAvailabilityTest.csx fájlba:

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

Rendelkezésre állási riasztások

Beállítás	Leírás
Közel valós idejű	Javasoljuk, hogy közel valós idejű riasztásokat használjunk. Az ilyen típusú riasztás konfigurálása a rendelkezésre állási teszt létrehozása után történik.
Riasztási hely küszöbértéke	Legalább 3/5 helyet ajánlunk. A riasztási hely küszöbértéke és a teszthelyek száma közötti optimális kapcsolat a teszthelyek riasztási helyének küszöbértéke = – 2, amely legalább öt teszthelyet jelent.

Földrajzi helyek területcímkéi

A rendelkezésre állási URL-pingelési teszt azure Resource Managerrel történő üzembe helyezésekor a következő sokaságcímkéket használhatja a földrajzi hely attribútumhoz.

Azure

Megjelenített név	Sokaság neve
Kelet-Ausztrália	emea-au-syd-edge
Dél-Brazília	latam-br-gru-edge
Az USA középső régiója	us-fl-mia-edge
Kelet-Ázsia	apac-hk-hkn-azr
USA keleti régiója	us-va-ash-azr
Dél-Franciaország (korábban Franciaország középső régiója)	emea-ch-zrh-edge
Közép-Franciaország	emea-fr-pra-edge
Kelet-Japán	apac-jp-kaw-edge
Észak-Európa	emea-gb-db3-azr
USA északi középső régiója	us-il-ch1-azr
USA déli középső régiója	us-tx-sn1-azr
Délkelet-Ázsia	apac-sg-sin-azr
Az Egyesült Királyság nyugati régiója	emea-se-sto-edge
Nyugat-Európa	emea-nl-ams-azr
USA nyugati régiója	us-ca-sjc-azr
Az Egyesült Királyság déli régiója	emea-ru-msa-edge

Azure Government

Megjelenített név	Sokaság neve
USGov Virginia	usgov-va-azr
USGov Arizona	usgov-phx-azr
USGov Texas	usgov-tx-azr
USDoD kelet	usgov-ddeast-azr
USDoD Central	usgov-ddcentral-azr

A 21Vianet által üzemeltetett Microsoft Azure

Megjelenített név	Sokaság neve
Kelet-Kína	mc-cne-azr
Kelet-Kína 2. régiója	mc-cne2-azr
Észak-Kína	mc-cnn-azr
Észak-Kína 2. régiója	mc-cnn2-azr

Riasztások engedélyezése

A riasztások alapértelmezés szerint automatikusan engedélyezve vannak, de a riasztások teljes konfigurálásához először létre kell hoznia a rendelkezésre állási tesztet.

Feljegyzés

Az új egyesített riasztások esetén a riasztási szabály súlyosságát és a műveletcsoportokkal kapcsolatos értesítési beállításokat a riasztási felületen kell konfigurálni. A következő lépések nélkül csak portálon belüli értesítéseket fog kapni.

A rendelkezésre állási teszt mentése után a Részletek lapon válassza ki a három pontot az elvégzett teszt alapján. Válassza a Szabályok megnyitása (Riasztások) lapot.
Adja meg a riasztási szabályhoz használni kívánt értesítési beállításokat tartalmazó súlyossági szintet, szabályleírást és műveletcsoportot.

Riasztási feltételek

Az automatikusan engedélyezett rendelkezésre állási riasztások aktiválnak egy e-mailt, ha a megadott végpont nem érhető el, és ha ismét elérhető. Az ezen a felületen létrehozott rendelkezésre állási riasztások állapotalapúak. Ha teljesülnek a riasztási feltételek, egyetlen riasztás jön létre, amikor a webhely elérhetetlenként van észlelve. Ha a webhely a riasztási feltételek következő kiértékelésekor még mindig nem működik, nem hoz létre új riasztást.

Tegyük fel például, hogy a webhelye egy órán át nem működik, és beállított egy 15 perces kiértékelési gyakoriságú e-mail-riasztást. Csak akkor kap e-mailt, ha a webhely leáll, és egy másik e-mailt, amikor újra online állapotba kerül. 15 percenként nem fog folyamatos riasztásokat kapni, hogy emlékeztesse önt arra, hogy a webhely továbbra sem érhető el.

Előfordulhat, hogy nem szeretne értesítéseket kapni, ha a webhelye csak rövid ideig nem működik, például karbantartás közben. A kiértékelési gyakoriságot a várt állásidőnél magasabb értékre módosíthatja, akár 15 percre is. A riasztási hely küszöbértékét is növelheti, hogy csak akkor aktiváljon riasztást, ha a webhely adott számú régióban nem működik. Hosszabb ütemezett állásidők esetén ideiglenesen inaktiválja a riasztási szabályt, vagy hozzon létre egy egyéni szabályt. Ez további lehetőségeket kínál az állásidő figyelembe vételéhez.

A riasztási feltételek módosítása

A hely küszöbértékének, az összesítési időszaknak és a tesztelés gyakoriságának módosításához válassza ki a riasztási szabály szerkesztési oldalán található feltételt a "Jellogika konfigurálása" ablak megnyitásához.

Egyéni riasztási szabály létrehozása

Ha speciális képességekre van szüksége, létrehozhat egy egyéni riasztási szabályt a Riasztások lapon. Válassza a Riasztási szabály létrehozása lehetőséget>. Válassza a Metrikák a jeltípushoz lehetőséget az összes elérhető jel megjelenítéséhez, és válassza a Rendelkezésre állás lehetőséget.

Az egyéni riasztási szabály magasabb értékeket kínál az összesítési időszakra (6 óra helyett legfeljebb 24 óra) és a tesztelés gyakoriságára (15 perc helyett legfeljebb 1 óra). Emellett a különböző operátorok, összesítési típusok és küszöbértékek kiválasztásával további lehetőségeket ad a logika további meghatározásához.

Riasztás az Y-ból az X-ből, hibajelentési hibákról: Az új rendelkezésre állási teszt létrehozásakor alapértelmezés szerint engedélyezve van az X out of Y hely riasztási szabály az új egyesített riasztási felületen . A letiltást a "klasszikus" lehetőség kiválasztásával vagy a riasztási szabály letiltásával teheti meg. Konfigurálja a műveletcsoportokat úgy, hogy értesítéseket kapjanak, amikor a riasztás aktiválódik az előző lépések végrehajtásával. E lépés nélkül csak a portálon belüli értesítéseket fogja kapni, amikor a szabály aktiválódik.
Riasztás a rendelkezésre állási metrikákról: Az új egyesített riasztások használatával a szegmentált összesített rendelkezésre állási és tesztelési időtartam metrikák is riasztást kaphatnak:
1. Válasszon ki egy Application Insights-erőforrást a Metrikák felületen, és válasszon ki egy rendelkezésre állási metrikát.
2. A riasztások konfigurálása lehetőség a menüből az új felületre viszi, ahol kiválaszthatja azokat a teszteket vagy helyeket, amelyeken riasztási szabályokat szeretne beállítani. A riasztási szabály műveleti csoportjait itt is konfigurálhatja.
Riasztás egyéni elemzési lekérdezéseken: Az új egyesített riasztások használatával riasztást készíthet az egyéni naplók lekérdezéseihez . Egyéni lekérdezésekkel bármilyen tetszőleges feltételről riasztást készíthet, amely segít a rendelkezésre állási problémák legmegbízhatóbb jelzésében. Akkor is alkalmazható, ha egyéni rendelkezésre állási eredményeket küld a TrackAvailability SDK használatával.

A rendelkezésre állási adatok metrikái tartalmazzák a TrackAvailability SDK meghívásával beküldendő egyéni rendelkezésre állási eredményeket. A metrikák támogatásával riasztást készíthet az egyéni rendelkezésre állási eredményekről.

Riasztások automatizálása

A folyamat Azure Resource Manager-sablonokkal való automatizálásához lásd : Metrikariasztás létrehozása Azure Resource Manager-sablonnal.

A rendelkezésre állási teszt eredményeinek megtekintése

Ez a szakasz azt ismerteti, hogyan tekintheti át a rendelkezésre állási teszt eredményeit az Azure Portalon, és hogyan kérdezheti le az adatokat a Log Analytics használatával. A rendelkezésre állási teszt eredményei vonal- és pontdiagram-nézetekkel is megjeleníthetők.

Elérhetőség ellenőrzése

Először tekintse át az Application Insights-erőforrás Rendelkezésre állás lapján található grafikont.

Standard teszt
Nyomon követhetőség

Képernyőkép a Rendelkezésre állás lapról, kiemelt Frissítés gombbal.

A Pontdiagram nézet a diagnosztikai tesztlépés részleteit tartalmazó teszteredmények mintáit jeleníti meg. A tesztmotor tárolja a hibákat tartalmazó tesztek diagnosztikai adatait. A sikeres tesztek esetében a végrehajtások részhalmazainak diagnosztikai adatait is tárolja. Vigye az egérmutatót bármelyik zöld/piros pont fölé a teszt, a teszt neve és a hely megtekintéséhez.

Képernyőkép a Vonal nézetről.

Válasszon ki egy adott tesztet vagy helyet. Vagy csökkentheti az időtartamot, hogy további eredményeket jelenítsen meg a kamatidőszak körül. A Kereséskezelővel megtekintheti az összes végrehajtás eredményét. Vagy Log Analytics-lekérdezésekkel egyéni jelentéseket futtathat ezen az adatokon.

A végpontok közötti tranzakció részleteinek megtekintéséhez a Részletezés területen válassza a Sikeres vagy a Sikertelen lehetőséget. Ezután válasszon ki egy mintát. A végpontok közötti tranzakció részleteit is elérheti, ha kiválaszt egy adatpontot a gráfon.

Képernyőkép egy rendelkezésre állási tesztminta kiválasztásáról.

Tesztek vizsgálata és szerkesztése

Teszt szerkesztéséhez, ideiglenes letiltásához vagy törléséhez jelölje ki a teszt neve melletti három pontot. A módosítás után akár 20 percet is igénybe vehet, amíg a konfigurációmódosítások az összes tesztügynökre propagálásra kerülnek.

A teszt részleteinek megtekintése képernyőképe. Webes teszt szerkesztése és letiltása.

Előfordulhat, hogy le szeretné tiltani a rendelkezésre állási teszteket vagy a hozzájuk társított riasztási szabályokat, miközben karbantartást végez a szolgáltatáson.

Ha hibákat lát

Jelöljön ki egy piros elemet.

Képernyőkép a Végpontok közötti tranzakció részletei lapról.

A rendelkezésre állási teszt eredményéből az összes összetevő tranzakciós adatait láthatja. A következőkre van lehetőség:

Tekintse át a hibaelhárítási jelentést annak megállapításához, hogy mi okozhatta a teszt sikertelen voltát, de az alkalmazás továbbra is elérhető.
Megvizsgálhatja a kiszolgálótól érkezett választ.
A sikertelen rendelkezésre állási teszt feldolgozása során gyűjtött korrelált kiszolgálóoldali telemetriával diagnosztizálja a hibát.
A probléma nyomon követéséhez naplózza a problémát vagy a munkaelemet a Gitben vagy az Azure Boardsban. A hiba tartalmazni fog egy hivatkozást erre az eseményre.
Megnyithatja a webes teszt eredményét a Visual Studióban.

A végpontok közötti tranzakciódiagnosztikai felülettel kapcsolatos további információkért tekintse meg a tranzakciódiagnosztika dokumentációját.

Válassza ki a kivételsort annak a kiszolgálóoldali kivételnek a részleteinek megtekintéséhez, amely miatt a szintetikus rendelkezésre állási teszt meghiúsult. A hibakeresési pillanatképet a kódszintű diagnosztikához is lekérheti.

A kiszolgálóoldali diagnosztikát bemutató képernyőkép.

A nyers eredmények mellett két fő rendelkezésre állási metrikát is megtekinthet a Metrics Explorerben:

Rendelkezésre állás: Az összes tesztvégrehajtás során sikeres tesztek százalékos aránya.
Tesztelés időtartama: Az összes tesztvégrehajtás átlagos tesztideje.

Lekérdezés a Log Analyticsben

A Log Analytics használatával megtekintheti a rendelkezésre állási eredményeket, a függőségeket és egyebeket. A Log Analyticsről további információt a Napló lekérdezésének áttekintése című témakörben talál.

Rendelkezésre állási tesztek migrálása

Ebben a cikkben végigvezetjük a klasszikus URL-ping tesztekről a modern és hatékony standard tesztekre való migrálás folyamatán.

Ezt a folyamatot leegyszerűsítjük azáltal, hogy világos, részletes utasításokat adunk a zökkenőmentes átálláshoz, és az alkalmazásokat a legkorszerűbb monitorozási képességekkel látjuk el.

Klasszikus URL-pingelési tesztek migrálása standard tesztekre

Az alábbi lépések végigvezetik az URL-pingelési tesztek funkcióit replikáló szabványos tesztek létrehozásának folyamatán. Ez lehetővé teszi, hogy egyszerűbben kezdje el használni a szabványos tesztek speciális funkcióit a korábban létrehozott URL-pingelési tesztekkel.

Fontos

A standard tesztek futtatásához költség tartozik. A szabványos teszt létrehozása után a rendszer díjat számít fel a tesztvégrehajtásokért. A folyamat megkezdése előtt tekintse meg az Azure Monitor díjszabását .

Előfeltételek

Bármilyen URL-pingelési teszt az Application Insightsban
Azure PowerShell-hozzáférés

Első lépések

Csatlakozzon előfizetéséhez az Azure PowerShell használatával (Connect-AzAccount + Set-AzContext).

Az aktuális előfizetés összes URL-pingelési tesztjének listázása:

Get-AzApplicationInsightsWebTest | `
Where-Object { $_.WebTestKind -eq "ping" } | `
Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;

Keresse meg a migrálni kívánt URL-cím pingelési tesztjét, és rögzítse annak erőforráscsoportját és nevét.

Az alábbi parancsok az URL-pingelési teszttel megegyező logikával rendelkező szabványos tesztet hoznak létre.

Feljegyzés

Az alábbi parancsok HTTP- és HTTPS-végpontokon is működnek, amelyeket az URL-pingelési tesztekben használnak.

$resourceGroup = "pingTestResourceGroup";
$appInsightsComponent = "componentName";
$pingTestName = "pingTestName";
$newStandardTestName = "newStandardTestName";

$componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
$pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
$pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
$pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;

$dynamicParameters = @{};

if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
$dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
}

if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
-and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
$dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
$dynamicParameters["ContentPassIfTextFound"] = $true;
}

New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
-Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
-RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
-Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
-RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);

Az új szabványos teszt alapértelmezés szerint nem rendelkezik riasztási szabályokkal, így nem hoz létre zajos riasztásokat. Az URL-pingteszt nem módosul, így továbbra is használhatja a riasztásokra.
Miután érvényesítette az új standard teszt funkcióit, frissítse az URL-pingelési tesztre hivatkozó riasztási szabályokat , hogy ehelyett a standard tesztre hivatkozzon. Ezután letilthatja vagy törölheti az URL-pingelési tesztet.
Ha törölni szeretne egy URL-pingelési tesztet az Azure PowerShell-lel, használja a következő parancsot:
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

Tesztelés tűzfal mögött

A végpontok tűzfalak mögötti rendelkezésre állásának biztosítása érdekében engedélyezze a nyilvános rendelkezésre állási teszteket, vagy futtassa a rendelkezésre állási teszteket leválasztott vagy bejövő forgatókönyvek nélkül.

Nyilvános rendelkezésre állási teszt engedélyezése

Győződjön meg arról, hogy a belső webhely rendelkezik nyilvános tartománynévrendszer-rekorddal (DNS). A rendelkezésre állási tesztek sikertelenek, ha a DNS nem oldható fel. További információ: Egyéni tartománynév létrehozása belső alkalmazáshoz.

Figyelmeztetés

A rendelkezésre állási tesztek szolgáltatás által használt IP-címek meg vannak osztva, és a tűzfal által védett szolgáltatásvégpontokat más teszteknek is elérhetővé tehetik. Az IP-címszűrés önmagában nem védi a szolgáltatás forgalmát, ezért ajánlott további egyéni fejléceket hozzáadni a webes kérés eredetének ellenőrzéséhez. További információ: Virtuális hálózati szolgáltatáscímkék.

Forgalom hitelesítése

Állítsa be az egyéni fejléceket a szabványos rendelkezésre állási tesztekben a forgalom ellenőrzéséhez.

Hozzon létre egy jogkivonatot vagy GUID-t a rendelkezésre állási tesztekből származó forgalom azonosításához.
A rendelkezésre állási tesztek létrehozásakor vagy frissítésekor adja hozzá az "X-Customer-InstanceId" egyéni fejlécet a "Standard tesztinformációk" szakaszban szereplő értékkel ApplicationInsightsAvailability:<GUID generated in step 1> .
Győződjön meg arról, hogy a szolgáltatás ellenőrzi, hogy a bejövő forgalom tartalmazza-e az előző lépésekben meghatározott fejlécet és értéket.

Másik lehetőségként állítsa be a jogkivonatot lekérdezési paraméterként. Például: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>.

A tűzfal konfigurálása a rendelkezésre állási tesztek bejövő kéréseinek engedélyezéséhez

Feljegyzés

Ez a példa a hálózati biztonsági csoport szolgáltatáscímkéinek használatára vonatkozik. Számos Azure-szolgáltatás fogadja el a szolgáltatáscímkéket, amelyek mindegyike különböző konfigurációs lépéseket igényel.

Az Azure-szolgáltatások engedélyezésének egyszerűsítése egyéni IP-címek engedélyezése vagy naprakész IP-lista fenntartása nélkül szolgáltatáscímkék használatával. Alkalmazza ezeket a címkéket az Azure Firewallra és a hálózati biztonsági csoportokra, így a rendelkezésre állási tesztszolgáltatás hozzáférhet a végpontokhoz. A szolgáltatáscímke ApplicationInsightsAvailability az összes rendelkezésre állási tesztre vonatkozik.
1. Ha Azure-beli hálózati biztonsági csoportokat használ, lépjen a hálózati biztonsági csoport erőforrására, és a Beállítások területen válassza ki a bejövő biztonsági szabályokat. Ezután válassza a Hozzáadás elemet.
2. Ezután válassza a Szolgáltatáscímke lehetőséget forrásként, és válassza az ApplicationInsightsAvailability lehetőséget forrásszolgáltatás-címkeként. A szolgáltatáscímkéről érkező bejövő forgalomhoz használja a 80-at (http) és a 443-at (https).
A hozzáférés kezeléséhez, ha a végpontok az Azure-on kívül vannak, vagy ha a szolgáltatáscímkék nem használhatók, engedélyezze a webes tesztügynökök IP-címeinek listáját. Ip-tartományokat a PowerShell, az Azure CLI vagy egy REST-hívás használatával kérdezhet le a Service Tag API-val. Az aktuális szolgáltatáscímkék és ip-adataik átfogó listájához töltse le a JSON-fájlt.
1. A hálózati biztonsági csoport erőforrásában a Beállítások területen válassza ki a bejövő biztonsági szabályokat. Ezután válassza a Hozzáadás elemet.
2. Ezután válassza ki az IP-címeket forrásként. Ezután adja hozzá az IP-címeket egy vesszővel tagolt listában a forrás IP-cím/CIRD-tartományokban.

Megszakadt vagy nincs bemeneti forgatókönyv

Csatlakoztassa az Application Insights-erőforrást a belső szolgáltatásvégponthoz az Azure Private Link használatával.
Egyéni kódot írhat a belső kiszolgáló vagy végpontok rendszeres teszteléséhez. Küldje el az eredményeket az Application Insightsnak a TrackAvailability() API használatával az alapvető SDK-csomagban.

Támogatott TLS-konfigurációk

Az osztályon belüli legjobb titkosítás érdekében az összes rendelkezésre állási teszt a Transport Layer Security (TLS) 1.2 és 1.3 titkosítási mechanizmusát használja. Emellett az egyes verziókban a következő titkosítási csomagok és ellipszisgörbék is támogatottak.

Feljegyzés

A TLS 1.3 jelenleg csak a NorthCentralUS, CentralUS, EastUS, SouthCentralUS és WestUS rendelkezésre állási teszt régiókban érhető el.

TLS 1.2

Titkosítási csomagok

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Elliptikus görbék

NistP384
NistP256

TLS 1.3

Titkosítási csomagok

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256

Elliptikus görbék:

NistP384
NistP256

A TLS-konfiguráció elavultja

Figyelmeztetés

2024. október 31-én a TLS 1.0/1.1 protokollverziók és az alábbi TLS 1.2/1.3 örökölt titkosítási csomagok és ellipszisgörbék kivonásra kerülnek az Application Insights rendelkezésre állási tesztjeihez.

TLS 1.0 és TLS 1.1

A protokollverziók a továbbiakban nem támogatottak.

TLS 1.2

Titkosítási csomagok

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

Elliptikus görbék:

görbe25519

TLS 1.3

Elliptikus görbék

görbe25519

Hibaelhárítás

Figyelmeztetés

Nemrég engedélyeztük a TLS 1.3-at a rendelkezésre állási tesztekben. Ha ennek eredményeként új hibaüzenetek jelennek meg, győződjön meg arról, hogy a TLS 1.3-as verziójú Windows Server 2022-en futó ügyfelek csatlakozhatnak a végponthoz. Ha ezt nem tudja megtenni, érdemes lehet ideiglenesen letiltani a TLS 1.3-at a végponton, hogy a rendelkezésre állási tesztek visszaálljanak a régebbi TLS-verziókra.
További információkért tekintse meg a hibaelhárítási cikket. Tekintse meg a dedikált hibaelhárítási cikket.

Állásidő, SLA és szolgáltatáskimaradások munkafüzet

Ez a cikk egy egyszerű módszert mutat be a szolgáltatásszintű szerződés (SLA) kiszámítására és jelentésére a webes tesztekhez egyetlen üvegablakon keresztül az Application Insights-erőforrások és az Azure-előfizetések között. Az állásidővel és szolgáltatáskimaradással kapcsolatos jelentés hatékony, előre összeállított lekérdezéseket és adatvizualizációkat biztosít, hogy Ön alaposabban tájékozódhasson az ügyfél kapcsolatáról, az alkalmazások tipikus válaszidejéről és a tapasztalt állásidőről.

Az SLA-munkafüzetsablon kétféleképpen érhető el az Application Insights-erőforrásból:

Nyissa meg a Rendelkezésre állás panelt, majd válassza az SLA-jelentés lehetőséget a képernyő tetején.
Nyissa meg a Munkafüzetek panelt, majd válassza az Állásidő és kimaradások lehetőséget.

Paraméterrugalmasság

A munkafüzetben beállított paraméterek befolyásolják a jelentés többi részét.

Subscriptions, App Insights Resourcesés Web Test: Ezek a paraméterek határozzák meg a magas szintű erőforrás-beállításokat. Log Analytics-lekérdezéseken alapulnak, és minden jelentés-lekérdezésben használják őket.
Failure Threshold és Outage Window: Ezeket a paramétereket használhatja a szolgáltatáskimaradás saját feltételeinek meghatározásához. Ilyen például az Application Insights rendelkezésre állási riasztásának feltételei egy kiválasztott időszak sikertelen helyszámlálója alapján. A tipikus küszöbérték három hely egy ötperces ablakban.
Maintenance Period: Ezt a paramétert használhatja a tipikus karbantartási gyakoriság kiválasztásához. Maintenance Window egy dátum/idő választó egy példa karbantartási időszakra. Az azonosított időszakban előforduló összes adat figyelmen kívül lesz hagyva az eredményekben.
Availability Target %: Ez a paraméter megadja a célcélt, és egyéni értékeket vesz fel.

Áttekintő oldal

Az áttekintési oldal magas szintű információkat tartalmaz a következőket illetően:

Teljes SLA (a karbantartási időszakok kivételével, ha meg van adva)
Végpontok közötti üzemkimaradási példányok
Alkalmazás állásideje

Az üzemkimaradási példányokat az határozza meg, hogy mikor indul el egy teszt a sikertelenségig, a kimaradás paraméterei alapján. Ha egy teszt 8:00-kor indul el, és 10:00-kor ismét sikeres lesz, akkor a teljes adatkimaradás azonos lesz.

Azt is megvizsgálhatja, hogy a jelentéskészítési időszak leghosszabb kimaradása történt-e.

Egyes tesztek az Application Insights-erőforrásukhoz csatolhatók további vizsgálat céljából. Ez azonban csak a munkaterület-alapú Application Insights-erőforrásban lehetséges.

Állásidő, leállások és hibák

A Kimaradás és állásidő lap a teljes üzemkimaradási példányokról és a teljes állásidőről tartalmaz információkat teszt szerint lebontva.

A Hibák hely szerint lap geotérképet biztosít a sikertelen tesztelési helyekről a lehetséges problémák kapcsolati területeinek azonosításához.

A jelentés szerkesztése

A jelentést úgy szerkesztheti, mint bármely más Azure Monitor-munkafüzetet.

Képernyőkép a Szerkesztés gombra kattintva a vizualizáció tortadiagrammá való módosításához.

A lekérdezéseket és vizualizációkat a csapat igényei szerint testre szabhatja.

Log Analytics

A lekérdezések a Log Analyticsben futtathatók, és más jelentésekben vagy irányítópultokon is használhatók.

Távolítsa el a paraméterkorlátozást, és használja újra az alapvető lekérdezést.

A jelentés megosztható a csapatokkal és a vezetőségtel, vagy rögzíthető egy irányítópulton további felhasználás céljából. A felhasználónak olvasási engedéllyel/hozzáféréssel kell rendelkeznie ahhoz az Application Insights-erőforráshoz, amelyben a tényleges munkafüzet található.

Gyakori kérdések

Ez a szakasz választ ad a gyakori kérdésekre.

Általános

Futtathatok rendelkezésreállási teszteket egy intranetes kiszolgálón?

Webes tesztjeink olyan jelenléti pontokon futnak, amelyek a világ különböző pontjain vannak elosztva. Két megoldás létezik:

Tűzfalajtó: A webtesztelők hosszú és módosítható listájából engedélyezheti a kiszolgálóra irányuló kéréseket.
Egyéni kód: Írjon saját kódot, hogy rendszeres kéréseket küldjön a kiszolgálónak az intraneten belülről. Erre a célra Visual Studio-webteszteket is futtathat. A tesztelő az API használatával elküldheti az eredményeket az TrackAvailability() Application Insightsnak.

Mi a felhasználói ügynök sztringje a rendelkezésre állási tesztekhez?

A felhasználói ügynök sztringje Mozilla /5.0 (kompatibilis; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)

TLS-támogatás

Hogyan befolyásolja ez az elavulás a webes teszt viselkedését?

A rendelkezésre állási tesztek elosztott ügyfélként működnek minden támogatott webes teszthelyen. Minden alkalommal, amikor egy webes teszt végrehajtása megtörténik, a rendelkezésre állási tesztszolgáltatás megpróbálja elérni a webes tesztkonfigurációban meghatározott távoli végpontot. A rendszer egy TLS-ügyfél hello üzenetet küld, amely tartalmazza az összes jelenleg támogatott TLS-konfigurációt. Ha a távoli végpont közös TLS-konfigurációt oszt meg a rendelkezésre állási tesztügyféllel, a TLS-kézfogás sikeres lesz. Ellenkező esetben a webes teszt TLS-kézfogási hibával meghiúsul.

Hogyan győződjön meg arról, hogy a webes teszt nem érintett?

A hatások elkerülése érdekében a webes teszt minden távoli végpontjának (beleértve a függő kéréseket is) támogatnia kell ugyanannak a protokollverziónak, a Titkosítási csomagnak és az Ellipszisnek legalább egy kombinációját, amelyet a rendelkezésre állási teszt végez. Ha a távoli végpont nem támogatja a szükséges TLS-konfigurációt, a fent említett elavulás utáni TLS-konfiguráció bizonyos kombinációjának támogatásával kell frissíteni. Ezek a végpontok a webes teszt Tranzakció részleteinek megtekintésével deríthetők fel (ideális esetben a sikeres webes teszt végrehajtásához).

Hogyan ellenőrizni, hogy a távoli végpont milyen TLS-konfigurációt támogat?

A végpontok által támogatott TLS-konfiguráció teszteléséhez több eszköz is rendelkezésre áll. Ennek egyik módja az ezen az oldalon részletezett példa követése. Ha a távoli végpont nem érhető el a nyilvános interneten keresztül, ellenőriznie kell a távoli végponton támogatott TLS-konfigurációt egy olyan gépről, amely rendelkezik hozzáféréssel a végpont meghívásához.

Feljegyzés

Ha szeretné engedélyezni a szükséges TLS-konfigurációt a webkiszolgálón, a legjobb, ha megkeresi azt a csapatot, amely a webkiszolgáló által futtatott üzemeltetési platformot birtokolja, ha a folyamat nem ismert.

2024. október 31-e után mi lesz a webes teszt viselkedése az érintett tesztekhez?

Nincs olyan kivételtípus, amellyel az elavulás által érintett TLS-kézfogási hibák megjelennének. A webes teszt során azonban a leggyakoribb kivétel a sikertelenség lenne The request was aborted: Couldn't create SSL/TLS secure channel. A TLS átviteli hibaelhárítási lépésében az esetlegesen érintett webes teszt eredményének TLS-sel kapcsolatos hibáit is látnia kell.

Megtekinthetim, hogy a webes teszt jelenleg milyen TLS-konfigurációt használ?

A webes teszt végrehajtása során egyeztetett TLS-konfiguráció nem tekinthető meg. Mindaddig, amíg a távoli végpont a rendelkezésre állási tesztekkel támogatja a gyakori TLS-konfigurációt, az elavulás utáni hatás nem észlelhető.

Mely összetevőkre van hatással az elavulás a rendelkezésre állási tesztszolgáltatásban?

A dokumentumban részletezett TLS-elavulás csak a rendelkezésre állási teszt webtesztjének végrehajtási viselkedését befolyásolhatja 2024. október 31. után. További információ a CRUD-műveletek rendelkezésre állási tesztszolgáltatásával való interakcióról: Azure Resource Manager TLS-támogatás. Ez az erőforrás további részleteket nyújt a TLS támogatásáról és az elavulás idővonaláról.

Hol szerezhetek be TLS-támogatást?

Az örökölt TLS-problémával kapcsolatos általános kérdésekért tekintse meg a TLS-problémák megoldását.

Megosztás a következőn keresztül:

Application Insights rendelkezésreállási tesztek

A rendelkezésre állási tesztek típusai

Rendelkezésre állási teszt létrehozása

Előfeltételek

Első lépések

Sikeresség feltétele

Rendelkezésre állási riasztások

Földrajzi helyek területcímkéi

Azure

Azure Government

A 21Vianet által üzemeltetett Microsoft Azure

Riasztások engedélyezése

Riasztási feltételek

A riasztási feltételek módosítása

Egyéni riasztási szabály létrehozása

Riasztások automatizálása

A rendelkezésre állási teszt eredményeinek megtekintése

Elérhetőség ellenőrzése

Tesztek vizsgálata és szerkesztése

Ha hibákat lát

Lekérdezés a Log Analyticsben

Rendelkezésre állási tesztek migrálása

Klasszikus URL-pingelési tesztek migrálása standard tesztekre

Előfeltételek

Első lépések

Tesztelés tűzfal mögött

Nyilvános rendelkezésre állási teszt engedélyezése

Forgalom hitelesítése

A tűzfal konfigurálása a rendelkezésre állási tesztek bejövő kéréseinek engedélyezéséhez

Megszakadt vagy nincs bemeneti forgatókönyv

Támogatott TLS-konfigurációk

TLS 1.2

TLS 1.3

A TLS-konfiguráció elavultja

TLS 1.0 és TLS 1.1

TLS 1.2

TLS 1.3

Hibaelhárítás

Állásidő, SLA és szolgáltatáskimaradások munkafüzet

Paraméterrugalmasság

Áttekintő oldal

Állásidő, leállások és hibák

A jelentés szerkesztése

Log Analytics

Hozzáférés és megosztás

Gyakori kérdések

Általános

Futtathatok rendelkezésreállási teszteket egy intranetes kiszolgálón?

Mi a felhasználói ügynök sztringje a rendelkezésre állási tesztekhez?

TLS-támogatás

Hogyan befolyásolja ez az elavulás a webes teszt viselkedését?

Hogyan győződjön meg arról, hogy a webes teszt nem érintett?

Hogyan ellenőrizni, hogy a távoli végpont milyen TLS-konfigurációt támogat?

2024. október 31-e után mi lesz a webes teszt viselkedése az érintett tesztekhez?

Megtekinthetim, hogy a webes teszt jelenleg milyen TLS-konfigurációt használ?

Mely összetevőkre van hatással az elavulás a rendelkezésre állási tesztszolgáltatásban?

Hol szerezhetek be TLS-támogatást?

Következő lépések

Visszajelzés

Visszajelzés

További források