Application Insights rendelkezésreállási tesztek
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 ésPOST
a 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.
Rendelkezésre állási teszt létrehozása
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
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. |
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űveletcsoportokkalkapcsolatos é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:
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.
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.
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.
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.
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.
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.
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 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.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.
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.
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.
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
ésWeb 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
ésOutage 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.
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.
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é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.
Következő lépések
Visszajelzés
https://aka.ms/ContentUserFeedback.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ:Visszajelzés küldése és megtekintése a következőhöz: