流量管理員常見問題集 (FAQ)

流量管理員基本概念

「流量管理員」使用什麼 IP 位址?

如流量管理員的運作方式所述,流量管理員可在網域名稱系統 (DNS) 層級運作。 它會傳送 DNS 回應,將用戶端導向適當的服務端點。 用戶端會接著直接連線到服務端點,而不會透過「流量管理員」。

因此,流量管理員不會提供端點或 IP 位址供用戶端連接。 如果您的服務需要靜態 IP 位址,就必須在服務上設定,而不是在「流量管理員」中設定。

哪種類型的流量可以使用流量管理員路由傳送?

流量管理員的運作方式中所述,流量管理員端點可以是 Azure 內部或外部裝載的任何網際網路對向服務。 因此,流量管理員可以將源自公用網際網路的流量路由傳送至一組也是網際網路面向的端點。 如果您的端點位於私人網路內 (例如Azure Load Balancer) 的內部版本,或讓使用者從這類內部網路提出 DNS 要求,則您無法使用流量管理員來路由傳送此流量。

流量管理員是否支援「粘滯」會話?

如流量管理員的運作方式所述,流量管理員可在 DNS 層級運作。 它會使用 DNS 回應將用戶端導向到適當的服務端點。 用戶端會直接連接至服務端點,而不會透過流量管理員。 因此,流量管理員看不到用戶端與伺服器之間的 HTTP 流量。

此外,流量管理員收到之 DNS 查詢的來源 IP 位址屬於遞迴 DNS 服務,而不是用戶端。 因此,流量管理員無法追蹤個別的用戶端,也無法執行「粘滯」會話。 這項限制適用于所有以 DNS 為基礎的流量管理系統,而不是流量管理員特有的。

我在使用流量管理員時為何看到 HTTP 錯誤?

如流量管理員的運作方式所述,流量管理員可在 DNS 層級運作。 它會使用 DNS 回應將用戶端導向到適當的服務端點。 用戶端會接著直接連線到服務端點,而不會透過「流量管理員」。 流量管理員看不到用戶端與伺服器之間的 HTTP 流量。 因此,您看到的任何 HTTP 錯誤必定來自您的應用程式。 為了讓用戶端連接至應用程式,所有 DNS 解析步驟都已完成。 這包括流量管理員在應用程式流量流程上的任何互動。

因此,進一步的調查應該將焦點放在應用程式上。

從用戶端的瀏覽器傳送的 HTTP 主機標頭是最常見的問題來源。 請確定應用程式已設定為接受您所使用之功能變數名稱的正確主機標頭。 關於使用 Azure App Service 的端點,請參閱在使用流量管理員的 Azure App Service 中設定 Web 應用程式的自訂網域名稱

使用「流量管理員」對效能有什麼影響?

如流量管理員的運作方式所述,流量管理員可在 DNS 層級運作。 由於用戶端會直接連接到您的服務端點,因此在建立連線之後使用流量管理員,並不會產生任何效能影響。

因為流量管理員會在 DNS 層級與應用程式整合,所以它確實需要在 DNS 解析鏈結中插入額外的 DNS 查閱。 「流量管理員」對 DNS 解析時間的影響極小。 流量管理員使用名稱伺服器的全球網路,並使用任意傳播網路,確保 DNS 查詢一律會路由至最接近的可用名稱伺服器。 此外,快取 DNS 回應意謂著因使用「流量管理員」而造成的額外 DNS 延遲僅適用於一小部分工作階段。

「效能」方法會將流量路由傳送至最靠近的可用端點。 最後結果就是這個方法引起的整體效能影響會降到最低。 增加的任何 DNS 延遲都被端點更短的網路延遲所抵銷。

我可以搭配「流量管理員」使用哪些應用程式通訊協定?

如流量管理員的運作方式所述,流量管理員可在 DNS 層級運作。 完成 DNS 查閱之後,用戶端就會直接連線到應用程式端點,而不會透過「流量管理員」。 因此,連線可以使用任何應用程式通訊協定。 如果您選取 TCP 作為監視通訊協定,流量管理員的端點健康情況監視可以在不使用任何應用程式通訊協定的情況下完成。 如果您選擇使用應用程式通訊協定來驗證健康情況,端點必須能夠回應 HTTP 或 HTTPS GET 要求。

我可以搭配「裸」功能變數名稱使用流量管理員嗎?

是的。 若要瞭解如何建立功能變數名稱頂點的別名記錄,以參考 Azure 流量管理員設定檔,請參閱設定別名記錄以支援頂點功能變數名稱與流量管理員

處理 DNS 查詢時,流量管理員會考量用戶端子網路位址嗎?

是,除了所收到 DNS 查詢的來源 IP 位址, (通常是 DNS 解析程式的 IP 位址) ,當您執行地理、效能和子網路由方法的查閱時,流量管理員也會考慮用戶端子網位址(如果由解析程式包含在查詢中,並代表使用者提出要求)。
具體而言即 RFC 7871 – DNS 查詢中的用戶端子網路 (英文),此子網路提供 DNS 的延伸機制 (EDNS0) (英文),可將用戶端子網路位址從支援它的解析程式傳遞出去。

什麼是 DNS TTL,以及它如何影響我的使用者?

DNS 查詢進入流量管理員時,它會在稱為存留時間 (TTL) 的回應中設定值。 此值 (單位為秒) 會向 DNS 解析程式下游表示快取此回應要多久時間。 雖然 DNS 解析程式不保證會快取此結果,但快取它可讓它們回應快取中的任何後續查詢,而不是前往流量管理員 DNS 伺服器。 這會影響回應,如下所示:

  • 較高的 TTL 會減少進入流量管理員 DNS 伺服器的查詢數目,因為提供服務的查詢數目是可計費的使用量,所以可減少客戶的成本。
  • 較高的 TTL 可能會減少執行 DNS 查閱所花費的時間。
  • 較高的 TTL 也表示您的資料不會反映流量管理員透過其探查代理程式取得的最新健康情況資訊。

我可以將流量管理員回應的 TTL 設為多高或多低?

您可以在每個設定檔層級將 DNS TTL 設定為最低 0 秒、最高 2,147,483,647 秒 (符合 RFC-1035 的最大範圍)。 TTL 為0表示下游 DNS 解析程式不會快取查詢回應,而且所有查詢都應該連到流量管理員的 DNS 伺服器以進行解析。

如何了解傳給我的設定檔的查詢量?

流量管理員提供的其中一個計量是由設定檔所回應的查詢數量。 您可以在設定檔層級的彙總取得此資訊,或者也可以進一步分割此資料,以查看所傳回特定端點的查詢量。 此外,您可以設定警示,以在查詢回應量跨越設定的條件時通知您。 如需詳細資訊,請參閱流量管理員的計量與警示

當我刪除流量管理員設定檔時,可重複使用設定檔名稱之前的時間長度為何?

刪除流量管理員設定檔之後,最多可能需要2小時的時間才會變成可用名稱。

流量管理員地理流量路由方法

地理路由派上用場的使用案例有哪些?

每當 Azure 客戶需要依據地理區域來區別他們的使用者位置時,就可以使用地理路由類型。 例如,使用地理流量路由方法,您可以為特定區域的使用者提供不同於其他區域的使用者體驗。 另一個例子是符合本機資料主權規定,要求特定區域的使用者只能由該區域中的端點提供服務。

如何決定應該要使用效能路由方法或使用地理路由方法?

這兩個常用路由方法的主要差異,在於效能路由的主要目標是將流量傳送至能提供呼叫者最低延遲的端點,而地理路由的主要目標則是對您的呼叫者強制使用地理柵欄,這樣就能特意將他們路由到特定端點。 發生重迭的原因是地理接近程度與較低延遲之間有相互關聯性,不過這不一定如此。 可能會有不同地理位置的端點,可為呼叫者提供更好的延遲體驗,而在此情況下,效能路由會將使用者傳送至該端點,但地理路由一律會將其傳送至您為其地理區域對應的端點。 為了進一步釐清,請考慮以下範例:您可以使用地理路由製造不尋常的對應,例如將來自亞洲的所有流量都傳送到在美國的端點,或將所有來自美國的流量傳送到在亞洲的端點。 在這種情況下,地理路由會刻意執行您所設定的工作,而且不會考慮效能優化。

注意

在某些情況下,您可能需要效能路由和地理路由功能兩者,對於這些情況,巢狀設定檔可能是最佳選擇。 例如,您可以設定使用地理路由的父設定檔,將所有來自北美洲的流量,傳送到所含端點在美國的巢狀設定檔,並使用效能路由將那些流量傳送到該集合中的最佳端點。

流量管理員的地理路由支援哪些區域?

這裡可以找到流量管理員所使用的國家/區域階層。 雖然此頁面會隨著任何變更而保持最新狀態,但您也可以使用Azure 流量管理員 REST API,以程式設計方式取得相同的資訊。

流量管理員如何判斷使用者從何處執行查詢?

流量管理員會查看查詢的來源 IP (這很可能是代表使用者執行查詢的本機 DNS 解析程式),並使用內部 IP 至區域的對應來判斷位置。 此對應會融合網際網路上的變動而不斷更新。

它保證流量管理員可以在每個案例中正確判斷使用者確切的地理位置嗎?

否,流量管理員無法保證從 DNS 查詢的來源 IP 位址推斷的地理區域,一律會對應到使用者的位置,原因如下:

  • 首先,如先前的常見問題所述,我們看到的來源 IP 是代表使用者執行查閱的 DNS 解析程式。 儘管 DNS 解析程式的地理位置是使用者地理位置的良好 Proxy,但是,根據 DNS 解析程式服務的使用量和客戶選擇使用的特定 DNS 解析程式服務而定,它也可以不一樣。 例如,位於馬來西亞的客戶可以在裝置的設定中指定使用 DNS 解析程式服務,該服務的 DNS 伺服器可能會被挑選,以處理該使用者/裝置的查詢解決方法。 在這種情況下,流量管理員只能看到對應到新加坡位置的解析程式 IP。 此外,請參閱此頁面上先前有關用戶端子網路位址支援的常見問題集。

  • 其次,流量管理員會使用內部對應來進行 IP 位址到地理區域的轉譯。 雖然此對應會持續進行驗證及更新,以便提高其精確度,並考慮網際網路的不斷演進,但我們的資訊仍有可能無法完全表示所有 IP 位址的地理位置。

端點是否必須實際位於與其設定用於地理路由的相同區域中?

否,端點的位置不限制哪些區域可以對應它。 例如,美國中部 Azure 區域的端點可以接納所有來自印度的使用者。

我可以將地理區域指派給設定檔中未設定為進行地理路由的端點嗎?

是,如果設定檔的路由方法不是地理,您可以使用Azure 流量管理員 REST API將地理區域指派給該設定檔中的端點。 在非地理路由類型的設定檔中,將忽略此設定。 如果您稍後將此設定檔變更為地理路由類型,流量管理員可以使用這些對應。

當我嘗試將現有設定檔的路由方法變更為地理時為何會發生錯誤?

設為地理路由的設定檔下的所有端點,必須至少有一個區域對應到它。 若要將現有的設定檔轉換成地理路由類型,您需要先使用 Azure 流量管理員 REST API,將地理區域和其所有端點相關聯,才能將路由類型變更為地理。 如果使用入口網站,先刪除端點,將設定檔的路由方法變更為地理,然後新增端點及其地理區域對應。

如果區域使用地理路由方法,則只能將一個端點指派給設定檔內的一個端點。 如果該端點不是已連結子設定檔的巢狀型別,則如果該端點變成狀況不良,流量管理員會繼續將流量傳送給它,因為未傳送任何流量的替代方式不會更好。 流量管理員不會容錯移轉至另一個端點,即使指派的區域是指派給狀況不良的端點之區域的「父系」 (例如,如果有區域西班牙的端點變成狀況不良,我們就不會容錯移轉至另一個端點,且該端點已獲指派歐洲區域) 。 這是為了確保流量管理員會顧及客戶在其設定檔中已設定的地理界限。 若要獲得當端點狀況不良時容錯移轉至另一個端點的優點,建議將地理區域指派給具有多個端點的嵌套設定檔,而不是個別端點。 如此一來,如果嵌套子設定檔中的端點失敗,流量就可以容錯移轉至相同的嵌套子設定檔中的另一個端點。

支援此路由類型的 API 版本有任何限制嗎?

是,只有 2017 年 3 月 1 日的 API 版本和更新版本支援地理路由類型。 任何較舊的 API 版本都不能用來建立地理路由類型的設定檔,或將地理區域指派給端點。 如果使用舊版 API 從 Azure 訂用帳戶取出設定檔,則不會傳回地理路由類型的任何設定檔。 此外,使用舊版 API 時,傳回的任何設定檔如果有具有地理區域指派的端點,則不會顯示其地理區域指派。

流量管理員子網路流量路由方法

子網路路由派上用場的使用案例有哪些?

「子網路」路由可讓您區分針對其 DNS 要求 IP 位址的來源 IP 所識別之特定使用者集合而提供的體驗。 如果使用者要從您的公司總部連線至網站,則範例將會顯示不同的內容。 另一種方法是將特定 Isp 的使用者限制為只有在使用 IPv6 時,如果這些 Isp 有欠佳效能,才存取僅支援 IPv4 連線的端點。 另一個使用「子網路」路由方法的原因是搭配使用巢狀設定檔集合中的其他設定檔。 例如,如果您想要使用「地理」路由方法來異地隔離使用者,但想要針對特定 ISP 執行不同的路由方法,則可以有「子網路」路由方法作為父設定檔的設定檔,並覆寫該 ISP 以使用特定子設定檔,以及讓其他人都有標準「地理」設定檔。

流量管理員如何知道終端使用者的 IP 位址?

終端使用者裝置通常會使用 DNS 解析程式來代表他們執行 DNS 查閱。 這類解析程式的連出 IP 就是流量管理員視為來源 IP 的 IP。 此外,子網路由方法也會查看是否有 EDNS0 延伸的用戶端子網 (ECS) 隨要求傳遞的資訊。 如果顯示 ECS 資訊,則這是用來判斷路由的位址。 如果沒有 ECS 資訊,則會將查詢的來源 IP 用於路由。

使用「子網路」路由時,如何指定 IP 位址?

有兩種方式可以指定要與端點建立關聯的 IP 位址。 首先,您可以使用具有開始和結束位址的四點十進制八進位標記法來指定範圍 (例如 1.2.3.4-5.6.7.8 或 3.4.5.6-3.4.5.6)。 其次,您可以使用 CIDR 標記法來指定範圍 (例如 1.2.3.0/24)。 您可以指定多個範圍,而且可以在範圍集合中使用這兩種標記法類型。 適用一些限制。

  • 位址範圍不能重迭,因為每個 IP 都必須對應至單一端點
  • 起始位址不能超過結束位址
  • 在 CIDR 標記法的案例中,'/' 前面的 IP 位址應該是該範圍的起始位址 (例如,1.2.3.0/24 有效,但 1.2.3.4.4/24 無效)

使用「子網路」路由時,如何指定後援端點?

在具有子網路由的設定檔中,如果您有未對應子網的端點,則任何與其他端點不符的要求都會導向此處。 強烈建議您在設定檔中有這類的 fallback 端點,因為如果要求傳入且未對應至任何端點,或它已對應到端點,但該端點狀況不良時,流量管理員將會傳回 NXDOMAIN 回應。

如果「子網路」路由類型設定檔中已停用端點,則會發生什麼事?

在具有子網路由的設定檔中,如果您有已停用的端點,流量管理員的行為會如同該端點和子網對應不存在。 如果收到的查詢與其 IP 位址對應相符,並已停用端點,流量管理員將會傳回一個沒有對應的回條端點 () 如果沒有對應的端點,則會傳回 NXDOMAIN 回應。

流量管理員 MultiValue 流量路由方法

MultiValue 路由派上用場的使用案例有哪些?

MultiValue 路由會在單一查詢回應中傳回多個狀況良好的端點。 此方式的主要優點在於,如果端點狀況不良,則用戶端有更多的選項可重試,而不需要提出另一個 DNS 呼叫 (這可能會從上游快取傳回相同的值)。 這適用于想要將停機時間降至最低的可用性敏感應用程式。 多值路由方法的另一種用法是,如果端點是「雙重主目錄」至 IPv4 和 IPv6 位址,而且您想要提供呼叫端在起始端點連線時選擇的兩個選項。

使用 MultiValue 路由時,會傳回多少個端點?

您可以指定要傳回的端點數目上限,而且 MultiValue 所傳回的狀況良好端點數目不會超過收到查詢時的狀況良好端點數目。 此設定的最大可能值為 10。

使用 MultiValue 路由時,會取得一組相同的端點嗎?

我們無法保證每個查詢都會傳回相同的端點集合。 這也會受到影響,因為某些端點可能會在回應中未包含這些端點的狀況不良

實際使用者度量

使用「實際使用者度量」有哪些優點?

當您使用效能路由方法時,「流量管理員」會檢查來源 IP 和「EDNS 用戶端子網路」(如果已傳入),並根據服務所維護的網路延遲智慧功能檢查這些資訊,為您的使用者挑選最佳的 Azure 區域來進行連線。 實際使用者度量藉由讓您的終端使用者體驗成為這份延遲資料表的經驗,來為您的使用者群增強這項功能,並確保此資料表能充分地橫跨使用者網路,讓使用者網路連線到 Azure。 這可提升使用者路由的精確度。

我是否可以將「實際使用者度量」與非 Azure 區域搭配使用?

「實際使用者度量」只會測量連線到 Azure 區域的延遲並進行回報。 如果您使用以效能為基礎的路由搭配非 Azure 區域中所裝載的端點,您仍然可以從這項功能獲益,因為您已選擇要與此端點相關聯的代表性 Azure 區域有更高的延遲資訊。

哪個路由方法可從「實際使用者度量」受益?

透過「實際使用者度量」取得的額外資訊僅適用於使用效能路由方法的設定檔。 透過 Azure 入口網站檢視實際使用者度量時,就能從所有設定檔使用 [實際使用者度量] 連結。

我是否需要為每個設定檔個別啟用「實際使用者度量」?

否,每一訂用帳戶只需啟用一次,所測量到和回報的所有延遲資訊便可供所有設定檔使用。

如何關閉我訂用帳戶的「實際使用者度量」?

當您從用戶端應用程式停止收集及傳回延遲度量時,即可停止產生與「實際使用者度量」相關的費用。 例如,當度量 JavaScript 內嵌在網頁中時,您可以移除該 JavaScript,或是在轉譯頁面時關閉其引動過程,來停止使用這項功能。

您也可以透過刪除您的金鑰來關閉「實際使用者度量」。 一旦您刪除金鑰,所有傳送給「流量管理員」且具有該金鑰的度量就都會被捨棄。

我是否可以將「實際使用者度量」與網頁以外的用戶端應用程式搭配使用?

是的,實際使用者度量是設計來內嵌透過不同類型的使用者用戶端所收集的資料。 當支援新類型的用戶端應用程式時,將會更新這個 FAQ。

每次轉譯已啟用「實際使用者度量」功能的網頁時,會執行多少個度量?

將「實際使用者度量」與所提供的度量 JavaScript 搭配使用時,每個頁面轉譯都會進行 6 個度量。 這些度量會接著回報給「流量管理員」服務。 此功能的收費依據為回報給流量管理員服務的度量數目。 例如,如果使用者在進行測量時,離開您的網頁,但在報告之前,不會考慮這些度量的計費用途。

「實際使用者度量」在我的網頁中執行前是否會有延遲?

否,叫用腳本之前沒有任何程式設計的延遲。

是否可以只搭配我想要測量的 Azure 區域來使用實際使用者度量?

否,每次叫用時,實際使用者測量腳本會測量一組由服務決定的六個 Azure 區域。 這個集合會在不同的引動過程之間變更,當發生大量這樣的引動過程時,度量涵蓋範圍就會跨不同的 Azure 區域。

我是否可以將度量數目限制為特定數目?

度量 JavaScript 內嵌在您網頁內,因此您可以完全控制要何時開始或停止使用它。 只要流量管理員服務收到要測量的 Azure 區域清單要求,就會傳回一組區域。

我是否可以查看用戶端應用程式在「實際使用者度量」過程中所進行的度量?

由於度量邏輯是從您用戶端應用程式執行的,因此您可以完全控制所進行的作業,包括查看延遲度量。 流量管理員不會回報在連結至您的訂用帳戶之金鑰底下收到的度量匯總視圖。

我是否可以修改「流量管理員」所提供的度量指令碼?

雖然您可以控制網頁上內嵌的指令碼,但強烈建議您不要對度量指令碼進行任何變更,以確保它可正確測量並回報延遲。

其他人是否可能看到我搭配「實際使用者度量」使用的金鑰?

當您將測量腳本內嵌至網頁時,其他人可以看到腳本和您的實際使用者度量 (RUM) 金鑰。 但請務必瞭解,此金鑰與您的訂用帳戶識別碼不同,而且是由流量管理員所產生,因此只能用於此用途。 知道您的 RUM 金鑰並不會危害您的 Azure 帳戶安全。

其他人是否可能濫用我的 RUM 金鑰?

雖然其他人可能使用您的金鑰將錯誤的資訊傳送至 Azure,但有幾個錯誤的度量並不會變更路由,因為它會與我們所收到的所有其他度量一併納入考慮。 如果您需要變更金鑰,您可以重新產生金鑰,此時會捨棄舊的金鑰。

我是否需要將度量 JavaScript 放在所有網頁中?

「實際使用者度量」會隨著度量數目增加而變得更有價值。 儘管如此,是要將它放在所有網頁中,還是放在幾個選取的網頁中,仍是取決於您。 建議您一開始將它放在瀏覽次數最多且使用者應該至少會停留 5 秒的頁面中。

如果我使用「實際使用者度量」,「流量管理員」是否可以識別出使用者的相關資訊?

使用所提供的度量 JavaScript 時,「流量管理員」將可以檢視使用者的用戶端 IP 位址,以及他們所用本機 DNS 解析程式的來源 IP 位址。 「流量管理員」會在將用戶端 IP 位址截斷成無法識別出傳送度量的特定使用者之後,才使用該 IP 位址。

測量「實際使用者度量」的網頁是否必須使用「流量管理員」來進行路由?

否,不需要使用流量管理員。 流量管理員的路由端會與實際的使用者度量部分分開運作,雖然最好讓它們都在相同的 web 屬性中,但它們並不需要這麼做。

我是否必須在 Azure 區域裝載任何服務,才能搭配使用「實際使用者度量」?

否,您不需要在 Azure 上裝載任何伺服器端元件,實際使用者度量就能正常運作。 度量 JavaScript 所下載的單一像素影像,以及在不同 Azure 區域中執行它的服務,是由 Azure 所裝載並管理的。

使用「實際使用者度量」時,我的 Azure 頻寬使用量是否會增加?

如先前的回答中所述,「實際使用者度量」的伺服器端元件是由 Azure 所擁有和管理的。 這表示您的 Azure 頻寬使用量將不會增加,因為您使用的是「實際使用者度量」。 這並不包括 Azure 費用以外的任何頻寬使用量。 我們藉由只下載一個單一像素影像來測量連線到 Azure 區域的延遲,將使用的頻寬降到最低。

流量檢視

「流量檢視」有哪些功能?

「流量檢視」是「流量管理員」的一項功能,可協助您進一步了解使用者及他們的體驗情況。 它會使用「流量管理員」所收到的查詢和此服務所維護的網路延遲智慧表格,來提供您下列資訊:

  • 使用者從哪些區域連線到您在 Azure 中的端點。
  • 有多少使用者從這些區域連線。
  • 要路由傳送到其中的 Azure 區域。
  • 使用者連線到這些 Azure 區域時的延遲體驗。

此資訊除了以未經處理資料的形式供您下載之外,也可供您透過入口網站中的地理對應重疊和表格式檢視取用。

我如何從使用「流量檢視」受益?

「流量檢視」可提供您「流量管理員」所接收流量的整體檢視。 尤其是可用來了解您的使用者群從何處連線,以及同樣重要的是他們的平均延遲體驗。 您可以接著使用此資訊來找出所需專注的領域,例如,將您的 Azure 電腦設備擺設區域擴充到可以為這些使用者提供較低延遲的區域。 您可以使用「流量查看」衍生的另一個見解是查看不同區域的流量模式,進而協助您決定在這些區域中增加或減少庫存量。

「流量檢視」與透過 Azure 監視器提供的「流量管理員」計量有何不同?

「Azure 監視器」可用來了解設定檔及其端點所收到流量的彙總層級。 它也可以顯示端點的健康情況檢查結果,來讓您追蹤端點的健康狀態。 當您需要超越這些範圍,並瞭解您的終端使用者在區域層級連線到 Azure 的體驗時,您可以使用「流量視圖」來達成此目標。

「流量檢視」是否使用「EDNS 用戶端子網路」資訊?

由 Azure 流量管理員提供的 DNS 查詢確實會考量 ECS 資訊,以增加路由的精確度。 但是,當建立其中顯示使用者連線來源的資料集時,「流量檢視」僅使用 DNS 解析程式的 IP 位址。

「流量檢視」會使用多少天的資料?

流量視圖會建立其輸出,其方式是在您于一天前的七天內處理資料。 這是一個移動時段,每次您瀏覽時都會使用最新的資料。

「流量檢視」如何處理外部端點?

當您在流量管理員設定檔中使用裝載于 azure 區域外部的外部端點時,您可以選擇將其對應至 azure 區域(這是其延遲特性的 proxy) (如果您使用效能路由方法) ,則這是必要的。 如果有此 Azure 區域對應,則在建立流量查看輸出時將會使用該 Azure 區域的延遲計量。 如果未指定任何 Azure 區域,這些外部端點的資料中就不會有任何延遲資訊。

我是否必須為訂用帳戶中的每個設定檔啟用「流量檢視」?

在預覽期間,「流量檢視」會在訂用帳戶層級啟用。 作為我們在公開推出之前所做的改進的一部分,您現在可以在設定檔層級啟用「流量檢視」,以便能更細微地啟用此功能。 根據預設,「流量檢視」將針對設定檔停用。

注意

如果您在預覽期間於訂用帳戶層級啟用「流量檢視」,現在就必須針對該訂用帳戶下的每個設定檔,將它重新啟用。

我是否可以關閉「流量檢視」?

您可以使用入口網站或 REST API,針對任何設定檔關閉「流量檢視」。

「流量檢視」如何計費?

「流量檢視」價格取決於用來建立輸出的資料點數目。 目前,唯一支援的資料類型是您設定檔所接收的查詢。 此外,您只需針對已啟用流量視圖時所執行的處理付費。 這意謂著如果您在一個月中的某個期間啟用「流量檢視」,而在其他期間關閉此功能,則只有在啟用此功能之期間處理的資料點會列入您的帳單中。

