Azure帳號充值 如何查看Azure伺服器歷史流量日誌

第一章：先釐清「歷史流量日誌」指的是哪一種

很多人一開始就想找「Azure 的歷史流量日誌」，但 Azure 裡的「流量」其實分散在不同層級：網路安全層（NSG/防火牆）、實體/虛擬機網卡層（例如診斷事件）、負載平衡與網路轉發層、甚至是應用本身的存取日誌。你要查的究竟是「誰連了誰、用哪個連線埠、封包是否被允許、還是應用回了什麼內容」？答案會直接決定你該看哪種日誌、在哪裡查。

一般最常見的需求可分成三類：

第一類是安全/連線事件：例如某個 IP 一段時間內是否被拒絕、某規則是否命中、是否有掃描或可疑連線。這通常對應 NSG Flow Logs 或防火牆診斷事件。

Azure帳號充值 第二類是網路吞吐與可用性觀測：例如特定 VM 的入站/出站量、延遲、錯誤。這往往透過監控指標、診斷資料與網路層事件來拼圖，並不一定是「逐筆封包」那種格式。

Azure帳號充值 第三類是應用層存取日誌：例如 Web 應用的請求路徑、回應碼、上游延遲。這通常來自 Web Apps、Application Gateway、Front Door 或自架構的日誌。

因此，本篇文章會用「你可能正在遇到的典型情境」來帶你找到正確日誌入口。你可以把它當成一份查詢地圖：先判斷層級，再用 Azure 內建的日誌服務做歷史查詢。

第二章：準備工作——先確認你的日誌是否真的有被啟用

要查「歷史」就必須先有資料。Azure 很多日誌需要你在部署當初或某個時間點啟用診斷設定、流量日誌或事件串流。你很可能看到的是「現在能查，但過去查不到」或「一片空白」。這不是你操作錯，而是資料在那段時間根本沒被產生。

建議你先做三件事：

第一，確認目標資源類型：你看的到底是 VM、NIC、VNet、NSG、Application Gateway 還是防火牆？不同資源對應不同設定頁面。

Azure帳號充值 第二，確認是否有設定「診斷設定（Diagnostic settings）」或「流量日誌（Flow Logs）」：這些設定決定資料是否會被送到 Log Analytics、儲存體或事件中樞。

第三，確認保留期間（Retention）：有些資料預設保留較短，超過期限就會被清除。即使你當初啟用過，也要注意保留策略。

在實務中，最常見的狀況是：你今天想查兩週前的流量，但 Log Analytics 的保留期可能只有 7 天；或你查的是 NSG，但當時該 NSG 沒啟用 flow logs。先把這些基本條件排除，後面你的查詢才有意義。

第三章：用 Log Analytics 查歷史流量——最常用的查詢入口

對多數「歷史」需求來說，答案通常在 Log Analytics（也就是你使用的日誌查詢服務）。如果你的流量日誌被送往 Log Analytics，你就能用 KQL（Kusto Query Language）去做時間範圍、條件篩選與聚合。

進入方式通常是：Azure 入口網站 → Log Analytics 工作區 → Logs（或「日誌」）。接著你會看到一個資料庫般的查詢環境。你要做的第一步是確定有哪些資料表（table）可用。

你可以在查詢畫面先用類似以下方式去找資料表（實際表名會依你啟用的功能不同而不同）：查詢「NSG flow logs」相關表、或「AzureDiagnostics」等診斷表。很多人跳過這步，直接寫查詢語句，結果因為表名對不上而一直以為沒有資料。

一旦你定位到正確資料表，就可以開始查詢。一般查詢會包括：

1）時間範圍：例如過去 7 天、過去 24 小時或自訂起迄。

2）來源或目標 IP：判斷某個可疑 IP 是否命中。

3）方向與動作：入站/出站、允許/拒絕。

4）規則或安全群組：如果你想確認命中的是哪條規則。

5）協定與連接埠：針對掃描或特定應用埠的攻擊/誤連線。

這種查詢方式的優點是：你可以把「歷史」用一致的方式管理與分析。缺點是：你必須依賴事先啟用資料流。否則就只能查到啟用之後的資料。

第四章：查 NSG Flow Logs——從安全角度看「誰連上了我」

當你想追蹤「流量」而且特別在意連線是否被放行，NSG Flow Logs 通常是最直接的選擇。它會記錄與 NSG 相關的網路流量事件，包括來源/目的、協定、端口以及是否允許等資訊。它的價值在於把「網路安全層」的行為變成可查可分析的資料。

4.1 確認 NSG 與 Flow Logs 是否啟用

到你的 NSG（Network security group）資源頁面，查看是否啟用 flow logs（若採用的是較新的設定方式，也可能在診斷設定中看到）。啟用後通常需要一段時間才能開始在 Log Analytics 看到資料。

