對 Log Analytics Linux 代理程式的問題進行疑難排解
此文章提供的說明可協助您針對 Azure 監視器中適用於 Linux 的 Log Analytics 代理程式錯誤進行疑難排解。
警告
本文參考 CentOS,這是處於終止服務 (EOL) 狀態的 Linux 發行版。 請據此考慮您的使用方式和規劃。 如需詳細資訊,請參閱 CentOS 生命週期結束指導。
Log Analytics 疑難排解工具
Log Analytics 代理程式 Linux 疑難排解工具是一個指令碼,設計目的是協助尋找和診斷 Log Analytics 代理程式的問題。 此工具在代理程式安裝時即已自動隨附。 診斷問題的第一個步驟應該是執行此工具。
使用疑難排解工具
請使用 Log Analytics 代理程式,將下列命令貼到電腦的終端機視窗中,以執行疑難排解工具:
sudo /opt/microsoft/omsagent/bin/troubleshooter
手動安裝
安裝 Log Analytics 代理程式時,即會自動隨附疑難排解工具。 如果安裝失敗,您也可以手動安裝此工具:
- 確認電腦上已安裝 GNU 專案偵錯工具 (GDB),因為疑難排解工具與其相輔相成。
- 將疑難排解工具套件複製到您的電腦:
wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
- 解除封裝套件:
tar -xzvf omsagent_tst.tar.gz
- 執行手動安裝:
sudo ./install_tst
涵蓋的案例
疑難排解工具會檢查是否有下列狀況:
- 代理程式狀況不良,活動訊號無法正常運作。
- 代理程式未啟動,或無法連線到 Log Analytics。
- 代理程式 Syslog 無法運作。
- 代理程式使用大量 CPU 或記憶體。
- 代理程式有安裝問題。
- 代理程式自訂記錄無法運作。
- 無法收集代理程式記錄。
如需詳細資訊,請參閱 GitHub 上的疑難排解工具文件。
注意
當您遇到問題時,請執行記錄收集器工具。 一開始就準備好相關記錄,將有助於支援小組更快針對您的問題進行疑難排解。
清除並重新安裝 Linux 代理程式
全新重新安裝代理程式可修正大部分的問題。 支援小組的第一個建議可能就是執行這項工作,讓代理程式回到未損毀的狀態。 執行疑難排解工具和記錄收集器工具以及嘗試全新重新安裝,有助於更快解決問題。
下載清除指令碼:
$ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh
使用 sudo 權限執行清除指令碼:
$ sudo sh purge_omsagent.sh
重要的記錄位置和記錄收集器工具
檔案 | Path |
---|---|
Log Analytics Linux 代理程式記錄檔 | /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log |
Log Analytics 代理程式組態記錄檔 | /var/opt/microsoft/omsconfig/omsconfig.log |
建議您使用記錄收集器工具擷取重要記錄以供進行疑難排解,或為提交 GitHub 問題預作準備。 如需工具及其執行方法的詳細資訊,請參閱 OMS Linux 代理程式記錄收集器。
重要組態檔案
類別 | 檔案位置 |
---|---|
Syslog | /etc/syslog-ng/syslog-ng.conf 、/etc/rsyslog.conf 或 /etc/rsyslog.d/95-omsagent.conf |
效能、Nagios、Zabbix、Log Analytics 輸出和一般代理程式 | /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf |
額外設定 | /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf |
注意
在編輯效能計數器和 Syslog 的設定檔時,如果工作區集合設定是在 Azure 入口網站中的 [代理程式設定] 進行,則會覆寫設定檔。 若要停用所有代理程式的設定,請在 [舊版代理程式管理] 停用集合。 單一代理程式請執行下列指令碼:
sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*
安裝錯誤碼
錯誤碼 | 意義 |
---|---|
NOT_DEFINED | 因未安裝必要的相依性,所以不會安裝 auoms auditd 外掛程式。 auoms 安裝失敗。 安裝套件 auditd。 |
2 | 提供給殼層組合的選項無效。 請執行 sudo sh ./omsagent-*.universal*.sh --help 以了解使用方式。 |
3 | 未提供任何選項給殼層組合。 請執行 sudo sh ./omsagent-*.universal*.sh --help 以了解使用方式。 |
4 | 套件類型不正確「或」Proxy 設定無效。 omsagent-rpm.sh 套件只能安裝在 RPM 型系統上。 omsagent-deb.sh 套件只能安裝在 Debian 型系統上。 建議您使用最新版本的通用安裝程式。 也請進行檢閱,以驗證 Proxy 設定。 |
5 | 必須以 root 身分執行殼層組合,「或」上線期間傳回 403 錯誤。 請使用 sudo 執行命令。 |
6 | 套件架構不正確「或」上線期間傳回 200 錯誤。 omsagent-*x64.sh 套件只能安裝在 64 位元系統上。 omsagent-*x86.sh 套件只能安裝在 32 位元系統上。 從最新版本下載架構的正確套件。 |
17 | OMS 套件安裝失敗。 查看命令的輸出中是否有 root 失敗。 |
18 | OMSConfig 套件安裝失敗。 查看命令的輸出中是否有 root 失敗。 |
19 | OMI 套件安裝失敗。 查看命令的輸出中是否有 root 失敗。 |
20 | SCX 套件安裝失敗。 查看命令的輸出中是否有 root 失敗。 |
21 | 提供者套件安裝失敗。 查看命令的輸出中是否有 root 失敗。 |
22 | 組合套件安裝失敗。 查看命令的輸出中是否有 root 失敗 |
23 | 已經安裝 SCX 或 OMI 套件。 使用 --upgrade 而非 --install 來安裝殼層組合。 |
30 | 內部組合錯誤。 提出 GitHub 問題,並附上輸出的詳細資料。 |
55 | 不支援 openssl 版本「或」無法連線到 Azure 監視器「或」已鎖定 dpkg「或」遺漏 curl 程式。 |
61 | 遺失 Python ctypes 程式庫。 安裝 Python ctypes 程式庫或套件 (python-ctypes)。 |
62 | 遺漏 tar 程式。 安裝 tar。 |
63 | 遺漏 sed 程式。 安裝 sed。 |
64 | 遺漏 curl 程式。 請安裝 curl。 |
65 | 遺漏 gpg 程式。 請安裝 gpg。 |
上架錯誤碼
錯誤碼 | 意義 |
---|---|
2 | 提供給 omsadmin 指令碼的選項無效。 請執行 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h 以了解使用方式。 |
3 | 提供給 omsadmin 指令碼的組態無效。 請執行 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h 以了解使用方式。 |
4 | 提供給 omsadmin 指令碼的 Proxy 無效。 請確認 Proxy,並查看 HTTP Proxy 的使用文件。 |
5 | 從 Azure 監視器收到 403 HTTP 錯誤。 如需詳細資訊,請參閱 omsadmin 指令碼的完整輸出。 |
6 | 從 Azure 監視器收到非 200 HTTP 錯誤。 如需詳細資訊,請參閱 omsadmin 指令碼的完整輸出。 |
7 | 無法連線到 Azure 監視器。 如需詳細資訊,請參閱 omsadmin 指令碼的完整輸出。 |
8 | 上架至 Log Analytics 工作區時發生錯誤。 如需詳細資訊,請參閱 omsadmin 指令碼的完整輸出。 |
30 | 內部指令碼錯誤。 提出 GitHub 問題,並附上輸出的詳細資料。 |
31 | 產生代理程式識別碼時發生錯誤。 提出 GitHub 問題,並附上輸出的詳細資料。 |
32 | 產生憑證時發生錯誤。 如需詳細資訊,請參閱 omsadmin 指令碼的完整輸出。 |
33 | 產生 omsconfig 的中繼組態時發生錯誤。 提出 GitHub 問題,並附上輸出的詳細資料。 |
34 | 中繼組態產生指令碼不存在。 請使用 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> 重試上架。 |
啟用偵錯記錄
OMS 輸出外掛程式偵錯
FluentD 允許使用外掛程式特定記錄層級,可讓您為輸入和輸出指定不同的記錄層級。 若要為 OMS 輸出指定不同的記錄層級,請在 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
編輯一般代理程式組態。
在 OMS 輸出外掛程式的設定檔結尾前面,將 log_level
屬性從 info
變更為 debug
:
<match oms.** docker.**>
type out_oms
log_level debug
num_threads 5
buffer_chunk_limit 5m
buffer_type file
buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
buffer_queue_limit 10
flush_interval 20s
retry_limit 10
retry_wait 30s
</match>
偵錯記錄功能可讓您查看 Azure 監視器的分批上傳 (依類型、資料項目數,以及傳送所花費的時間分隔)。
以下是啟用偵錯的記錄檔範例:
Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s
詳細資訊輸出
除了使用 OMS 輸出外掛程式,您也可以將資料項目直接輸出至 stdout
,其顯示在 Log Analytics Linux 代理程式記錄檔中。
在位於 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
的 Log Analytics 一般代理程式設定檔中,於每一行前面新增 #
,以將 OMS 輸出註解化:
#<match oms.** docker.**>
# type out_oms
# log_level info
# num_threads 5
# buffer_chunk_limit 5m
# buffer_type file
# buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
# buffer_queue_limit 10
# flush_interval 20s
# retry_limit 10
# retry_wait 30s
#</match>
在輸出外掛程式下面,移除每一行開頭的 #
,以取消註解下列區段:
<match **>
type stdout
</match>
問題:無法透過 Proxy 連線至 Azure 監視器
可能的原因
- 上線期間指定的 Proxy 不正確。
- 資料中心的核准清單中不包含 Azure 監視器和 Azure 自動化服務端點。
解決方法
使用下列命令搭配已啟用的
-v
選項,以便透過 Log Analytics Linux 代理程式重新上架至 Azure 監視器。 這可讓透過 Proxy 連線至 Azure 監視器的代理程式輸出詳細資訊:/opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v
請參閱更新 Proxy 設定一節,以驗證您是否已正確設定代理程式透過 Proxy 伺服器通訊。
請仔細檢查 Azure 監視器網路防火牆需求清單中概述的端點,是否已正確新增至允許清單。 如果您使用 Azure 自動化,其上方也會顯示必要的網路設定步驟連結。
問題:您在嘗試上架時收到 403 錯誤
可能的原因
- Linux 伺服器上的日期和時間不正確。
- 工作區識別碼和工作區金鑰不正確。
解決方法
- 使用命令日期檢查 Linux 伺服器上的時間。 如果時間為目前時間的 +/-15 分鐘,則上線失敗。 若要修正此情況,請更新 Linux 伺服器的日期和/或時區。
- 驗證您已安裝最新版的 Log Analytics Linux 代理程式。 最新版本現在會通知您時間差異是否造成上架失敗。
- 使用正確的工作區識別碼和工作區金鑰,遵循本文前面的安裝指示重新上線。
問題︰上架後您隨即在記錄檔中看到 500 與 404 錯誤
這是已知問題,第一次將 Linux 資料上傳至 Log Analytics 工作區時會發生此問題。 這個問題不會影響正在傳送的資料或服務體驗。
問題:您看到使用 100% CPU 的 omiagent
可能的原因
nss-pem 套件 v1.0.3-5.el7 中的迴歸造成嚴重的效能問題。 已知 Redhat/CentOS 7.x 發行版本中常發生此問題。 若要深入了解此問題,請參閱 1667121l:ibcurl 中的效能迴歸 (英文)。
效能相關的 Bug 不會隨時發生,而且很難重現。 如果在使用 omiagent 時遇到此問題,請使用指令碼 omiHighCPUDiagnostics.sh
,其會在超過特定閾值時收集 omiagent 的堆疊追蹤。
下載指令碼:
wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh
以 30% CPU 閾值執行診斷 24 小時:
bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30
呼叫堆疊會傾印到 omiagent_trace 檔案。 如果發現許多 Curl 和 NSS 函式呼叫,請遵循下列解決步驟。
解決方法
將 nss-pem 套件升級至 v1.0.3-5.el7_6.1:
sudo yum upgrade nss-pem
如果 nss-pem 不適用於升級 (大部分發生在 CentOS),請將 curl 降級為 7.29.0-46。 如果不小心執行 "yum update",curl 會升級至 7.29.0-51,會再次發生同樣的問題:
sudo yum downgrade curl libcurl
重新啟動 OMI:
sudo scxadmin -restart
問題:沒看到轉送的 Syslog 訊息
可能的原因
- 套用到 Linux 伺服器的設定不允許收集傳送的設備或記錄檔層級。
- Syslog 並未正確轉送到 Linux 伺服器。
- 每秒所轉送的訊息數目太大,以致無法處理 Log Analytics Linux 代理程式的基本設定。
解決方法
- 確認 Log Analytics 工作區 (適用於 Syslog) 中的組態具有所有設備和正確的記錄檔層級。 請參閱在 Azure 入口網站中設定 Syslog 集合。
- 驗證原生 syslog 傳訊精靈 (
rsyslog
、syslog-ng
) 能夠接收轉送的訊息。 - 檢查 Syslog 伺服器上的防火牆設定,確定不會封鎖訊息。
- 使用
logger
命令模擬給 Log Analytics 的 Syslog 訊息:
logger -p local0.err "This is my test message"
問題:您在 omsagent 記錄檔中收到「位址已在使用中」的錯誤
您會在 omsagent.log 中看到 [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224>
。
可能的原因
此錯誤指出 Linux 診斷延伸模組 (LAD) 已隨 Log Analytics Linux VM 延伸模組安裝。 其使用與 omsagent 相同的 Syslog 資料收集連接埠。
解決方法
以 root 身分執行下列命令。 請注意,25224 只是範例,您在環境中可能會看到 LAD 使用不同的連接埠號碼。
/opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229 sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf
然後,您需要編輯正確的
rsyslogd
或syslog_ng
組態檔,並變更 LAD 相關組態以寫入至連接埠 25229。如果 VM 執行的是
rsyslogd
,則要修改的檔案是/etc/rsyslog.d/95-omsagent.conf
(若有,否則即為/etc/rsyslog
)。 如果 VM 執行的是syslog_ng
,則要修改的檔案是/etc/syslog-ng/syslog-ng.conf
。重新啟動 omsagent
sudo /opt/microsoft/omsagent/bin/service_control restart
。重新啟動 Syslog 服務。
問題:您無法使用清除選項解除安裝 omsagent
可能的原因
- 已安裝 Linux 診斷延伸模組。
- 安裝了 Linux 診斷延伸模組後又解除安裝,但您仍看到 omsagent 正由 mdsd 使用所以無法移除的錯誤。
解決方法
- 解除安裝 Linux 診斷延伸模組。
- 移除機器下列位置的 Linux 診斷延伸模組檔案:
/var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/
和/var/opt/microsoft/omsagent/LAD/
。
問題:看不到任何 Nagios 資料
可能的原因
- omsagent 使用者沒有從 Nagios 記錄檔讀取資料的權限。
- 未在 omsagent.conf 檔案中取消註解 Nagios 來源和篩選。
解決方法
遵循這些指示,新增 omsagent 使用者以讀取 Nagios 檔案。
在位於
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
的 Log Analytics Linux 代理程式一般組態檔中,確定 Nagios 來源和篩選都已取消註解。<source> type tail path /var/log/nagios/nagios.log format none tag oms.nagios </source> <filter oms.nagios> type filter_nagios_log </filter>
問題︰您沒有看到任何 Linux 資料
可能的原因
- 上線至 Azure 監視器失敗。
- Azure 監視器的連線已封鎖。
- 虛擬機器已重新啟動。
- OMI 套件已手動升級為比 Log Analytics Linux 代理程式套件所安裝版本還新的版本。
- OMI 已凍結,封鎖 OMS 代理程式。
- DSC 資源在
omsconfig.log
記錄中記錄了「找不到類別」錯誤。 - Log Analytics 的資料代理程式已備份。
- DSC 記錄了目前的組態不存在。請執行 Start-DscConfiguration 命令與 -Path 參數來指定設定檔,並先建立目前的設定。」
omsconfig.log
,但沒有關於PerformRequiredConfigurationChecks
作業的記錄訊息存在。
解決方法
安裝所有相依性,例如 auditd 套件。
檢查下列檔案是否存在,以確認 Azure 監視器是否成功上線:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf
。 如果不成功,請使用 omsadmin.sh 命令列指示重新上線。如果使用 Proxy,請查看前文中的 Proxy 疑難排解步驟。
在某些 Azure 發佈系統中,omid OMI 伺服器精靈未在虛擬機器重新啟動後隨之啟動。 如果是這種情況,您不會看到 Audit、ChangeTracking 或 UpdateManagement 解決方案相關資料。 因應措施是執行
sudo /opt/omi/bin/service_control restart
手動啟動 OMI 伺服器。OMI 套件手動升級為較新版本後,必須手動重新啟動,Log Analytics 代理程式才能繼續運作。 在 OMI 伺服器未於升級後自動啟動的某些散發套件中,此為必要步驟。 執行
sudo /opt/omi/bin/service_control restart
以重新啟動 OMI。有時候可能會凍結 OMI。 OMS 代理程式可能會進入等候 OMI 的封鎖狀態,同時封鎖所有資料收集。 OMS 代理程式程式會持續執行,但卻沒有任何活動,證據是
omsagent.log
中沒有新的記錄行 (例如傳送的活動訊號)。 使用sudo /opt/omi/bin/service_control restart
重新啟動 OMI,以復原代理程式。如果您在 omsconfig.log 中看到 DSC 資源的「找不到類別」錯誤,請執行
sudo /opt/omi/bin/service_control restart
。有時候,當 Log Analytics Linux 代理程式無法與 Azure 監視器通訊時,代理程式上的資料會備份為整個緩衝區大小:50 MB。 應該執行下列命令重新啟動代理程式:
/opt/microsoft/omsagent/bin/service_control restart
。注意
此問題已在代理程式 1.1.0-28 版和更新版本中修正。
如果
omsconfig.log
記錄檔未指出PerformRequiredConfigurationChecks
作業會在系統上定期執行,則表示 cron 工作/服務可能有問題。 請確定 cron 工作存在於/etc/cron.d/OMSConsistencyInvoker
底下。 如有需要,請執行下列命令以建立 cron 工作:mkdir -p /etc/cron.d/ echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker
此外,請確定 cron 服務正在執行。 您可以對 Debian、Ubuntu 和 SUSE 使用
service cron status
,或對 RHEL、CentOS 和 Oracle Linux 使用service crond status
,來檢查此服務的狀態。 如果服務不存在,您可以使用下列指示來安裝二進位檔並啟動服務:Ubuntu/Debian
# To Install the service binaries sudo apt-get install -y cron # To start the service sudo service cron start
SUSE
# To Install the service binaries sudo zypper in cron -y # To start the service sudo systemctl enable cron sudo systemctl start cron
RHEL/CentOS
# To Install the service binaries sudo yum install -y crond # To start the service sudo service crond start
Oracle Linux
# To Install the service binaries sudo yum install -y cronie # To start the service sudo service crond start
問題:當您在入口網站中設定 Syslog 或 Linux 效能計數器的收集功能時,系統不會套用設定
可能的原因
- Log Analytics Linux 代理程式未挑選最新的設定。
- 未套用入口網站中經過變更的設定。
解決方法
背景:omsconfig
是 Log Analytics Linux 代理程式設定代理程式,會每隔五分鐘尋找一次新的入口網站端設定。 此組態接著會套用到位於 /etc/opt/microsoft/omsagent/conf/omsagent.conf 的 Log Analytics Linux 代理程式組態檔。
在某些情況下,Log Analytics Linux 代理程式設定代理程式可能無法與入口網站設定服務進行通訊。 此狀況會導致未套用最新的設定。
執行
dpkg --list omsconfig
或rpm -qi omsconfig
來確認omsconfig
代理程式已安裝。 若未安裝,請重新安裝最新版的 Log Analytics Linux 代理程式。執行
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'
命令來確認omsconfig
代理程式可與 Azure 監視器通訊。 此命令會傳回代理程式從服務接收的設定,包括 Syslog 設定、Linux 效能計數器以及自訂記錄。 如果此命令失敗,請執行下列命令:sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'
。 此命令會強制 omsconfig 代理程式與 Azure 監視器進行通訊,以擷取最新的設定。
問題︰您沒有看到任何自訂記錄資料
可能的原因
- 上線至 Azure 監視器失敗。
- 尚未選取 [將下列設定套用至我的 Linux 伺服器] 設定。
omsconfig
尚未從服務中挑選最新的自訂記錄設定。- Log Analytics Linux 代理程式的使用者
omsagent
無法存取自訂記錄,因為沒有權限或找不到記錄。 您可能會看到下列錯誤:[DATETIME] [warn]: file not found. Continuing without tailing it.
[DATETIME] [error]: file not accessible by omsagent.
- Log Analytics Linux 代理程式 1.1.0-217 版中已修正已知的競爭條件問題。
解決方法
驗證下列檔案是否存在,以確認 Azure 監視器是否成功上線:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf
。 如果不成功,則:- 使用 omsadmin.sh 命令列指示重新上線。
- 在 Azure 入口網站的 [進階設定] 之下,確定已啟用 [將下列組態套用至我的 Linux 伺服器] 設定。
執行
sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'
命令來確認omsconfig
代理程式可與 Azure 監視器通訊。 此命令會傳回代理程式從服務接收的設定,包括 Syslog 設定、Linux 效能計數器以及自訂記錄。 如果此命令失敗,請執行下列命令:sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'
。 此命令會強制omsconfig
代理程式與 Azure 監視器進行通訊,以擷取最新的設定。
背景:Log Analytics Linux 代理程式使用者不會以特殊權限使用者 root
身分執行,而會以 omsagent
使用者身分執行。 在大部分情況下,必須將明確的權限授與這位使用者,以讀取特定檔案。 若要授與權限給 omsagent
使用者,請執行下列命令︰
- 將
omsagent
使用者新增至特定群組:sudo usermod -a -G <GROUPNAME> <USERNAME>
。 - 授與必要檔案的通用讀取權限:
sudo chmod -R ugo+rx <FILE DIRECTORY>
。
1.1.0-217 版之前的 Log Analytics Linux 代理程式已知有競爭條件問題。 更新為最新的代理程式後,請執行下列命令,以取得最新版的輸出外掛程式:sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
。
問題:您要嘗試重新上線至新的工作區
嘗試將代理程式重新上線至新的工作區時,您必須先清除 Log Analytics 代理程式設定,才能重新上線。 若要從代理程式清除舊設定,請使用 --purge
執行殼層組合:
sudo sh ./omsagent-*.universal.x64.sh --purge
Or
sudo sh ./onboard_agent.sh --purge
使用 --purge
選項之後,您可以繼續重新上線。
問題:Azure 入口網站中的 Log Analytics 代理程式延伸模組標示了失敗狀態:佈建失敗
可能的原因
- Log Analytics 代理程式已從作業系統中移除。
- Log Analytics 代理程式服務已關閉、停用或未設定。
解決方法
- 從 Azure 入口網站中移除此延伸模組。
- 遵循指示以安裝代理程式。
- 執行下列命令來重新啟動代理程式:
sudo /opt/microsoft/omsagent/bin/service_control restart
. - 等候幾分鐘,直到佈建狀態變為佈建成功。
問題:Log Analytics 代理程式隨選升級
可能的原因
主機上的 Log Analytics 代理程式套件已過時。
解決方法
請至此 GitHub 頁面查看最新版。
下載安裝指令碼 (1.4.2-124 是範例版本):
wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh
執行
sudo sh ./omsagent-*.universal.x64.sh --upgrade
來升級套件。
問題:安裝失敗並指出 Python2 不支援 ctypes,即使正在使用 Python3 也一樣
可能的原因
就此已知問題而言,如果 VM 的語言不是英文,在驗證所用的 Python 版本為何時,檢查將會失敗。 此問題會導致代理程式一律假設使用的是 Python2,因此如果沒有 Python2,就會失敗。
解決方法
將 VM 的環境語言變更為英文:
export LANG=en_US.UTF-8