流量管理員端點

可以將流量管理員用於來自多個訂用帳戶的端點嗎?

Azure Web Apps 不能使用多個訂用帳戶的端點。 Azure Web Apps 規定 Web Apps 使用的任何自訂網域名稱只能在單一訂用帳戶內使用。 您無法使用來自具有相同功能變數名稱之多個訂用帳戶的 Web Apps。

對於其他端點類型,可以使用流量管理員與多個訂用帳戶的端點。 在 Resource Manager 中,來自任何訂用帳戶的端點都可以新增至流量管理員,只要設定流量管理員設定檔的人員具有端點的讀取權限即可。 您可以使用 azure 角色型存取控制 (AZURE RBAC 角色) 來授與這些許可權。 您可以使用Azure PowerShellAzure CLI,來新增其他訂用帳戶的端點。

我可以使用流量管理員來設定雲端服務「預備」位置嗎?

是的。 雲端服務「預備」位置可在流量管理員中設定為外部端點。 健康情況檢查仍然以 Azure 端點費率計費。

流量管理員是否支援 IPv6 端點?

流量管理員目前未提供 IPv6 可定址的名稱伺服器。 不過,連接到 IPv6 端點的 IPv6 用戶端仍然可以使用流量管理員。 用戶端不會直接向流量管理員提出 DNS 要求。 相反地,用戶端會使用遞迴 DNS 服務。 僅支援 IPv6 的用戶端會透過 IPv6 將要求傳送至遞迴 DNS 服務。 然後,遞迴服務應該就能夠使用 IPv4 來連絡流量管理員名稱伺服器。

流量管理員會回應端點的 DNS 名稱或 IP 位址。 有兩個選項可以支援 IPv6 端點。 您可以將端點新增為具有相關聯 AAAA 記錄的 DNA 名稱,而流量管理員將會對該端點執行健康狀態檢查,並在查詢回應中以 CNAME 記錄類型傳回它。 您也可以直接使用 IPv6 位址新增該端點,而流量管理員會在查詢回應中傳回 AAAA 類型記錄。

可以使用流量管理員搭配相同區域中的多個 Web 應用程式嗎?

通常,流量管理員用於將流量導向不同區域中部署的應用程式。 不過,也可用於應用程式在相同區域中有多個部署時。 流量管理員 Azure 端點不允許將相同 azure 區域中的多個 Web 應用程式端點新增至相同的流量管理員設定檔。

如何? 將流量管理員設定檔的 Azure 端點移至不同的資源群組或訂用帳戶嗎?

與流量管理員設定檔相關聯的 Azure 端點,是使用其資源識別碼來追蹤的。 當作為端點使用的 Azure 資源 (例如,公用 IP、傳統雲端服務、WebApp 或以嵌套方式使用的另一個流量管理員設定檔) 移至不同的資源群組或訂用帳戶時,其資源識別碼會變更。 在此情況下,目前您必須先刪除端點,然後再將端點加回設定檔中,以更新流量管理員設定檔。

流量管理員端點監視

流量管理員有能力從 Azure 區域失敗中恢復嗎?

流量管理員在 Azure 中是提供高可用性應用程式的一個重要元件。 若要提供高可用性,流量管理員必須擁有極高的可用性,並且可從區域失敗中恢復。

根據設計,流量管理員元件可從任何 Azure 區域的全面失敗中恢復。 此恢復功能適用於所有流量管理員元件︰DNS 名稱伺服器、API、儲存層及端點監視服務。

萬一整個 Azure 區域停機,也能預期流量管理員會持續正常運作。 在多個 Azure 區域中部署的應用程式可依賴流量管理員,將流量導向其應用程式的可用執行個體。

資源群組位置的選擇如何影響流量管理員?

流量管理員是單一全域服務。 不是區域。 如何選擇資源群組位置,對於部署在該資源群組中的流量管理員設定檔而言,並沒有差別。

Azure Resource Manager 需要所有資源群組指定位置,這會決定部署在該資源群組中資源的預設位置。 當您建立流量管理員設定檔時,會在資源群組中建立。 所有流量管理員設定檔都使用全域當作位置,覆寫資源群組預設值。

如何判斷每個端點目前的健全狀況?

每個端點的目前監視狀態以及整體設定檔都會顯示於 Azure 入口網站中。 您也可以透過流量監視 REST APIPowerShell cmdlets跨平台 Azure CLI 取得此資訊。

您也可以使用 Azure 監視器來追蹤端點的健康情況,並查看它們的視覺效果表示法。 如需如何使用 Azure 監視器的相關資訊,請參閱 Azure 監視文件

我可以監視 HTTPS 端點嗎?

是的。 流量管理員支援透過 HTTPS 探查。 在監視組態中將 HTTPS 設定為通訊協定。

流量管理員無法提供任何憑證驗證,包括:

  • 不會驗證服務器端憑證
  • 未驗證 SNI 伺服器端憑證
  • 不支援用戶端憑證

新增端點時,使用 IP 位址還是 DNS 名稱?

流量管理員支援使用三種方式來新增要參照的端點:作為 DNS 名稱、IPv4 位址和 IPv6 位址。 如果端點新增為 IPv4 或 IPv6 位址,則查詢回應分別是 A 或 AAAA 記錄類型。 如果端點已新增為 DNS 名稱,則查詢回應會是 CNAME 記錄類型。 只有在端點的類型為外部時,才允許將端點新增為 IPv4 或 IPv6 位址。 三端點定址類型支援所有路由方法和監視設定。