若你只有啟用某一個 NSG，但流量其實打到的是另一張 NIC 或另一個 NSG，那你就會查不到你以為存在的事件。這也是許多人遇到「資料很少」或「完全沒有」的常見原因。

4.2 在 Log Analytics 找到正確的資料表

到 Log Analytics 的 Logs 查詢畫面，先查資料表清單或用關鍵字尋找。你會看到與 flow logs 對應的表。因為不同部署與功能啟用的細節可能會影響表名，所以不要把表名當死。

找到表後，最基本的查詢就是按時間抓一段看資料結構是否符合你的預期。你通常需要確認欄位是否包含：時間戳、來源 IP、目的 IP、協定、目的端口、action（允許/拒絕）等。

4.3 典型查詢思路：先小範圍驗證，再擴大時間

不要一上來就查「過去一年」，那會拖慢也讓你難以校正條件。建議流程是：

第一步：抓過去 1 小時或 24 小時，確認欄位完整且你能看到事件。

第二步：把目標 IP 或目標端口套進去，確認查詢是否命中你要的行為。

第三步：再擴到你真正要的歷史範圍，並加入聚合（例如每分鐘/每小時的命中次數），把資料變成可讀的趨勢。

若你是要找可疑掃描，常見做法是以「同一來源 IP 在短時間內對多個目的埠」做聚合。若你是要排障，例如某服務突然連不上，就可以針對特定目的 IP、目的端口，並限制動作（例如拒絕）來縮小範圍。

第五章：查 Azure 防火牆/網路安全事件——把安全策略變成可追溯的紀錄

如果你使用的是 Azure 防火牆（Azure Firewall）或其他網路安全設備，流量日誌的產生與格式會更偏向「事件/診斷」而不是單純 NSG 的 flow。這時你同樣需要先確認診斷設定是否把資料送到 Log Analytics 或儲存體。

防火牆相關的事件常見用途是：確認被策略拒絕的原因、定位規則命中、追蹤跨區域或跨網段的連線行為。你查詢時要特別留意事件的動作欄位（Allow/Deny 或類似語意）以及規則名稱欄位（如果有提供）。

實務提醒：有些資料表可能同時包含多種診斷類型（不只防火牆）。你要用事件類型或資源欄位把範圍縮到只看你要的那部分，不然資料量會爆炸，導致查詢變慢或結果混雜。

第六章：查 VM 或 NIC 的網路診斷——當你要的是「主機視角」

NSG Flow Logs 更偏安全與連線事件；但如果你想看的是「伺服器層」發生了什麼，例如網卡是否重置、連線是否斷開、或更細的主機事件，那就需要從 VM 診斷與作業系統層資料著手。

這一類資料通常不是 Azure 原生直接提供的「流量日誌」那種逐筆格式，而是：

1）你安裝並配置的系統日誌（例如 Linux 的 syslog、Windows 的事件檢視器）。

2）Azure Monitor Agent 收集到的診斷與效能事件。

3）若你使用了特定監控代理或網路觀測工具，日誌會集中到 Log Analytics 或其他目的地。

Azure帳號充值 如果你的目標是排障（例如某應用連線失敗），通常流程會是：先用 NSG 或防火牆確認「到底有沒有被阻擋」；如果沒有被阻擋，才回到 VM 主機找「應用或服務是否異常」。用這種順序，你會更快定位問題。

第七章：查負載平衡或入口服務——從應用到網路的「請求軌跡」

當你說的流量是「對外的請求」例如 HTTP/HTTPS，很多時候最有效的不是看網路層，而是看入口服務的存取日誌或診斷事件，例如：

Application Gateway、Azure Front Door、Load Balancer（視你設定）、以及 Web App 相關的存取紀錄。

這些日誌能告訴你：某個時間點有多少請求、來源國家或 IP、URL 路徑、回應狀態碼、延遲與錯誤碼。它們跟 NSG flow logs 的不同在於：你得到的是「應用層/HTTP 層」的語意，對排查業務異常更直接。

Azure帳號充值 如果你的問題是「有人打不進來」：先看入口層是否有請求進來。若完全沒有，才回頭看是否被 NSG/防火牆擋掉。這樣的判斷路徑能避免陷入「到底是網路還是應用」的長時間猜測。

第八章：把資料變成可用的報表——查詢、篩選與聚合的實務技巧

查到資料只是第一步，真正讓你用得上的，是能回答問題的查詢結果。這裡提供一些常用且容易上手的技巧。

8.1 設定合理的時間範圍與節點

當你在看歷史流量時，時間範圍很容易設太大。建議用「先局部、後擴大」：例如先查最近 6 小時的趨勢，找出異常點後，再圍繞異常點擴大到前後幾天。這比直接拉長時間更容易節省查詢成本，也更容易看出規律。

8.2 先用少量條件驗證，再慢慢加條件

查詢結果為空時，常見不是「沒資料」，而是條件太嚴或欄位理解錯誤。例如你以為目的端口欄位叫 A，實際叫 B；或你以為 action 的值是 Allow/deny，實際在資料表裡是另一種表示。最好的方式是先取樣幾筆事件檢視欄位，理解後再加條件。

8.3 用聚合看趨勢，而不是只看明細

明細資料適合定位單一事件；但如果你在做安全監測或容量觀測，聚合才是關鍵。例如每分鐘拒絕次數、每小時連線數、某來源 IP 在一天內的命中埠數。聚合能把「噪音」變成「訊號」，讓你看到變化。

8.4 釐清「方向」與「來源/目的」的語意

在網路事件裡，「來源」和「目的」可能會因為日誌定義而與你的直覺相反。尤其在 NAT、反向代理或多層轉發情境下，目的 IP 可能是入口服務而不是最終主機。遇到這種情況，最有效的做法是先比對你已知的測試流量，確認欄位對應哪一端。

第九章：常見誤區與排查清單

下面列出一些在實務中最常遇到、也最浪費時間的狀況。你可以把它當作快速檢查清單。

9.1 查不到「過去」的資料

可能原因：未啟用 flow logs 或診斷設定、或保留期不足、或你查的 Log Analytics 其實不是資料送達的工作區。解法是回到資源的診斷設定頁面檢查送達目的地與啟用時間。

9.2 查詢語句跑得很慢或結果混亂

可能原因：時間範圍太大、未使用資源篩選、未限制事件類型或沒有先縮小目的 IP/端口。解法是先用小時間窗驗證並加上資源/欄位條件。

9.3 NSG 有啟用，但看不到預期事件

可能原因：該流量的實際落點不在那個 NSG（例如用了不同 NIC 或不同規則套用）、或方向與規則理解不同。解法是確認 NSG 的套用範圍，以及規則是否對應你觀測的入站/出站。

9.4 防火牆事件存在，但你不知道是哪個規則造成

可能原因：事件欄位未包含規則名稱，或診斷等級設定較低。解法是檢查診斷設定的類型與層級，並在查詢中優先使用動作欄位與核心識別資訊（時間、來源、目的、協定、目的端口）。

9.5 看到允許/拒絕，但仍不確定是否是「你要的那段流量」

可能原因：時間座標與時區、或你測試時的時間點與查詢範圍不一致。解法是先做一次可控測試（例如從已知 IP 連到已知端口），確認日誌時間落點，再回到歷史查詢校正。

第十章：一個可落地的查詢流程（從問題到結果）

最後我用一個「你真的遇到問題時」的流程，把前面的概念串起來。假設你想回答：「過去某天為什麼我的服務連不上？是否被拒絕？是網路層還是應用層？」

步驟一：先確定服務入口層

若是 HTTP/HTTPS，先看入口服務（App Gateway/Front Door/Web App）的存取或診斷是否有請求進來。若入口層完全沒有請求，通常問題在前置網路或 DNS/路由；若有請求但回應異常，問題可能在應用。

步驟二：用 NSG Flow Logs 或防火牆事件確認連線是否被拒

針對服務所在的目的 IP、目的端口（例如 443），再加上拒絕動作，篩出在那段時間內最明顯的來源 IP 或規則命中。這能快速回答「到底是不是安全策略擋掉了」。

步驟三：若沒有拒絕，再回到主機與應用

如果網路層沒有拒絕，但你仍看到連線失敗，那就回到 VM/容器/應用層看錯誤事件或連線逾時。通常你需要把應用的錯誤時間點對齊網路層事件，定位是哪一段流程失效。

步驟四：把你找到的關鍵結果做成趨勢

最後不要只停在單次事件。你可以把拒絕次數或連線數按小時聚合，做成每週/每月的趨勢視圖。這樣下次類似異常發生時，你不用從零開始找入口。

結語：查歷史流量的核心是「資料來源 + 啟用狀態 + 正確篩選」

查看 Azure 伺服器歷史流量日誌，真正的關鍵不是寫出多厲害的查詢語句，而是先確定你要看的流量層級、確認日誌是否在目標期間已被啟用、並用一致的方法做時間與條件篩選。NSG Flow Logs 適合做安全與連線行為的追蹤；防火牆診斷適合策略層的追溯；入口服務與應用存取日誌適合回答「請求是否進來、回應是否異常」。當你把這些拼在一起，歷史流量就會從一堆資料變成能解釋問題的證據。

如果你願意，我也可以依你實際環境（例如：是否用 NSG、是否有啟用診斷設定、流量是到 VM 還是到入口服務）給你一套更貼近現況的查詢步驟與篩選條件。你只要告訴我：目標是 VM 還是公開網站、你要找的是被拒絕還是延遲/錯誤、以及大致時間範圍即可。