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 monitorování zakázat, 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 pro svůj profil Služby Traffic Manager zadat následující nastavení:

• Protokol. Jako protokol, který Traffic Manager používá ke kontrole stavu koncového bodu, zvolte PROTOKOL HTTP, HTTPS nebo TCP. Monitorování HTTPS neověřuje, jestli je váš certifikát TLS/SSL platný, kontroluje pouze přítomnost certifikátu.
• 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 nastavení cesty. Poskytnutím tohoto nastavení pro protokol monitorování TCP dojde k chybě. V případě protokolu HTTP a HTTPS zadejte relativní cestu a název webové stránky nebo souboru, ke kterému přistupuje monitorování. 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á do koncových bodů v rámci profilu. Vlastní hlavičky je možné zadat na úrovni profilu, aby se mohly použít pro všechny koncové body v tomto profilu nebo na úrovni koncového bodu platné pouze pro tento koncový bod. Vlastní hlavičky můžete použít k 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é se dají použít k identifikaci požadavků HTTP(S) pocházejících z Traffic Manageru a jejich zpracování odlišně. Můžete zadat až osm header:value dvojic oddělených čárkou. Například header1:value1, header2:value2.

Poznámka:

Použití znaků 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 se tyto stavové kódy obdrží jako odpověď z koncového bodu při kontrole stavu, Traffic Manager označí tyto koncové body jako v pořádku. Můžete zadat maximálně osm rozsahů stavového kódu. Toto nastavení platí jenom pro protokol 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 sondy. Tato hodnota určuje, jak často se koncový bod kontroluje pro jeho stav z agenta sondy Traffic Manageru. Tady můžete zadat dvě hodnoty: 30 sekund (normální sondování) a 10 sekund (rychlá sonda). Pokud nejsou zadány žádné hodnoty, profil se nastaví na výchozí hodnotu 30 sekund. Další informace o rychlých cenách probívání najdete na stránce s cenami služby Traffic Manager.

• Tolerovaný počet selhání Tato hodnota určuje, kolik selhání agent probing Traffic Manager toleruje před označením tohoto koncového bodu, že není v pořádku. 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, že koncový bod bude označený jako nezdravý. Pokud není zadaná žádná hodnota, použije výchozí hodnotu 3.

• Časový limit sondy Tato vlastnost určuje dobu, po kterou by měl agent sondy služby Traffic Manager čekat, než zkontrolujete, jestli sonda stavu do koncového bodu selhala. Pokud je interval sondy nastavený na 30 sekund, můžete nastavit hodnotu časového limitu mezi 5 a 10 sekund. Pokud není zadaná žádná hodnota, použije výchozí hodnotu 10 sekund. Pokud je interval probing nastaven na 10 sekund, můžete nastavit hodnotu časového limitu mezi 5 a 9 sekund. Pokud není zadaná žá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ů

Pokud je monitorovací protokol nastavený jako HTTP nebo HTTPS, agent probing Traffic Manageru odešle do koncového bodu požadavek GET pomocí protokolu, portu a relativní cesty. Koncový bod se považuje za v pořádku, pokud agent probing obdrží odpověď 200-OK nebo jakoukoli z odpovědí nakonfigurovaných v rozsahech očekávaných stavových kódů. Pokud je odpověď jinou hodnotou nebo se během časového limitu nepřijala žádná odpověď, agent probing Traffic Manager se znovu spustí podle nastavení Tolerovaný počet selhání. Pokud je toto nastavení 0, neprovádí se žádné reattempty. Koncový bod není v pořádku, pokud je počet po sobě jdoucích selhání vyšší než nastavení Tolerovaného počtu selhání .

Pokud je monitorovací protokol TCP, agent probing Traffic Manager 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 zbídání služby Traffic Manager resetuje připojení TCP. V případech, kdy je odpověď jinou hodnotou nebo se během časového limitu nepřijala žádná odpověď, agent probing traffic manageru se znovu vrátí podle nastavení Tolerovaného počtu selhání . Pokud je toto nastavení 0, neprovedou se žádné reattempty. Pokud je počet po sobě jdoucích selhání vyšší než nastavení Tolerovaného počtu selhání , znamená to, že tento koncový bod není v pořádku.

Ve všech případech se 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žívané pro interval sondy stavu.

Poznámka:

V případě monitorovacího protokolu HTTP nebo HTTPS je běžným postupem na straně koncového bodu implementace vlastní stránky v rámci vaší 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 nastavení monitorování profilu Traffic Manageru 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

Můžete povolit nebo zakázat konkrétní koncový bod. Základní služba, která může být stále v pořádku, nemá vliv. 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.

Stav profilu

Pomocí nastavení stavu profilu můžete povolit nebo zakázat konkrétní profil. Stav koncového bodu má vliv na jeden koncový bod, ale stav profilu ovlivňuje celý profil včetně všech koncových bodů. Když profil zakážete, koncové body se nekontrolují pro stav 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ého bodu

Stav monitorování koncových bodů 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:

Stav profilu	Stav koncového bodu	Stav monitorování koncového bodu	Notes
Disabled	Povolený	Neaktivní	Profil byl zakázán. I když je stav koncového bodu Povolený, má přednost 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.
<jakýkoliv>	Disabled	Disabled	Koncový bod byl zakázán. Zakázané koncové body se nemonitorují. Koncový bod není součástí odpovědí DNS, například nepřijímá provoz.
Povolený	Povolený	Online	Koncový bod se monitoruje a je v pořádku. Je součástí odpovědí DNS a může přijímat provoz.
Povolený	Povolený	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, pokud jsou všechny koncové body degradované. V takovém případě se všechny z nich v odpovědi dotazu považují za vrácené.
Povolený	Povolený	CheckEndpoint	Koncový bod se monitoruje, ale výsledky první sondy ještě nebyly přijaty. CheckEndpoint je dočasný stav, ke kterému obvykle dochází 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.
Povolený	Povolený	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í součástí odpovědí DNS a nepřijímá provoz. Výjimkou je, pokud jsou všechny koncové body degradované. V takovém případě se všechny z nich v odpovědi dotazu považují za vrácené.
Povolený	Povolený	Nemonitorováno	Koncový bod je nakonfigurovaný tak, aby vždy obsluhoval provoz. Kontroly stavu nejsou povolené.

Podrobnosti o výpočtu stavu 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 stát ve službě 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 se službou App Service.

Stav monitorování profilu

Stav monitorování profilu je kombinací nakonfigurovaného stavu profilu a hodnot stavu monitorování koncového bodu pro všechny koncové body. Možné hodnoty jsou popsány v následující tabulce:

Stav profilu (nakonfigurovaný)	Stav monitorování koncového bodu	Stav monitorování profilu	Notes
Zakázáno	<jakýkoli> profil bez definovaných koncových bodů.	Zakázáno	Profil byl zakázán.
Povoleno	Stav alespoň jednoho koncového bodu je degradovaný.	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 nejméně jednoho koncového bodu je CheckEndpoint. Ve stavu Online nebo Degraded nejsou žádné koncové body.	CheckEndpoints	Tento stav přechodu nastane, pokud je profil vytvořen nebo povolen. Stav koncového bodu se kontroluje poprvé.
Povoleno	Stavy všech koncových bodů v profilu jsou zakázané nebo zastavené, nebo profil nemá žádné definované koncové body.	Neaktivní	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 každého koncového bodu, včetně koncových bodů, které nejsou v pořádku. Traffic Manager zjistí, kdy je koncový bod v pořádku, a vrátí ho zpět do rotace.

Koncový bod není v pořádku, když dojde k některé z následujících událostí:

• Pokud je monitorovací protokol HTTP nebo HTTPS:
  • Odpověď, která není 200 nebo odpověď, která neobsahuje rozsah stavu zadaný v nastavení Očekávané rozsahy stavového kódu, se obdrží. (Včetně jiného kódu 2xx nebo přesměrování 301/302).
• Pokud je monitorovací protokol TCP:
  • Odpověď jiná než ACK nebo SYN-ACK se obdrží v reakci na požadavek SYN odeslaný Traffic Managerem za účelem pokusu o vytvoření připojení.
• Přerušení zápasu.
• Jakýkoli jiný problém s připojením vede k tomu, že koncový bod není dostupný.

Další informace o řešení potíží s neúspěšnými kontrolami najdete v tématu Řešení potíží se sníženým stavem služby Azure Traffic Manager.

Č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.
• Interval sondy 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: Převzetí služeb při selhání koncového bodu Traffic Manageru a posloupnost obnovení

1. ZÍSKAT. Pro každý koncový bod provede sledovací systém Traffic Manageru požadavek GET na cestě zadané v nastavení monitorování.

2. 200 OK nebo vlastní rozsah kódu určil nastavení monitorování profilu Traffic Manageru. Monitorovací systém očekává, že se během 10 sekund vrátí stavový kód HTTP 200 OK nebo stavový kód v rozsahu zadaném v nastavení monitorování. Když obdrží tuto odpověď, rozpozná, že je služba dostupná.

3. 30 sekund mezi kontrolami. Kontrola stavu koncového bodu se opakuje každých 30 sekund.

4. Služba není k dispozici. Služba bude nedostupná. Traffic Manager nebude vědět až do další kontroly stavu.

5. Pokusí se o přístup k cestě monitorování. Sledovací systém provede požadavek GET, ale během časového limitu 10 sekund neobdrží odpověď. Pak se třikrát pokusí, v 30sekundových intervalech. Pokud je některý z pokusů úspěšný, počet pokusů se resetuje.

6. Stav nastavený na Degraded. Po čtvrtém po sobě jdoucím selhání systém monitorování označí stav nedostupného koncového bodu jako degradovaný.

7. Provoz se přesměruje na jiné koncové body. Názvové servery DNS Traffic Manageru se aktualizují a Traffic Manager už nevrátí koncový bod v reakci na dotazy DNS. Nová připojení se směrují na jiné dostupné koncové body. Předchozí odpovědi DNS, které zahrnují tento koncový bod, ale můžou být stále uložené v mezipaměti rekurzivními servery DNS a klienty DNS. Klienti budou dál používat koncový bod, dokud nevyprší platnost mezipaměti DNS. S vypršením platnosti mezipaměti DNS klienti provádějí nové dotazy DNS a směrují se do různých koncových bodů. Doba trvání mezipaměti se řídí nastavením hodnoty TTL v profilu Traffic Manageru, například 30 sekund.

8. Kontroly stavu budou pokračovat. Traffic Manager dál kontroluje stav koncového bodu, zatímco má snížený výkon. Traffic Manager zjistí, kdy se koncový bod vrátí do stavu.

9. Služba se vrátí do online režimu. Služba bude dostupná. Koncový bod uchovává svůj degradovaný stav v Traffic Manageru, dokud sledovací systém neprovede další kontrolu stavu.

10. Přenosy do služeb se obnoví. Traffic Manager odešle požadavek GET a obdrží odpověď na stav 200 OK. Služba se vrátila do stavu v pořádku. Názvové servery Traffic Manageru se aktualizují a začnou předávat název DNS služby v odpovědích DNS. Provoz se vrátí do koncového bodu jako odpovědi DNS uložené v mezipaměti, jejichž platnost vrací jiné koncové body a 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í. Více sond zvyšuje odolnost pro monitorování koncových bodů. Traffic Manager agreguje průměrný stav sond místo toho, aby se spoléhal na instanci jednotné sondy. Redundance systému sondování je navržená. Hodnoty koncových bodů by se měly prohlédnout holisticky a ne na každou sondu. Číslo zobrazené pro stav sondy je průměr. Stav by měl být jen problém v případě, že méně než 50 % (0,5) sond publikuje stav nahoru .

    Poznámka:

    Protože Traffic Manager funguje na úrovni DNS, nemůže ovlivnit stávající připojení k žádnému koncovému bodu. Když směruje provoz mezi koncovými body (buď změněným nastavením profilu, nebo během převzetí služeb při selhání nebo navrácení služeb po obnovení), Traffic Manager přesměruje nová připojení k dostupným koncovým bodům. 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 se provoz vyprázdnil z existujících připojení, měly by aplikace omezit dobu trvání relace používanou s každým koncovým bodem.

Metody směrování provozu

Pokud má koncový bod degradovaný stav, už se nevrátí v reakci na dotazy DNS. Místo toho se vybere a vrátí alternativní koncový bod. Metoda směrování provozu nakonfigurovaná v profilu určuje způsob výběru alternativního koncového bodu.

• Priorita. Koncové body vytvoří seznam s prioritami. Vždy se vrátí první dostupný koncový bod v seznamu. Pokud je stav koncového bodu degradovaný, vrátí se další dostupný koncový bod.
• Vážená. Všechny dostupné koncové body se náhodně vyberou 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 nejblíže koncovému uživateli. Pokud tento koncový bod není dostupný, Traffic Manager přesune provoz do koncových bodů v další 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.
• Geografická oblast. Vrátí se koncový bod namapovaný tak, aby obsluhoval zeměpisné umístění (na základě IP adres požadavků dotazu). Pokud je tento koncový bod nedostupný, není vybrán jiný koncový bod pro převzetí služeb při selhání, protože geografické umístění je možné mapovat pouze na jeden koncový bod v profilu. (Další podrobnosti najdete v části Časté otázky). 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.
• Vrátí se více koncových bodů mapovaných na adresy IPv4/IPv6. Při přijetí dotazu pro tento profil se vrátí koncové body, které jsou v pořádku, na základě maximálního počtu záznamů v zadané hodnotě odpovědi . Výchozí počet odpovědí je dva koncové body.
• Podsíť Koncový bod namapovaný na sadu rozsahů IP adres se vrátí. Když se z této IP adresy obdrží požadavek, vrátí se koncový bod jako namapovaný pro tuto IP adresu. 

Další informace najdete v tématu Metody směrování provozu Traffic Manageru.

Poznámka:

K jedné výjimce normálního chování směrování provozu dochází v případě, že všechny oprávněné koncové body mají snížený stav. Traffic Manager se snaží "co nejlépe" se pokusit a reaguje, jako by všechny koncové body stavu se sníženým výkonem skutečně byly v online stavu. Toto chování je vhodnější než alternativní řešení, které by v odpovědi DNS nevracelo žádný koncový bod. Zakázané nebo zastavené koncové body nejsou monitorovány, proto se nepovažují za způsobilé 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 Traffic Manageru.

Důsledkem tohoto chování je, že pokud nejsou správně nakonfigurované kontroly stavu Traffic Manageru, může se zobrazit ze směrování provozu, jako by Traffic Manager správně fungoval. V tomto případě ale převzetí služeb při selhání koncového bodu nemůže nastat, což má vliv na celkovou dostupnost aplikace. Je důležité zkontrolovat, jestli profil zobrazuje stav Online, ne degradovaný stav. Stav Online označuje, ž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 stavem služby Azure Traffic Manager.

Povolení nebo zakázání kontrol stavu

Azure Traffic Manager také umožňuje nakonfigurovat kontroly stavu koncového bodu tak, aby byly povolené nebo zakázané. Pokud chcete monitorování zakázat, zvolte možnost vždy obsluhovat provoz.

Pro kontroly stavu existují dvě dostupná nastavení:

1. Povolení (kontroly stavu) Provoz se obsluhuje do koncového bodu na základě stavu. Toto je výchozí nastavení.
2. Vždy obsluhovat provoz. Toto nastavení zakáže kontroly stavu.

Vždy servírovat

Pokud je vybraný vždy obsluhovaný provoz , monitorování se vynechá a provoz se vždy odesílá do koncového bodu. Zobrazený stav monitorování koncového bodu je Nesledovaný.

Povolení funkce Always Serve:

1. V části Nastavení v okně profilu Traffic Manageru vyberte koncové body.
2. Vyberte koncový bod, který chcete nakonfigurovat.
3. V části Kontroly stavu zvolte Vždy obsluhovat provoz.
4. Zvolte Uložit.

Prohlédněte si následující příklad:

Poznámka:

• U vnořených profilů Traffic Manageru není možné zakázat kontroly stavu.
• Aby bylo možné nakonfigurovat kontroly stavu, musí být koncový bod povolený.
• Povolení a zakázání koncového bodu nena resetuje konfiguraci kontrol stavu.
• Koncové body nakonfigurované tak, aby vždy obsluhovaly provoz, se účtují za 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 každého koncového bodu?
• Můžu monitorovat koncové body HTTPS?
• Používám 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 v vnořeném profilu použít profil s koncovými body adresovanými protokolem IPv4 nebo IPv6?
• V profilu Traffic Manageru jsem zastavil koncový bod webové aplikace, ale nedostávám žádný provoz ani po restartování. Jak můžu tento problém vyřešit?
• Můžu traffic manager použít i v případě, že moje aplikace nepodporuje protokol HTTP nebo HTTPS?
• Jaké konkrétní odpovědi se vyžadují z koncového bodu při monitorování protokolu TCP?
• Jak rychle Traffic Manager přesune uživatele mimo koncový bod, který není v pořádku?
• Jak můžu určit různá nastavení monitorování pro různé koncové body v profilu?
• Jak můžu přiřadit hlavičky HTTP kontrolám stavu Traffic Manageru ke koncovým bodům?
• 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 do koncového bodu můžu od Traffic Manageru očekávat?
• Jak získám upozornění, když některý z mých koncových bodů přestane fungovat?

Další kroky

• Zjistěte , jak Traffic Manager funguje.
• Další informace o metodách směrování provozu podporovaných traffic Managerem
• Zjistěte, jak vytvořit profil Traffic Manageru.
• Řešení potíží se sníženým výkonem u koncového bodu Traffic Manageru