共用方式為

針對 Linux 虛擬機器和擴展集上 Azure 監視器代理程式的疑難排解指引

  • 發行項

Azure 監視器代理程式概觀

進一步閱讀之前，您必須熟悉 Azure 監視器代理程式和資料收集規則。

詞彙

名稱 縮略字 描述
Azure 監視器代理程式 AMA 新的 Azure 監視器代理程式
資料收集規則 DCR 關於代理程式設定資料收集的規則，亦即要收集的內容、傳送目的地等等
Azure 監視器設定服務 AMCS 裝載於 Azure 中的區域服務，可控制此代理程式和其他 Azure 監視器部分的資料收集。 代理程式會呼叫此服務以擷取 DCR。
記錄端點 -- 用於將資料傳送至 Log Analytics 工作區的端點
計量端點 -- 用於將資料傳送至 Azure 監視器計量資料庫的端點。
Instance Metadata Service 與 Hybrid IMDS 和 HIMDS 裝載於 Azure 中的服務，可提供目前執行中的虛擬機器相關資訊，以及個別提供擴展集 (透過 IMDS) 和已啟用 Arc 的伺服器 (透過 HIMDS) 相關資訊
Log Analytics 工作區 LAW Azure 監視器中的目的地，您可以將代理程式收集的記錄傳送至此
自訂計量 -- Azure 監視器中的目的地，您可以將代理程式收集的客體計量傳送至此

基本疑難排解步驟

請遵循下列步驟，針對在 Linux 虛擬機器上執行的最新版 Azure 監視器代理程式進行疑難排解：

  1. 仔細檢閱此處的必要條件。

  2. 確認已成功安裝並佈建延伸模組，這會在您的電腦上安裝代理程式二進位檔：

    1. 開啟 Azure 入口網站 > 選取虛擬機器 > 從左側窗格開啟 [設定]：[擴充功能 + 應用程式] > 「AzureMonitorLinuxAgent」應會顯示的狀態為：「佈建成功」
    2. 如果您沒有看到列出的擴充功能，請檢查機器是否可以連線到 Azure，並使用下列命令尋找要安裝的擴充功能：
      az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
    3. 等候 10-15 分鐘，因為延伸模組可能處於轉換狀態。 如果顯示的內容仍然未如上方所示，請解除安裝並再次安裝擴充功能。
    4. 檢查您是否在機器上 /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ 位置的擴充功能記錄中看到任何錯誤

  3. 確認代理程式正在執行：

    1. 使用下列查詢，檢查代理程式是否在將活動訊號記錄發出至 Log Analytics 工作區。 如果「自訂計量」是 DCR 中唯一的目的地，那麼請略過：
      Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
    2. 檢查代理程式服務是否正在執行中 
      systemctl status azuremonitoragent
    3. 檢查您是否在機器上 /var/opt/microsoft/azuremonitoragent/log/mdsd.* 位置的核心代理程式記錄中看到任何錯誤

  4. 確認 DCR 存在且與虛擬機器相關聯：

    1. 如果使用 Log Analytics 工作區作為目的地，請確認 DCR 存在於與 Log Analytics 工作區相同的實體區域中。
    2. 開啟 Azure 入口網站 > 選取您的資料收集規則 > 從左側窗格開啟 [設定]：[資源] > 您應該會看到此處所列出的虛擬機器。
    3. 如果未列出，請按一下 [新增]，然後從資源選擇器中選取您的虛擬機器。 在所有 DCR 之間重複進行。

  5. 確認代理程式能夠從 AMCS 服務下載相關聯的 DCR：

    1. 檢查您是否在下列位置看到下載的最新 DCR：/etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/

收集 Syslog 的問題

如需如何針對 Azure 監視器代理程式 syslog 問題進行疑難排解的詳細資訊，請參閱這裡。

  • 服務品質 (QoS) 檔案 /var/opt/microsoft/azuremonitoragent/log/mdsd.qos 會以CSV 格式提供已處理事件的 15 分鐘匯總，並包含指定時間範圍內已處理 syslog 事件數量的相關資訊。 在追蹤 Syslog 事件擷取捨棄時，此檔案很有用。

    例如，下列片段顯示，在 2022-02-02-28T19:55:23.5432920Z 之前的 15 分鐘內，代理程式收到了 77 個 syslog 事件 (其中包含設備精靈和層級資訊)，並將 77 個上述事件傳送至上傳工作。 此外，代理程式上傳工作收到了 77 個 daemon.info 訊息，並成功全數上傳。

    #Time: 2022-02-28T19:55:23.5432920Z
#Fields: Operation,Object,TotalCount,SuccessCount,Retries,AverageDuration,AverageSize,AverageDelay,TotalSize,TotalRowsRead,TotalRowsSent
...
MaRunTaskLocal,daemon.debug,15,15,0,60000,0,0,0,0,0
MaRunTaskLocal,daemon.info,15,15,0,60000,46.2,0,693,77,77
MaRunTaskLocal,daemon.notice,15,15,0,60000,0,0,0,0,0
MaRunTaskLocal,daemon.warning,15,15,0,60000,0,0,0,0,0
MaRunTaskLocal,daemon.error,15,15,0,60000,0,0,0,0,0
MaRunTaskLocal,daemon.critical,15,15,0,60000,0,0,0,0,0
MaRunTaskLocal,daemon.alert,15,15,0,60000,0,0,0,0,0
MaRunTaskLocal,daemon.emergency,15,15,0,60000,0,0,0,0,0
...
MaODSRequest,https://e73fd5e3-ea2b-4637-8da0-5c8144b670c8_LogManagement,15,15,0,455067,476.467,0,7147,77,77

疑難排解步驟

  1. 請先檢閱一般 Linux AMA 的疑難排解步驟。 如果代理程式發出活動訊號，請繼續進行步驟 2。

  2. 剖析的組態儲存在 /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/。 檢查是否已定義 Syslog 集合，並檢查記錄目的地是否與在 DCR UI / DCR JSON 中建構的目的地相同。

    1. 如果是，請繼續進行步驟 3。 如果否，問題出在組態工作流程之中。
    2. 調查 /var/opt/microsoft/azuremonitoragent/log 底下的 mdsd.err、mdsd.warn、mdsd.info 檔案，看看是否可能存在組態錯誤。

  3. 驗證 Syslog 集合工作流程的配置，以確保所有必要的項目都已就緒且可供存取：

    1. 針對 rsyslog 使用者，請確定檔案 /etc/rsyslog.d/10-azuremonitoragent.conf 存在、不是空的，而且可供 rsyslog 精靈 (syslog 使用者) 存取。
      1. 檢查在 /etc/rsyslog.conf 和 /etc/rsyslog.d/* 的 rsyslog 組態，以檢視您是否有任何輸入繫結至非預設規則集，因為來自這些輸入的訊息不會轉送到 Azure 監視器代理程式。 例如，來自以非預設規則集 (例如 input(type="imtcp" port="514" ruleset="myruleset")) 所設定輸入的訊息不會轉送。
    2. 針對 syslog-ng 使用者，請確定檔案 /etc/syslog-ng/conf.d/azuremonitoragent.conf 存在、不是空的，而且可供 syslog-ng 精靈 (syslog 使用者) 存取。
    3. 請確定檔案 /run/azuremonitoragent/default_syslog.socket 存在且可分別由 rsyslog 或 syslog-ng 進行存取。
    4. 藉由參考這裡的指引，檢查 syslog 精靈佇列並未因溢位而導致上傳失敗：因為 AMA Linux 代理程式上發生磁碟空間已滿問題而未上傳 Rsyslog 資料

  4. 若要進一步偵錯 syslog 事件擷取，您可以在檔案 /etc/default/azuremonitoragent 中 MDSD_OPTIONS 的結尾附加追蹤旗標 -T 0x2002，然後重新啟動代理程式：

    export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"

  5. 重現加上了追蹤旗標的問題之後，您會在 /var/opt/microsoft/azuremonitoragent/log/mdsd.info 中找到更多偵錯資訊。 針對檔案檢查 syslog 收集問題 (例如剖析/處理/組態/上傳錯誤) 的可能原因。

    警告

    請務必在偵錯工作階段之後移除追蹤旗標設定 -T 0x2002 ，因為該設定會產生許多追蹤陳述式，可能會更快塞滿磁碟，或讓以視覺化方式剖析記錄檔變得困難。

針對已啟用 Arc 的伺服器問題進行疑難排解

如果在檢查基本疑難排解步驟之後，您看不到發出記錄的 Azure 監視器代理程式，或發現 /var/opt/microsoft/azuremonitoragent/log/mdsd.err 記錄檔中的「無法從 IMDS 端點取得 MSI 權杖」錯誤，則 syslog 使用者可能不是群組的成員 himds。 如果使用者不是此群組的成員，請將 syslog 使用者新增至 himds 使用者群組。 視需要建立使用者 syslog 和群組 syslog，並確定該使用者位於該群組中。 如需詳細資訊，請參閱這裡已啟用 Azure Arc 的伺服器驗證需求。