監視及疑難排解 Azure 運算子深入解析擷取代理程式
如需擷取代理程式的概觀,請參閱擷取代理程式概觀。
如果您注意到從擷取代理程式收集資料的問題,請使用本節中的資訊來修正常見問題或建立診斷套件。 您可以將診斷套件上傳至您在 Azure 入口網站中建立的支援票證。
擷取代理程式是軟體套件,因此診斷僅限於應用程式的運作。 我們不會提供作業系統或資源監視。 建議您使用標準工具,例如 snmpd、Prometheus 節點匯出工具或其他工具,將 OS 層級的資料、記錄和計量傳送至您自己的監視系統。 使用 Azure 監視器監視虛擬機器說明當您的擷取代理程式在 Azure VM 上執行時,可以使用的工具。
代理程式會將記錄和計量寫入 /var/log/az-aoi-ingestion/ 下的檔案。 如果代理程式因任何原因 (例如設定錯誤) 而無法啟動,stdout.log 檔案會包含人類可讀取的記錄,並說明問題。
計量是以簡單的人類易記形式回報。
必要條件
- 針對大部分的疑難排解技術,您需要對執行代理程式的 VM 進行 SSH 連線。
擷取代理程序診斷
若要收集診斷套件,請透過 SSH 連線到虛擬機器,並執行 /usr/bin/microsoft/az-aoi-ingestion-gather-diags
命令。 此命令會在您從系統複製的目前目錄中產生日期戳記 zip 檔案。
如果您已透過 Azure 監視器代理程式設定記錄收集,您可以在 Log Analytics 工作區的入口網站檢視中檢視擷取代理程序記錄,而且可能不需要收集診斷套件來偵錯您的問題。
注意
Microsoft 支援服務 調查問題時,可能會要求診斷套件。 診斷套件不包含任何客戶資料或任何認證的值。
所有來源的常見問題
問題大致分為四類。
- 代理程式設定錯誤,會使代理程式無法啟動。
- 從來源接收資料時發生問題 (通常是設定錯誤) 或網路連線發生問題。
- 將檔案上傳至資料產品的輸入儲存體帳戶時發生問題,通常是網路連線。
- 代理程式執行所在的 VM 發生問題。
代理程式無法啟動
徵兆:sudo systemctl status az-aoi-ingestion
顯示服務處於失敗狀態。
- 確保服務正在執行。
sudo systemctl start az-aoi-ingestion
- 查看 /var/log/az-aoi-ingestion/stdout.log 檔案,並檢查是否有任何回報的錯誤。 修正組態檔的任何問題,然後再次啟動代理程式。
Azure Operator Insights 中未顯示任何數據
徵兆:Azure 資料總管中未顯示任何資料。
- 檢查擷取代理程式 VM 與資料產品輸入儲存體帳戶之間的網路連線和防火牆設定。
- 檢查擷取代理程式的記錄,是否有上傳至 Azure 的錯誤。 如果記錄指向驗證問題,請檢查代理程式設定是否具有數據產品的正確接收設定和驗證。 然後重新啟動代理程式。
- 檢查擷取代理程式是否從其來源接收資料。 檢查網路與擷取代理程式之間的網路連線和防火牆設定。
MCC EDR 來源的問題
本節涵蓋 MCC EDR 來源特定的問題。
您也可以使用 MCC 所提供的診斷,或 Azure 運算子深入解析本身在 Azure 監視器中提供的診斷,協助識別及偵錯擷取問題。
MCC 無法連線
徵兆:MCC 報告 MSF 無法使用的警示。
- 檢查代理程式正在執行。
- 請確定已使用正確的 IP 和連接埠設定 MCC。
- 檢查來自代理程式的記錄,並查看其是否回報連線。 如果沒有,請檢查代理程式 VM 的網路連線,並確認防火牆並未封鎖連接埠 36001 的流量。
- 收集封包擷取,以查看連線失敗的位置。
Azure Operator Insights 中未出現任何 EDR
徵兆:Azure 資料總管中未顯示任何資料。
- 檢查 MCC 是否狀況良好且擷取代理程式正在執行。
- 檢查診斷套件中的擷取代理程序記錄,以找出上傳至 Azure 的錯誤。 如果記錄指向無效的連接字串或連線問題,請修正設定、連接字串或 SAS 權杖,然後重新啟動代理程式。
- 檢查儲存體帳戶上的網路連線和防火牆設定。
資料遺失或不完整
徵兆:Azure 監視器在 ADX 中顯示的傳入 EDR 速率低於預期。
- 檢查代理程式是否在所有 VM 上執行,而且不會報告診斷套件記錄中的錯誤。
- 確認代理程式 VM 未傳送超過評等負載。
- 檢查診斷套件中的代理程式計量,以取得已卸除的位元組/已卸除 EDR。 如果計量未顯示任何已卸除的資料,則 MCC 不會將資料傳送至代理程式。 檢查「已接收的位元組」計量,以查看要從 MCC 接收多少資料。
- 檢查代理程式 VM 並未多載 – 監視 CPU 和記憶體使用量。 特別是,請確定沒有其他程序從 VM 取得資源。
SFTP 提取來源的問題
本節涵蓋 SFTP 提取來源特定的問題。
您也可以使用 Azure 運算子深入解析本身在 Azure 監視器中提供的診斷,協助識別及偵錯擷取問題。
代理程式無法連線到 SFTP 伺服器
徵兆:不會將任何檔案上傳至 Azure Operator Insights。 代理程式記錄檔 /var/log/az-aoi-ingestion/stdout.log 包含連線 SFTP 伺服器的錯誤。
- 確認代理程式所使用的 SFTP 使用者和認證對 SFTP 伺服器有效。
- 檢查代理程式與 SFTP 伺服器之間的網路連線和防火牆設定。 根據預設,SFTP 伺服器必須開啟連接埠 22,才能接受 SFTP 連線。
- 檢查代理程式 VM 上的
known_hosts
檔案是否包含 SFTP 伺服器的有效公開 SSH 金鑰:- 在代理程式 VM 上執行
ssh-keygen -l -F *<sftp-server-IP-or-hostname>*
。 - 如果沒有輸出,則
known_hosts
不包含相符的項目。 請遵循設定 Azure 運算子深入解析擷取代理程式中的指示,為 SFTP 伺服器新增known_hosts
項目。
- 在代理程式 VM 上執行
不會將任何檔案上傳至 Azure 運算子深入解析
徵兆:Azure 資料總管中未顯示任何資料。 類別Ingestion
的記錄不會出現在 Azure Operator Insights 監視數據中,或包含錯誤。 相關數據類型的內嵌數據列數據品質計量數目為零。
- 檢查代理程式是否在所有 VM 上執行,且未報告記錄中的錯誤。
- 檢查檔案是否存在於 SFTP 伺服器上的正確位置,並檢查是否由於檔案來源設定而未排除檔案 (請參閱檔案遺失)。
- 確定已設定的 SFTP 使用者可以讀取 下
base_path
的所有目錄,但檔案來源組態不會排除。 - 檢查擷取代理程式 VM 與資料產品輸入儲存體帳戶之間的網路連線和防火牆設定。
檔案遺失
徵兆:Azure 資料總管中遺漏資料。 Azure Operator Insights 監視數據的類別Ingestion
記錄低於預期,或包含錯誤。 相關數據類型的擷取數據列數據品質計量數目低於預期。
- 檢查代理程式是否在所有 VM 上執行,且未報告記錄中的錯誤。 在診斷套件記錄中搜尋遺漏檔案的名稱,以尋找與該檔案相關的錯誤。
- 檢查檔案是否存在於 SFTP 伺服器上,並檢查是否由於檔案來源設定而未排除檔案。檢查檔案來源組態,並確認:
- 檔案存在於 SFTP 伺服器,在
base_path
中定義的路徑下。 確定檔案的檔案路徑中沒有要上傳的符號連結:擷取代理程式會忽略符號連結。 - 檔案的「上次修改」時間至少比此檔案來源最近上傳執行的時間還提早
settling_time
秒。 - 檔案的「上次修改」時間晚於
exclude_before_time
(若指定)。 - 相對於
base_path
的檔案路徑會比對include_pattern
所指定的規則運算式 (若指定)。 - 相對於
base_path
的檔案路徑不會符合exclude_pattern
所指定的規則運算式 (若有指定)。
- 檔案存在於 SFTP 伺服器,在
- 如果遺漏最近的檔案,請檢查診斷套件中的代理程序記錄,以確認擷取代理程式在預期時間內執行來源的上傳執行。 來源組態中的
cron
參數會提供預期的排程。 - 檢查代理程式 VM 並未多載 – 監視 CPU 和記憶體使用量。 特別是,請確定沒有其他程序從 VM 取得資源。
檔案上傳一次以上
徵兆:重複的資料會出現在 Azure 運算子深入解析中。
- 檢查擷取代理程式是否在先前上傳的診斷套件記錄檔中遇到可重試的錯誤,然後在上次成功上傳后 24 小時重試該上傳。 在此情況下,代理程式可能會在重試嘗試期間上傳重複的資料。 重複資料應該只會影響重試嘗試。
- 檢查組態檔中定義的檔案來源是否參閱非重疊的檔案集。 如果將多個檔案來源設定為從 SFTP 伺服器上的相同位置提取檔案,請使用
include_pattern
和exclude_pattern
組態欄位來指定每個檔案來源應考慮的不同檔案集。 - 如果您正在執行 SFTP 擷取代理程式的多個執行個體,請檢查針對每個代理程式設定的檔案來源不會與任何其他代理程式上的檔案來源重疊。 特別是,請查看意外從另一個代理程式組態複製的檔案來源組態。
- 如果您最近變更了已設定檔案來源的管線
id
,請使用exclude_before_time
欄位,以避免使用新的管線id
將檔案重新載入。 如需指示,請參閱變更 Azure 運算子深入解析擷取代理程式的設定。
相關內容
了解如何:
- 變更擷取代理程式的設定。
- 升級擷取代理程式 (部分機器翻譯)。
- 輪替擷取代理程式的祕密。
意見反映
https://aka.ms/ContentUserFeedback。
即將推出:我們會在 2024 年淘汰 GitHub 問題,並以全新的意見反應系統取代並作為內容意見反應的渠道。 如需更多資訊,請參閱:提交及檢視以下的意見反映: