Application Insights rendelkezésreállási tesztek

Cikk
10/25/2024

Az Application Insights lehetővé teszi ismétlődő webes tesztek beállítását, amelyek figyelik a webhely vagy az alkalmazás rendelkezésre állását és válaszképességét a világ különböző pontjairól. Ezek a rendelkezésre állási tesztek rendszeres időközönként küldenek webes kéréseket az alkalmazásnak, és riasztást küldenek, ha az alkalmazás nem válaszol, vagy ha a válaszidő túl lassú.

A rendelkezésre állási tesztekhez nincs szükség a tesztelt webhely vagy alkalmazás módosítására. A nyilvános internetről elérhető BÁRMELY HTTP- vagy HTTPS-végponton működnek, beleértve a szolgáltatástól függő REST API-kat is. Ez azt jelenti, hogy nemcsak a saját alkalmazásai, hanem az alkalmazás funkciói szempontjából kritikus külső szolgáltatásokat is monitorozhat. Az Application Insights-erőforrásonként legfeljebb 100 rendelkezésre állási tesztet hozhat létre.

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: 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, az elavult URL-ping teszthez hasonlóan. 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.

Megtudhatja, hogyan hozhat létre standard teszteket.
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.

Megtudhatja, hogyan hozhat létre egyéni TrackAvailability-tesztet.
(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.

Előfeltételek

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

Első lépések

Nyissa meg az Application Insights-erőforrást, és nyissa meg a rendelkezésre állási felületet.
A felső navigációs sávon 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, majd válassza a Létrehozás lehetőséget.

Section	Beállítás	Leírás
Alapszintű információk
	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. Legfeljebb 15 függő kérést elemezünk.
	Újrapróbálkozások engedélyezése rendelkezésreállási teszthibák esetén	Ha a teszt sikertelen, rövid időköz után újrapróbálkozza. 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ényességének engedélyezése	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.
Standard tesztinformációk
	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.
	Egyéni fejlécek hozzáadása	Az üzemeltetési paramétereket meghatározó kulcsértékpárok.
Sikerességi feltételek
	Teszt időtúllépése	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 érkeznek meg ebben az időszakban. Ha a függő kérések elemzése lehetőséget választotta, az összes képet, stílusfájlt, szkriptet és egyéb függő erőforrást ebben az időszakban meg kell kapnia.
	HTTP-válasz	A visszaadott állapotkód sikeresnek számít. A 200-es szám az a kód, amely azt jelzi, hogy a rendszer egy normál weblapot ad 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.

Ez a példa csak az API-hívás azure Functions-alkalmazásokban való működésének mechanikáit TrackAvailability() 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.

Előfeltételek

Munkaterület-alapú Application Insights-erőforrás
Hozzáférés egy Azure Functions-alkalmazás forráskódhoz
Fejlesztői szakértelem a TrackAvailability() egyéni kódjának létrehozásához, az Ön egyedi üzleti igényeihez igazítva

Első lépések

Feljegyzés

Az utasítások követéséhez az App Service-csomag vagy a Functions Premium csomag használatával kell engedélyeznie a kód szerkesztését az App Service-szerkesztőben.

Ha virtuális hálózat mögött tesztel vagy nem nyilvános végpontokat tesztel, a Functions Premium csomagot kell használnia.

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

Hozzon létre egy Azure Functions-erőforrást a következő szempontok figyelembevételével:
- Ha még nem rendelkezik Application Insights-erőforrással az időzítő által aktivált függvényhez, az alapértelmezés szerint az Azure Functions-alkalmazások létrehozásakor jön létre.
- Ha már rendelkezik Application Insights-erőforrással, lépjen a Figyelés lapra az Azure Functions-alkalmazás létrehozásakor, és válassza ki vagy adja meg a meglévő erőforrás nevét az Application Insights legördülő menüben:
Kövesse az utasításokat egy időzítő által aktivált függvény létrehozásához.

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

Nyissa meg az üzembe helyezett Azure Functions-alkalmazá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/"); 
    } 
}

Cserélje le a run.csx meglévő kódját a következőre:

#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, 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(); 
    } 
}

Feljegyzés

A létrehozott TrackAvailability() tesztek a teszt neve mellett AZ EGYÉNI beállítással jelennek meg.

Képernyőkép a rendelkezésre állási felületről két különböző teszttel a listában.

Rendelkezésre állási riasztások

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.

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 földrajzi hely attribútumhoz a következő sokaságcímkéket használhatja, ha standard teszt vagy URL-pingelési tesztet helyez üzembe az Azure Resource Manager használatával.

Szolgáltató	Megjelenített név	Sokaság neve
Azure
	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
	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
	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

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 nyissa meg a helyi menüt az elvégzett teszt alapján, majd válassza a Szabályok (riasztások) lap megnyitása lehetőséget.
A Riasztási szabályok lapon nyissa meg a riasztást, majd válassza a Szerkesztés lehetőséget a felső navigációs sávon. Itt adhatja meg azt a súlyossági szintet, szabályleírást és műveletcsoportot, amely rendelkezik a riasztási szabályhoz használni kívánt értesítési beállításokkal.

Riasztási feltételek

Az automatikusan engedélyezett rendelkezésre állási riasztások aktiválnak egy e-mailt, amikor a végpont elérhetetlenné válik, és egy másik e-mailt, amikor 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ít 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. Nem kap folyamatos riasztásokat 15 percenként, hogy emlékeztesse arra, hogy a webhely továbbra sem érhető el.

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

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.

Tipp.

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 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 lépjen a Riasztási szabály szerkesztése lapra (lásd a riasztások engedélyezése területen a 2. lépést), majd válassza ki a feltételt a Jel logikai 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 kapja, 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

Első lépésként tekintse át a gráfot az Azure Portal rendelkezésre állási felületén.

Alapértelmezés szerint a Rendelkezésre állási felület egy vonaldiagramot jelenít meg. Módosítsa a nézetet pontdiagramra (váltógomb a gráf felett) a diagnosztikai tesztlépés részletességű teszteredményeinek mintáinak megtekintéséhez. 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. A teszt, a teszt neve és a hely megtekintéséhez mutasson bármelyik zöld pontra vagy piros keresztre.

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 nyissa meg a helyi menüt (három pontot), majd válassza a Szerkesztés lehetőséget. 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.

Tipp.

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

Nyissa meg a Végpontok közötti tranzakció részletei nézetet egy piros kereszt kiválasztásával a Pontdiagramon.

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.
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ózhat egy hibát vagy munkaelemet a Gitben vagy az Azure Boardsban. A hiba az Eseményre mutató hivatkozást tartalmaz az Azure Portalon.
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 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 (availabilityResults), a függőségeket (dependenciesstb.). A Log Analyticsről további információt a Napló lekérdezésének áttekintése című témakörben talál.

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 (Connect-AzAccount + Set-AzContext) használatával.

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-pingelési tesztet, és rögzítse annak erőforráscsoportját és nevét.

Hozzon létre egy szabványos tesztet ugyanazzal a logikával, mint az URL-pingelési teszt a következő parancsokkal, amelyek HTTP- és HTTPS-végpontokon is működnek.

$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.

Ellenőrizze az új szabványos teszt funkcióit, majd frissítse az URL-pingelési tesztre hivatkozó riasztási szabályokat , hogy ehelyett a standard tesztre hivatkozzon.
Tiltsa le vagy törölje az URL-pingelési tesztet. Ehhez az Azure PowerShell-lel ezt a parancsot használhatja:
```
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

Egyéni fejlécek beállítása standard tesztekben a forgalom ellenőrzéséhez.

Hozzon létre egy alfanumerikus sztringet szóközök nélkül a rendelkezésre állási teszt azonosításához (például MyAppAvailabilityTest). Innen ezt a sztringet tekintjük a rendelkezésre állási teszt sztringazonosítójának.
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 található értékkelApplicationInsightsAvailability:<your availability test string identifier>.
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 rendelkezésre állási teszt sztringazonosítót lekérdezési paraméterként.

Példa: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

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.

Ha Azure-beli hálózati biztonsági csoportokat használ, nyissa meg a hálózati biztonsági csoport erőforrását, és a Beállítások területen nyissa meg a Bejövő biztonsági szabályok felületet, majd válassza a Hozzáadás lehetőséget.
Ezután válassza a Szolgáltatáscímkét forrásként, az ApplicationInsightsAvailability pedig a Forrás szolgáltatáscímkét. 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.

A hálózati biztonsági csoport erőforrásában a Beállítások területen nyissa meg a bejövő biztonsági szabályok felületét, majd válassza a Hozzáadás lehetőséget.
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.

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

Verzió	Titkosítócsomagok	Elliptikus görbék
TLS 1.2	• 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	• NistP384 • NistP256
TLS 1.3	• TLS_AES_256_GCM_SHA384 • TLS_AES_128_GCM_SHA256	• NistP384 • NistP256

A TLS-konfiguráció elavultja

Fontos

2025. március 1-jén a TLS 1.0/1.1 protokollverziók és a felsorolt TLS 1.2/1.3 örökölt titkosítási csomagok és háromliptikus görbék az Application Insights rendelkezésre állási tesztjeihez ki lesznek kapcsolva.

TLS 1.0 és TLS 1.1

A TLS 1.0 és a TLS 1.1 kivezetése folyamatban van.

TLS 1.2 és TLS 1.3

Verzió	Titkosítócsomagok	Elliptikus görbék
TLS 1.2	• 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	• görbe25519
TLS 1.3		• 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 Windows Server 2022-n futó, TLS 1.3-as verziójú ü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.

Állásidő és üzemkimaradások munkafüzet

Ez a szakasz 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ási felületet, majd válassza az SLA-jelentés lehetőséget a felső navigációs sávon.
Nyissa meg a Munkafüzetek felületet, majd válassza az Állásidő & Kimaradások sablont .

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

A kimaradási példányok attól a pillanattól kezdve vannak meghatározva, amikor a teszt megkezdődik a sikertelenségig, amíg a kimaradás paramétereinek megfelelően ismét sikeresen át nem megy. 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

Az Áttekintés lap mellett további két lap található:

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.

Egyéb jellemzők

Testreszabás: Szerkesztheti a jelentést, mint bármely más Azure Monitor-munkafüzetet , és a csapat igényeinek megfelelően testre szabhatja a lekérdezéseket vagy vizualizációkat.
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.
Hozzáférés és megosztás: 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élyekre és hozzáférésre van szüksége 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?

A rendelkezésre állási tesztek a világ különböző pontjain elosztott jelenléti pontokon futnak. 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.

2025. március 1. 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 webes tesztvégrehajtási viselkedését befolyásolhatja 2025. március 1. 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

Rendelkezésre állási riasztások

Földrajzi helyek területcímkéi

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

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

A TLS-konfiguráció elavultja

TLS 1.0 és TLS 1.1

TLS 1.2 és TLS 1.3

Hibaelhárítás

Állásidő és üzemkimaradások munkafüzet

Paraméterrugalmasság

Áttekintő oldal

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

Egyéb jellemzők

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?

2025. március 1. 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

További források