新增端點時,可以使用哪些類型的 IP 位址?

流量管理員可讓您使用 IPv4 或 IPv6 位址來指定端點。 有幾個限制,如下所示:

  • 不允許對應至保留私人 IP 位址空間的位址。 這些位址包含 RFC 1918、RFC 6890、RFC 5737、RFC 3068、RFC 2544 和 RFC 5771 中所呼叫的位址
  • 位址不得包含任何連接埠號碼 (您可以在設定檔組態設定中指定要使用的連接埠)
  • 在相同的設定檔中,不能有兩個端點具有相同的目標 IP 位址

我可以在單一設定檔內使用不同的端點定址類型嗎?

否,流量管理員不允許您混合設定檔內的端點定址類型,除了具有多值路由類型的設定檔案例之外,您可以在其中混用 IPv4 和 IPv6 網址類別型

當傳入查詢的記錄類型與端點的定址類型相關聯的記錄類型不同時,會發生什麼事?

收到設定檔的查詢時,流量管理員會先尋找需要根據指定路由方法和端點健康狀態所傳回的端點。 它接著會在根據下表傳回回應之前,查看傳入查詢中所要求的記錄類型以及與端點建立關聯的記錄類型。

針對任何具有 MultiValue 以外之路由方法的設定檔:

傳入查詢要求 端點類型 提供的回應
ANY A/AAAA/CNAME 目標端點
A A/CNAME 目標端點
A AAAA NODATA
AAAA AAAA/CNAME 目標端點
AAAA A NODATA
CNAME CNAME 目標端點
CNAME A/AAAA NODATA

針對路由方法設定為 MultiValue 的設定檔:

傳入查詢要求 端點類型 提供的回應
ANY 混用 A 和 AAAA 目標端點
A 混用 A 和 AAAA 僅限 A 類型的目標端點
AAAA 混用 A 和 AAAA 僅限 AAAA 類型的目標端點
CNAME 混用 A 和 AAAA NODATA

我可以在巢狀設定檔中使用具有 IPv4/IPv6 定址端點的設定檔嗎?

是,您可以使用例外狀況:多數值型別的設定檔不能是嵌套設定檔集中的父設定檔。

我在流量管理員設定檔中停止了 web 應用程式端點,但即使在重新開機後,也不會收到任何流量。 我該怎麼辦?

當 Azure web 應用程式端點停止時流量管理員會停止檢查其健康情況,並只在偵測到端點已重新開機後才重新開機健康情況檢查。 若要避免這種延遲,在重新啟動該端點之後,請在「流量管理員」設定檔中停用然後重新啟用該端點。

即使我的應用程式不支援 HTTP 或 HTTPS,還是可以使用流量管理員?

是的。 您可以指定 TCP 作為監視通訊協定,流量管理員可以起始 TCP 連線,並且等待端點的回應。 如果端點在逾時期間內以建立連線的回應來回覆連線要求,則該端點會標示為狀況良好。

使用 TCP 監視時需要端點的哪些特定回應?

使用 TCP 監視時,流量管理員會啟動三向 TCP 交握,方法是將 SYN 要求傳送至端點的指定連接埠。 然後,它會等候來自端點的 SYN ACK 回應一段時間, (在 [超時設定]) 中指定。

  • 如果在監視設定中指定的超時時間內收到 SYN ACK 回應,則該端點會視為狀況良好。 當 fin 或 fin 認可定期終止通訊端時,就是來自流量管理員的預期回應。
  • 如果在指定的超時時間之後收到 SYN ACK 回應,流量管理員將會回應 RST 以重設連接。

流量管理員將我的使用者從狀況不良的端點移開時間有多快?

流量管理員提供多項設定,可協助您控制流量管理員設定檔的容錯移轉行為,如下所示:

  • 您可以將探查間隔設定為 10 秒,指定流量管理員更頻繁地探查端點。 這可確保能夠立即偵測到狀況不良的任何端點。
  • 您可以指定健康情況檢查要求超時之前的等候時間, (最小超時值為5秒) 。
  • 您可以指定在端點標示為狀況不良之前,可以發生多少次失敗。 這個值最低可以為 0,只要端點的第一次健康情況檢查失敗,就會標示為狀況不良。 不過,對於容許失敗次數使用最小值 0,可能會導致因為在探查時可能發生的任何暫時性問題,讓端點離開輪替。
  • 您可以將 DNS 回應的存留時間 (TTL) 指定為最低的 0。 如此一來,DNS 解析程式就無法快取回應,而且每個新的查詢都會取得包含流量管理員所擁有之最新健康情況資訊的回應。

藉由使用這些設定,流量管理員可以提供在端點變成狀況不良之後 10 秒內的容錯移轉,以及針對對應設定檔進行 DNS 查詢。

如何為設定檔中不同的端點指定不同監視設定?

流量管理員監視設定是在各個設定檔層級。 如果您只需要為一個端點使用不同的監視設定,可以藉由讓該端點成為巢狀設定檔來完成,其監視設定與父代設定檔不同。

如何將 HTTP 標頭指派給我端點的流量管理員健康狀態檢查?

