Monitorování koncových bodů Traffic Manageru
Součástí Azure Traffic Manageru je integrované monitorování koncových bodů a automatické převzetí služeb při jejich selhání. Díky této funkci můžete poskytovat vysoce dostupné aplikace, které jsou odolné vůči selhání koncových bodů, a to i v případě selhání oblastí Azure. Monitorování koncových bodů je ve výchozím nastavení povolené. Pokud chcete zakázat monitorování, přečtěte si téma Povolení nebo zakázání kontrol stavu.
Konfigurace monitorování koncových bodů
Pokud chcete nakonfigurovat monitorování koncových bodů, musíte ve svém profilu služby Traffic Manager zadat následující nastavení:
- Protokol. Jako protokol, který Traffic Manager používá při sondování koncového bodu ke kontrole jeho stavu, zvolte HTTP, HTTPS nebo TCP. Monitorování HTTPS neověřuje, jestli je váš certifikát TLS/SSL platný, ale pouze kontroluje, jestli je certifikát k dispozici.
- Port. Zvolte port použitý pro požadavek.
- Cesta. Toto nastavení konfigurace je platné pouze pro protokoly HTTP a HTTPS, pro které se vyžaduje zadání nastavení cesty. Poskytnutím tohoto nastavení pro protokol monitorování TCP dojde k chybě. Pro protokoly HTTP a HTTPS zadejte relativní cestu a název webové stránky nebo souboru, ke kterému monitorování přistupuje. Lomítko
/je platná položka pro relativní cestu. Tato hodnota znamená, že soubor je v kořenovém adresáři (výchozí). - Vlastní nastavení záhlaví. Toto nastavení konfigurace vám pomůže přidat konkrétní hlavičky HTTP do kontrol stavu, které Traffic Manager odesílá koncovým bodům v rámci profilu. Vlastní hlavičky je možné zadat na úrovni profilu, aby je bylo možné použít pro všechny koncové body v daném profilu nebo na úrovni koncového bodu, která se vztahuje pouze na tento koncový bod. Vlastní hlavičky můžete použít ke kontrolám stavu koncových bodů v prostředí s více tenanty. Tímto způsobem se dá správně směrovat do cíle zadáním hlavičky hostitele. Toto nastavení můžete použít také přidáním jedinečných hlaviček, které lze použít k identifikaci požadavků HTTP(S) z Traffic Manageru a jejich zpracování odlišně. Můžete zadat až osm
header:valuedvojic oddělených čárkami. Například,header1:value1, header2:value2.
Poznámka
Použití hvězdičky (*) ve vlastních Host hlavičkách není podporováno.
Očekávané rozsahy stavových kódů Toto nastavení umožňuje zadat více rozsahů kódu úspěchu ve formátu 200-299, 301-301. Pokud jsou tyto stavové kódy přijaty jako odpověď z koncového bodu po dokončení kontroly stavu, Traffic Manager označí tyto koncové body jako v pořádku. Můžete zadat maximálně osm rozsahů stavových kódů. Toto nastavení platí jenom pro protokoly HTTP a HTTPS a pro všechny koncové body. Toto nastavení je na úrovni profilu Traffic Manageru a ve výchozím nastavení je hodnota 200 definována jako stavový kód úspěchu.
Interval sondování. Tato hodnota určuje, jak často se koncový bod kontroluje z agenta pro sondování Traffic Manageru. Tady můžete zadat dvě hodnoty: 30 sekund (normální sondování) a 10 sekund (rychlé sondování). Pokud nejsou zadány žádné hodnoty, profil se nastaví na výchozí hodnotu 30 sekund. Další informace o rychlém testování cen najdete na stránce s cenami služby Traffic Manager .
Tolerovaný počet selhání. Tato hodnota určuje, kolik chyb agent pro sondování Traffic Manageru toleruje, než tento koncový bod označí jako chybný. Jeho hodnota může být v rozsahu od 0 do 9. Hodnota 0 znamená, že jedno selhání monitorování může způsobit označení tohoto koncového bodu jako špatného stavu. Pokud není zadána žádná hodnota, použije se výchozí hodnota 3.
Časový limit sondy. Tato vlastnost určuje dobu, po kterou by měl agent sondy Traffic Manageru počkat, než bude zvažovat selhání kontroly stavu koncového bodu. Pokud je interval sondy nastavený na 30 sekund, můžete nastavit hodnotu Časový limit mezi 5 a 10 sekund. Pokud není zadána žádná hodnota, použije se výchozí hodnota 10 sekund. Pokud je interval sondy nastavený na 10 sekund, můžete nastavit hodnotu Časový limit mezi 5 a 9 sekund. Pokud není zadána žádná hodnota časového limitu, použije se výchozí hodnota 9 sekund.
Obrázek: Monitorování koncových bodů Traffic Manageru
Jak funguje monitorování koncových bodů
Když je protokol monitorování nastavený na HTTP nebo HTTPS, agent pro sondování Traffic Manageru provede požadavek GET na koncový bod pomocí zadaného protokolu, portu a relativní cesty. Koncový bod se považuje za v pořádku, pokud agent sondy obdrží odpověď 200-OK nebo některou z odpovědí nakonfigurovaných v rozsahech očekávaných stavových kódů. Pokud má odpověď jinou hodnotu nebo se během časového limitu neobdrží žádná odpověď, agent pro sondování Traffic Manageru znovu spustí nastavení Tolerovaný počet selhání. Pokud je toto nastavení 0, neprovádí se žádné opakování. Koncový bod je označen jako chybný, pokud je počet po sobě jdoucích selhání vyšší než nastavení Tolerovaný počet selhání .
Pokud je protokol monitorování TCP, agent sondování Traffic Manageru vytvoří požadavek na připojení TCP pomocí zadaného portu. Pokud koncový bod odpoví na požadavek odpovědí na navázání připojení, označí se tato kontrola stavu jako úspěšná. Agent pro sondování Traffic Manageru resetuje připojení TCP. V případech, kdy má odpověď jinou hodnotu nebo se během časového limitu nepřijde žádná odpověď, agent pro sondování Traffic Manageru znovu vytvoří nastavení Tolerovaný počet selhání . Pokud je toto nastavení 0, neprovedou se žádné reattempts. Pokud je počet po sobě jdoucích selhání vyšší než nastavení Tolerovaný počet selhání , znamená to, že tento koncový bod není v pořádku.
Ve všech případech Traffic Manager sonduje z více umístění. Po sobě jdoucí selhání určuje, co se stane v jednotlivých oblastech. To je důvod, proč koncové body přijímají sondy stavu z Traffic Manageru s vyšší frekvencí, než je nastavení použité pro interval sondování.
Poznámka
U monitorovacího protokolu HTTP nebo HTTPS je běžným postupem na straně koncového bodu implementace vlastní stránky v rámci aplikace , například /health.aspx. Pomocí této cesty pro monitorování můžete provádět kontroly specifické pro aplikaci, jako je kontrola čítačů výkonu nebo ověření dostupnosti databáze. Na základě těchto vlastních kontrol vrátí stránka odpovídající stavový kód HTTP.
Všechny koncové body v profilu Traffic Manageru sdílejí nastavení monitorování. Pokud potřebujete použít různá nastavení monitorování pro různé koncové body, můžete vytvořit vnořené profily Traffic Manageru.
Stav koncového bodu a profilu
Profily a koncové body Traffic Manageru můžete povolit a zakázat. Ke změně stavu koncového bodu ale může dojít také kvůli automatizovaným nastavením a procesům Traffic Manageru.
Stav koncového bodu
Konkrétní koncový bod můžete povolit nebo zakázat. Základní služba, která může být stále v pořádku, není ovlivněna. Změna stavu koncového bodu řídí dostupnost koncového bodu v profilu Traffic Manageru. Když je stav koncového bodu zakázaný, Traffic Manager nekontroluje jeho stav a koncový bod není součástí odpovědi DNS.
Profile status
Pomocí nastavení stavu profilu můžete povolit nebo zakázat konkrétní profil. Zatímco stav koncového bodu ovlivňuje jeden koncový bod, stav profilu ovlivňuje celý profil včetně všech koncových bodů. Když profil zakážete, koncové body se nekontrolují z hlediska stavu a do odpovědi DNS se nezahrnou žádné koncové body. Pro dotaz DNS se vrátí kód odpovědi NXDOMAIN .
Stav monitorování koncových bodů
Stav monitorování koncového bodu je hodnota vygenerovaná službou Traffic Manager, která zobrazuje stav koncového bodu. Toto nastavení nemůžete změnit ručně. Stav monitorování koncového bodu je kombinací výsledků monitorování koncových bodů a nakonfigurovaného stavu koncového bodu. Možné hodnoty stavu monitorování koncových bodů jsou uvedené v následující tabulce:
| Profile status | Stav koncového bodu | Stav monitorování koncových bodů | Poznámky |
|---|---|---|---|
| Zakázáno | Povoleno | Inactive | Profil byl zakázán. I když je stav koncového bodu Povoleno, přednost má stav profilu (Zakázáno). Koncové body v zakázaných profilech se nemonitorují. Pro dotaz DNS se vrátí kód odpovědi NXDOMAIN. |
| <libovolné> | Zakázáno | Zakázáno | Koncový bod je zakázaný. Zakázané koncové body se nemonitorují. Koncový bod není součástí odpovědí DNS, proto nepřijímá provoz. |
| Povoleno | Povoleno | Online | Koncový bod se monitoruje a je v pořádku. Je součástí odpovědí DNS a může přijímat provoz. |
| Povoleno | Povoleno | Snížený výkon | Kontroly stavu monitorování koncových bodů selhávají. Koncový bod není součástí odpovědí DNS a nepřijímá provoz. Výjimkou je snížení výkonu všech koncových bodů. V takovém případě se všechny považují za vrácené v odpovědi na dotaz. |
| Povoleno | Povoleno | Kontrolní koncový bod | Koncový bod se monitoruje, ale výsledky první sondy ještě nebyly přijaty. CheckEndpoint je dočasný stav, který obvykle nastane okamžitě po přidání nebo povolení koncového bodu v profilu. Koncový bod v tomto stavu je součástí odpovědí DNS a může přijímat provoz. |
| Povoleno | Povoleno | Zastaveno | Webová aplikace, na kterou koncový bod odkazuje, není spuštěná. Zkontrolujte nastavení webové aplikace. K tomuto stavu může dojít také v případě, že je koncový bod typu vnořený a podřízený profil se zakáže nebo je neaktivní. Koncový bod se stavem Zastaveno se nemonitoruje. Není zahrnutá v odpovědích DNS a nepřijímá provoz. Výjimkou je snížení výkonu všech koncových bodů. V takovém případě se všechny považují za vrácené v odpovědi na dotaz. |
| Povoleno | Povoleno | Nemonitorováno | Koncový bod je nakonfigurovaný tak, aby vždy obsluhoval provoz. Kontroly stavu nejsou povolené. |
Podrobnosti o tom, jak se počítá stav monitorování koncových bodů pro vnořené koncové body, najdete v tématu vnořené profily Traffic Manageru.
Poznámka
Stav monitorování zastaveného koncového bodu se může zobrazit na App Service, pokud vaše webová aplikace není spuštěná na úrovni Standard nebo vyšší. Další informace najdete v tématu Integrace Traffic Manageru s App Service.
Stav monitorování profilu
Stav monitorování profilu je kombinací nakonfigurovaného stavu profilu a hodnot stavu monitorování koncových bodů pro všechny koncové body. Možné hodnoty jsou popsány v následující tabulce:
| Stav profilu (podle konfigurace) | Stav monitorování koncových bodů | Stav monitorování profilu | Poznámky |
|---|---|---|---|
| Zakázáno | <nebo> profil bez definovaných koncových bodů. | Zakázáno | Profil byl zakázán. |
| Povoleno | Stav alespoň jednoho koncového bodu je Snížený výkon. | Snížený výkon | Zkontrolujte hodnoty stavu jednotlivých koncových bodů a určete, které koncové body vyžadují další pozornost. |
| Povoleno | Stav alespoň jednoho koncového bodu je Online. Žádné koncové body nemají degradovaný stav. | Online | Služba přijímá provoz. Nevyžaduje se žádná další akce. |
| Povoleno | Stav alespoň jednoho koncového bodu je CheckingEndpoint. Žádné koncové body nejsou ve stavu Online nebo Snížený výkon. | Kontrola koncových bodů | K tomuto stavu přechodu dochází při vytvoření nebo povolení profilu. Stav koncového bodu se kontroluje poprvé. |
| Povoleno | Stav všech koncových bodů v profilu je Zakázáno nebo Zastaveno nebo profil nemá žádné definované koncové body. | Inactive | Nejsou aktivní žádné koncové body, ale profil je stále Povolený. |
Převzetí služeb při selhání a obnovení koncového bodu
Traffic Manager pravidelně kontroluje stav všech koncových bodů, včetně koncových bodů, které nejsou v pořádku. Traffic Manager zjistí, kdy koncový bod přestane být v pořádku, a vrátí ho zpět do oběhu.
Koncový bod není v pořádku, když dojde k některé z následujících událostí:
- Pokud je protokol monitorování HTTP nebo HTTPS:
- Odpověď, která není 200, nebo odpověď, která neobsahuje rozsah stavu zadaný v nastavení Očekávané rozsahy stavových kódů , se přijímá. (Včetně jiného kódu 2xx nebo přesměrování 301/302).
- Pokud je protokol monitorování TCP:
- Jiná odpověď než ACK nebo SYN-ACK se obdrží jako odpověď na požadavek SYN odeslaný Traffic Managerem za účelem pokusu o navázání připojení.
- Časový limit.
- Všechny ostatní problémy s připojením, které vedou k nedostupným koncovým bodům
Další informace o řešení potíží s neúspěšnými kontrolami najdete v tématu Řešení potíží se sníženým výkonem v Azure Traffic Manageru.
Časová osa na následujícím obrázku je podrobný popis procesu monitorování koncového bodu Traffic Manageru, který má následující nastavení:
- Protokol monitorování je HTTP.
- Zkušební interval je 30 sekund.
- Počet tolerovaných selhání je 3.
- Hodnota časového limitu je 10 sekund.
- Hodnota TTL DNS je 30 sekund.
Obrázek: Posloupnost převzetí služeb při selhání a obnovení koncového bodu Traffic Manageru
GET. Monitorovací systém Traffic Manageru pro každý koncový bod provede požadavek GET na cestu zadanou v nastavení monitorování.
200 – Nastavení monitorování profilu Služby Traffic Manager nebo vlastního rozsahu kódu. Monitorovací systém očekává, že se během 10 sekund vrátí stavový kód HTTP 200 OK nebo v rozsahu zadaném v nastavení monitorování. Když obdrží tuto odpověď, rozpozná, že je služba dostupná.
30 sekund mezi kontrolami. Kontrola stavu koncového bodu se opakuje každých 30 sekund.
Služba není k dispozici. Služba přestane být dostupná. Traffic Manager to nebude vědět až do další kontroly stavu.
Pokusí se o přístup k cestě monitorování. Monitorovací systém provede požadavek GET, ale během časového limitu 10 sekund neobdrží odpověď. Pak se pokusí ještě třikrát ve 30sekundových intervalech. Pokud je jeden z pokusů úspěšný, počet pokusů se resetuje.
Stav je nastavený na Snížený výkon. Po čtvrtém po sobě jdoucím selhání monitorovací systém označí stav nedostupného koncového bodu jako Snížený výkon.
Provoz se přesměruje na jiné koncové body. Názvové servery DNS služby Traffic Manager se aktualizují a Traffic Manager už nevrací koncový bod v reakci na dotazy DNS. Nová připojení se směrují na jiné dostupné koncové body. Předchozí odpovědi DNS, které obsahují tento koncový bod, ale můžou být stále uložené v mezipaměti rekurzivními servery DNS a klienty DNS. Klienti budou koncový bod dál používat, dokud nevyprší platnost mezipaměti DNS. Po vypršení platnosti mezipaměti DNS budou klienti provádět nové dotazy DNS a směrovat je do různých koncových bodů. Doba trvání mezipaměti se řídí nastavením hodnoty TTL v profilu služby Traffic Manager, například 30 sekund.
Kontroly stavu budou pokračovat. Traffic Manager bude dál kontrolovat stav koncového bodu, i když má snížený výkon. Traffic Manager zjistí, kdy se koncový bod vrátí do stavu.
Služba se vrátí do online režimu. Služba bude dostupná. Koncový bod si v Traffic Manageru zachová degradovaný stav, dokud monitorovací systém neprovede další kontrolu stavu.
Provoz do služby se obnoví. Traffic Manager odešle požadavek GET a obdrží odpověď na stav 200 OK. Služba se vrátila do dobrého stavu. Názvové servery Traffic Manageru se aktualizují a začnou v odpovědích DNS předávat název DNS služby. Provoz se vrací do koncového bodu jako odpovědi DNS uložené v mezipaměti, které vracejí ostatní koncové body, vyprší platnost a jak končí stávající připojení k jiným koncovým bodům.
Důležité
Traffic Manager nasadí pro každý koncový bod několik sond z více umístění. Několik testů zvyšuje odolnost při monitorování koncových bodů. Traffic Manager agreguje průměrný stav testů a nespoléhá na instanci sondy s jediným číslem. Redundance zkušebního systému je záměrně. Na hodnoty koncových bodů byste se měli dívat holisticky, a ne na jednotlivé sondy. Číslo zobrazené pro stav sondy je průměr. Stav by měl být problém pouze v případě, že méně než 50 % (0,5) testů publikuje stav up .
Poznámka
Vzhledem k tomu, že Traffic Manager funguje na úrovni DNS, nemůže ovlivnit existující připojení k žádnému koncovému bodu. Když Traffic Manager směruje provoz mezi koncovými body (buď změnou nastavení profilu, nebo během převzetí služeb při selhání nebo navrácení služeb po obnovení), přesměruje nová připojení na dostupné koncové body. Ostatní koncové body můžou dál přijímat provoz prostřednictvím stávajících připojení, dokud se tyto relace neukončily. Aby bylo možné vyčerpat provoz z existujících připojení, měly by aplikace omezit dobu trvání relace používané s jednotlivými koncovými body.
Metody směrování provozu
Pokud má koncový bod snížený výkon , už se nevrací v reakci na dotazy DNS. Místo toho se zvolí a vrátí alternativní koncový bod. Způsob výběru alternativního koncového bodu určuje metoda směrování provozu nakonfigurovaná v profilu.
- Priorita. Koncové body vytvoří seznam seřazený podle priority. Vždy se vrátí první dostupný koncový bod v seznamu. Pokud je stav koncového bodu Snížený výkon, vrátí se další dostupný koncový bod.
- Vážený. Všechny dostupné koncové body se vyberou náhodně na základě jejich přiřazených vah a váhy ostatních dostupných koncových bodů.
- Výkon. Vrátí se koncový bod, který je nejblíže koncovému uživateli. Pokud je tento koncový bod nedostupný, Traffic Manager přesune provoz do koncových bodů v nejbližší oblasti Azure. Alternativní plány převzetí služeb při selhání pro směrování provozu výkonu můžete nakonfigurovat pomocí vnořených profilů Traffic Manageru.
- Zeměpisná oblast. Vrátí se koncový bod namapovaný tak, aby obsluhoval zeměpisnou polohu (na základě IP adres požadavků dotazu). Pokud je tento koncový bod nedostupný, pro převzetí služeb při selhání se nevybere jiný koncový bod, protože zeměpisné umístění je možné mapovat pouze na jeden koncový bod v profilu. (Další podrobnosti najdete v nejčastějších dotazech.) Při použití geografického směrování doporučujeme zákazníkům používat vnořené profily Traffic Manageru s více než jedním koncovým bodem jako koncovými body profilu.
- Více hodnot Vrátí se více koncových bodů namapovaných na adresy IPv4/IPv6. Při přijetí dotazu pro tento profil se vrátí funkční koncové body na základě zadané hodnoty Maximální počet záznamů v odpovědi . Výchozí počet odpovědí jsou dva koncové body.
- Podsítě Vrátí se koncový bod namapovaný na sadu rozsahů IP adres. Při přijetí požadavku z této IP adresy je vrácený koncový bod namapovaný na tuto IP adresu.
Další informace najdete v tématu Metody směrování provozu Traffic Manageru.
Poznámka
Jednou z výjimek z normálního chování směrování provozu je situace, kdy mají všechny oprávněné koncové body snížený výkon. Traffic Manager se pokusí "co nejlépe" a reaguje, jako by všechny koncové body se sníženým výkonem ve skutečnosti byly v online stavu. Toto chování je vhodnější než alternativní řešení, kterým by bylo nevracet žádný koncový bod v odpovědi DNS. Zakázané nebo zastavené koncové body se nemonitorují, a proto se nepovažují za vhodné pro provoz.
Příčinou této podmínky je obvykle nesprávná konfigurace služby, například:
- Seznam řízení přístupu [ACL] blokující kontroly stavu Traffic Manageru.
- Nesprávná konfigurace portu nebo protokolu monitorování v profilu služby Traffic Manager.
Důsledkem tohoto chování je, že pokud nejsou správně nakonfigurované kontroly stavu Traffic Manageru, může to ze směrování provozu vypadat, jako by Traffic Manager fungoval správně. V tomto případě ale nemůže dojít k převzetí služeb při selhání koncového bodu, což má vliv na celkovou dostupnost aplikace. Je důležité zkontrolovat, jestli profil zobrazuje stav Online, ne degradovaný stav. Stav Online znamená, že kontroly stavu Traffic Manageru fungují podle očekávání.
Další informace o řešení potíží s neúspěšnými kontrolami stavu najdete v tématu Řešení potíží se sníženým výkonem v Azure Traffic Manageru.
Povolení nebo zakázání kontrol stavu
Azure Traffic Manager také umožňuje nakonfigurovat povolení nebo zakázání kontrol stavu koncového bodu. Pokud chcete monitorování zakázat, zvolte možnost Vždy obsluhovat provoz.
Pro kontroly stavu jsou k dispozici dvě nastavení:
- Povolit (kontroly stavu). Provoz se do koncového bodu obsluhuje na základě stavu. Toto nastavení je výchozí.
- Vždy obsluhujte provoz. Toto nastavení zakáže kontroly stavu.
Vždy obsluhovat
Když je vybraná možnost Vždy obsluhovat provoz , monitorování se vynechá a provoz se vždy odesílá do koncového bodu. Zobrazený stav monitorování koncového bodu je Nemonitorováno.
Povolení funkce Always Serve:
- V okně profilu Traffic Manageru v části Nastavení vyberte Koncové body.
- Vyberte koncový bod, který chcete nakonfigurovat.
- V části Kontroly stavu zvolte Vždy obsluhovat provoz.
- Vyberte Uložit.
Prohlédněte si následující příklad:
Poznámka
- Kontroly stavu není možné u vnořených profilů Traffic Manageru zakázat.
- Aby bylo možné nakonfigurovat kontroly stavu, musí být povolený koncový bod.
- Povolením a zakázáním koncového bodu nedojde k resetování konfigurace kontrol stavu .
- Koncovým bodům, které jsou nakonfigurované tak, aby vždy obsluhovaly provoz, se účtují základní kontroly stavu.
Nejčastější dotazy
- Je Traffic Manager odolný vůči selhání oblastí Azure?
- Jaký vliv má volba umístění skupiny prostředků na Traffic Manager?
- Návody určit aktuální stav jednotlivých koncových bodů?
- Můžu monitorovat koncové body HTTPS?
- Použiju při přidávání koncového bodu IP adresu nebo název DNS?
- Jaké typy IP adres můžu použít při přidávání koncového bodu?
- Můžu v rámci jednoho profilu použít různé typy adresování koncových bodů?
- Co se stane, když se typ záznamu příchozího dotazu liší od typu záznamu přidruženého k typu adresování koncových bodů?
- Můžu ve vnořeném profilu použít profil s koncovými body adresovanými IPv4/IPv6?
- Zastavil(a) jsem koncový bod webové aplikace v mém profilu Traffic Manageru, ale nepřijímají se mi žádné přenosy ani po restartování. Jak můžu tento problém vyřešit?
- Můžu Traffic Manager používat, i když moje aplikace nepodporuje protokol HTTP nebo HTTPS?
- Jaké konkrétní odpovědi se od koncového bodu vyžadují při použití monitorování protokolu TCP?
- Jak rychle Traffic Manager přesune uživatele z koncového bodu, který není v pořádku?
- Jak můžu zadat různá nastavení monitorování pro různé koncové body v profilu?
- Jak můžu koncovým bodům přiřadit hlavičky HTTP ke kontrolám stavu Traffic Manageru?
- Jakou hlavičku hostitele používají kontroly stavu koncového bodu?
- Jaké jsou IP adresy, ze kterých pocházejí kontroly stavu?
- Kolik kontrol stavu koncového bodu můžu očekávat od Traffic Manageru?
- Jak můžu dostat oznámení, když některý z mých koncových bodů přestane fungovat?
Další kroky
- Informace o fungování Traffic Manageru
- Další informace o metodách směrování provozu podporovaných službou Traffic Manager
- Informace o vytvoření profilu Traffic Manageru
- Řešení potíží se sníženým výkonem koncového bodu Traffic Manageru