流量管理員可讓您在對您端點起始的 HTTP(S) 健康狀態檢查中指定自訂標頭。 如果您想要指定自訂標頭,則可以在設定檔層級 (適用於所有端點) 或在端點層級指定。 如果標頭定義于這兩個層級,則在端點層級指定的標頭將會覆寫設定檔層級1。 此狀況的一個常見使用案例是指定主機標頭,以將流量管理員要求正確地路由至裝載於多租用戶環境的端點。 另一個使用案例是從端點的 HTTP () 要求記錄中找出流量管理員要求

端點健全狀況檢查使用哪一個主機標頭?

如果未提供自訂主機標頭設定,則流量管理員所使用主機標頭即為設定檔中所設定端點目標的 DNS 名稱 (如果可用)。

健康情況檢查是從哪些 IP 位址產生?

請參閱這篇文章,以瞭解如何取得可從中產生流量管理員健康情況檢查的 IP 位址清單。 您可以使用 REST API、Azure CLI 或 Azure PowerShell 來取得最新清單。 檢查列出的 ip,以確保端點允許來自這些 IP 位址的連入連線來檢查其健康情況狀態。

使用 Azure PowerShell 的範例:

$serviceTags = Get-AzNetworkServiceTag -Location eastus
$result = $serviceTags.Values | Where-Object { $_.Name -eq "AzureTrafficManager" }
$result.Properties.AddressPrefixes

注意

公用 IP 位址可能會變更,恕不另行通知。 請務必使用服務標記探索 API 或可下載的 JSON 檔案來取得最新資訊。

流量管理員會對端點進行多少健康情況檢查?

流量管理員對於您端點的健康情況檢查數目取決於下列項目:

  • 您為監視間隔所設定的值 (較小間隔表示在任何指定時間期間內有更多要求進入端點)。
  • 產生健康情況檢查的位置數目 (您可以預期這些檢查列在上述常見問題集的 IP 位址)。

如果我的其中一個端點關閉,我如何取得通知?

流量管理員所提供的其中一個計量是設定檔中端點的健全狀態。 您可以將此視為設定檔中所有端點的彙總 (例如,您的端點中 75% 是健康的),或是依端點層級的端點彙總。 流量管理員計量會透過 Azure 監視器公開,您可以使用它的警示功能,在端點的健康狀態有所變更時,收到通知。 如需詳細資訊,請參閱流量管理員計量和警示

流量管理員巢狀設定檔

如何設定巢狀設定檔?

您可以使用 Azure Resource Manager 和傳統 Azure REST API、Azure PowerShell Cmdlet 及跨平台 Azure CLI 命令來設定巢狀流量管理員設定檔。 您也可以透過新的 Azure 入口網站來支援它們。

流量管理員支援幾層巢狀結構?

設定檔的巢狀結構深度最多可達 10 層。 不允許「迴圈」。

在同一個「流量管理員」設定檔中,是否可以將其他端點類型與巢狀子設定檔混合使用?

是的。 對於在設定檔內如何結合不同類型的端點,並沒有任何限制。

巢狀設定檔如何套用計費模型?

使用嵌套設定檔並不會有負面影響。

流量管理員計費有兩個要素︰端點健康狀態檢查和數百萬個 DNS 查詢

  • 端點健康情況檢查:當子設定檔設定為父設定檔中的端點時,不會收取任何費用。 監視子設定檔中的端點將以一般方式計費。
  • DNS 查詢:每個查詢只計算一次。 查詢父設定檔而從子設定檔傳回端點時,只計入父設定檔內。

如需完整的詳細資料,請參閱流量管理員定價頁面

巢狀設定檔是否會對效能造成影響?

不會。 使用嵌套設定檔時,不會產生任何效能影響。

在處理每個 DNS 查詢時,流量管理員名稱伺服器會周遊設定檔階層內部。 父設定檔的 DNS 查詢可能會收到從子設定檔傳回端點的 DNS 回應。 無論您是使用單一設定檔或嵌套設定檔,都會使用單一 CNAME 記錄。 不需要針對階層中的每個設定檔建立 CNAME 記錄。

流量管理員如何計算父設定檔中的巢狀端點健康狀態?

父設定檔不會直接對子系執行健康狀態檢查, 子設定檔端點的健康狀態會用來計算子設定檔的整體健康狀態。 這項資訊會在巢狀設定檔階層中往上傳播,以判斷巢狀端點的健康狀態。 父設定檔會使用此彙總健康狀態,以決定是否可以將流量導向子設定檔。

下表描述流量管理員檢查巢狀端點健康狀態時的行為。

子設定檔監視狀態 父端點監視狀態 備註
停用。 已停用子設定檔。 已停止 父端點狀態為「已停止」,不是「已停用」。 停用的狀態會保留,表示您已停用父設定檔中的端點。
已降級。 至少有一個子設定檔端點的狀態為「已降級」。 線上︰子設定檔中「線上」端點的數目至少等於 MinChildEndpoints 的值。
CheckingEndpoint︰子設定檔中「線上」加 CheckingEndpoint 端點的數目至少等於 MinChildEndpoints 的值。
已降級︰其他情況。
系統會將流量傳遞給狀態為 CheckingEndpoint 的端點。 如果 MinChildEndpoints 設定太高,則端點一律會降級。
線上。 至少有一個子設定檔端點處於「線上」狀態。 沒有端點處於「已降級」狀態。 請參閱上方。
CheckingEndpoints。 至少有一個子設定檔端點是 'CheckingEndpoint'。 沒有端點是「線上」或「已降級」。 同上。
非使用中。 所有子設定檔端點不是「已停用」就是「已停止」,或者此設定檔沒有任何端點 已停止

後續步驟: