Simple Log Service：如何排查容器日誌採集異常

ACK 叢集複用已有安全性群組導致 LoongCollector/Logtail 無心跳

ACK 叢集複用已有安全性群組時，如果 ECS 安全性群組未允許存取 Pod 網段的入站流量，LoongCollector/Logtail 可能無法訪問 coredns 解析 SLS endpoint 地址，從而無法上報機器組心跳。

解決步驟：

1. 在ECS 控制台中找到 ACK 叢集節點使用的安全性群組，新增一條入方向規則，允許存取 Pod 網段的所有協議和連接埠流量。例如，Pod 網段為 10.229.0.0/16 時，將該網段配置為規則來源。

2. 規則生效後，重啟 kube-system 命名空間中的 loongcollector-ds DaemonSet：

   kubectl rollout restart daemonset/loongcollector-ds -n kube-system

3. 等待 LoongCollector/Logtail Pod 恢複運行後，在Log Service控制台的機器組中確認心跳是否恢複。

Docker/LoongCollector 部署後無心跳（AliUID 配置缺失）

在 Docker 模式下部署 LoongCollector/Logtail 後，如果機器組心跳狀態持續異常（無法註冊），通常是由於使用者標識（AliUID）配置缺失。LoongCollector/Logtail 容器需要讀取阿里雲帳號 ID 資訊才能向 SLS 註冊機器組，未掛載該檔案時註冊無法完成。

解決步驟：

1. 在宿主機上建立使用者標識目錄：

   mkdir -p /etc/ilogtail/users/

2. 在該目錄下建立以阿里雲帳號 ID 命名的空檔案（檔案名稱即阿里雲帳號 ID）：

   touch /etc/ilogtail/users/{阿里雲帳號ID}

3. 啟動 LoongCollector/Logtail 容器時，將該目錄以唯讀方式掛載到容器內（在 docker run 命令中添加如下參數）：

   -v /etc/ilogtail/users:/etc/ilogtail/users:ro

4. 重啟 LoongCollector/Logtail 容器。

驗證：操作完成後，在 SLS 控制台進入對應機器組，查看心跳狀態是否變為 OK。

Docker Swarm 叢集多台伺服器上報相同 IP 導致機器組識別異常

在 Docker Swarm 叢集中，如果機器組中僅顯示一台機器而非實際數量，通常是因為多台伺服器的 Logtail 容器使用了相同的內部 IP，且配置了相同的 ALIYUN_LOGTAIL_USER_DEFINED_ID，導致 SLS 無法區分不同的伺服器。

解決方案一：為每台伺服器的 Logtail 容器設定唯一的 ALIYUN_LOGTAIL_USER_DEFINED_ID 環境變數，確保各伺服器標識不重複，並與機器組配置中的自訂標識匹配：

-e ALIYUN_LOGTAIL_USER_DEFINED_ID={唯一標識，如 swarm-node-1}

解決方案二：設定 ALIYUN_LOGTAIL_WORKING_IP 環境變數，手動為每台伺服器的 Logtail 容器指定唯一的工作 IP（例如宿主機公網 IP 或內網唯一 IP）：

-e ALIYUN_LOGTAIL_WORKING_IP={宿主機唯一IP地址}

Istio Sidecar（邊車）日誌未採集

採集不到 Istio Sidecar（邊車）日誌時，常見原因是採集配置匹配的容器記錄檔已不存在，或者 ContainerFilters 未精確匹配到 Sidecar 容器。按以下順序排查：

1. 檢查運行 Istio Sidecar 的 Pod 的 Deployment 或 StatefulSet 配置，確認用於採集的環境變數已正確配置。例如，配置中應包含以下環境變數：

   aliyun_logs_reconfig-zltx-test-stdout: "stdout"

2. 確認 Logtail 或 LoongCollector 組件已正確安裝且處於運行狀態，並確認相關 ConfigMap 配置與當前採集需求一致。

3. 檢查採集配置中的 ContainerFilters，僅精確匹配目標 Istio Sidecar 容器。配置變更後，確認匹配的容器記錄檔仍然存在，再檢查日誌是否恢複採集。

SLS 容器元資訊預覽找不到 Pod 或採集不到 emptyDir 日誌

在 SLS 控制台的容器元資訊預覽中找不到目標 Pod，或應用寫入 emptyDir 的日誌始終無法被採集，通常是由於 Logtail（DaemonSet 模式）無法訪問容器內部的 emptyDir 臨時儲存。

原因：Logtail 以 DaemonSet 方式運行在宿主機上，emptyDir 是 K8s 的臨時儲存卷，僅存在於 Pod 內部，宿主機無法直接存取，因此 Logtail 無法讀取其中的記錄檔，也無法提取容器中繼資料。

解決方案一（推薦）：修改應用，將日誌輸出到標準輸出（stdout/stderr）。在 SLS 控制台將採集路徑配置為 K8s 標準日誌路徑：

/logtail_host/var/log/pods/<namespace>_<pod-name>-<uid>/<container-name>/*.log

解決方案二：若必須使用檔案日誌，將應用的日誌目錄掛載方式從 emptyDir 改為 hostPath 或 PVC，確保日誌持久化在宿主機可訪問路徑，然後將 SLS 採集路徑調整為宿主機實際掛載路徑，例如：

/logtail_host/var/log/your-app/*.log

Logtail 採集容器日誌提示建立檔案失敗或許可權錯誤

現象：Logtail 報錯，提示需要在容器內建立特定的空檔案，或出現許可權拒絕（Permission denied）錯誤，導致無法正常採集日誌。

解決步驟：

1. 根據報錯提示，在容器內手動建立指定的空檔案：

   touch <報錯中指定的檔案路徑>

2. 設定該檔案的許可權為 -rw-r--r--（644）：

   chmod 644 <報錯中指定的檔案路徑>

3. 重啟容器。

替代方案：如果以上步驟後仍無法採集，建議將容器日誌目錄掛載到宿主機，通過宿主機路徑進行採集，此方案更為穩定。

採集 K8s 標準輸出日誌報錯 parse cri docker line error

現象：日誌中出現 parse cri docker line error: invalid CRI log, timestamp not found 報錯，導致 K8s 標準輸出（stdout）日誌無法正常採集。

原因：日誌行解析失敗，常見原因是多行日誌配置中行首Regex配置不正確，Logtail 無法識別 CRI 日誌行格式。

解決步驟：

1. 檢查 Logtail 配置中的行首Regex，確認能正確匹配日誌格式；如有必要，嘗試關閉多行模式：

   • YAML 配置方式：在設定檔中注釋或刪除 multiline 相關配置段，然後重新 apply 配置。

   • 控制台方式：在 SLS 控制台的 Logtail 配置頁面，關閉多行日誌採集選項。

2. 確認 K8s Namespace Regex 格式正確。若需匹配多個命名空間，各命名空間之間需使用豎線（|）分隔，例如：namespace1|namespace2。

3. 修改 YAML 配置後，執行以下命令重新應用配置使其生效：

   kubectl apply -f <設定檔.yaml>

Logtail 配置 JSON 解析外掛程式時出現紅色歎號無法儲存怎麼辦？

現象：在 Logtail 配置中添加 JSON 解析外掛程式後，外掛程式表徵圖旁出現紅色歎號警告，配置無法儲存。

原因：紅色歎號通常表示外掛程式內部尚未完成配置，或配置在編輯過程中發生變化但未應用。

解決步驟：

1. 在 Logtail 配置編輯頁面，刪除系統預設添加的 JSON 解析外掛程式。

2. 重新手動添加 JSON 解析外掛程式，並在外掛程式內完成所有必要欄位的配置（如日誌範例、解析規則）。

3. 配置完成後紅色歎號會消失，此時即可正常儲存 Logtail 配置。

說明：在 JSON 解析外掛程式之後繼續添加時間解析外掛程式是標準用法，可用於從日誌本文中提取時間欄位作為日誌時間。

多個 Logtail 配置匹配同一檔案導致採集不到資料（MULTI CONFIG MATCH ALARM）怎麼辦？

現象：Logtail 作業記錄中出現 MULTI CONFIG MATCH ALARM 警示，無法採集到目標檔案的資料。

原因：預設情況下，一個記錄檔只能匹配一個 Logtail 配置。當多個 Logtail 配置的檔案路徑同時匹配到同一檔案時，僅其中一個配置會生效，其餘配置無法採集到資料，並觸發 MULTI CONFIG MATCH ALARM 警示。

解決步驟：

1. 刪除多餘的 Logtail 配置：在Log Service控制台檢查綁定到對應機器組的所有 Logtail 配置，重複資料刪除或不再使用的配置，使每個檔案僅被一個配置匹配。

2. 按 pod-name 拆分匹配路徑：如果確需對同一檔案使用多個配置（例如按 pod-name 拆分採集），請參考官方文檔修改相關配置，使每個 Logtail 配置通過更精確的路徑或 Label 過濾只匹配自己的目標檔案，避免路徑重疊。

3. 修改完成後，觀察 Logtail 作業記錄，確認 MULTI CONFIG MATCH ALARM 警示消失且資料正常採集。

Logtail 採集容器日誌報錯 no such file or directory 如何處理？

現象：Logtail 作業記錄中出現 no such file or directory 報錯，目標容器日誌無法採集。

原因：目標採集路徑在節點上不存在，通常與 Kubernetes Pod 生命週期或日誌輪轉機制有關。

解決步驟：

1. 確認 Pod 是否仍存在：若 Pod 已被刪除，對應的日誌路徑隨之消失，屬於正常現象，可忽略該報錯。若 Pod 仍在運行，請登入對應節點檢查實際日誌路徑是否存在。

2. 優先使用容器標準輸出採集：在ACK 控制台建立採集配置時，建議選擇容器標準輸出類型，並通過容器 Label 或容器名稱匹配目標容器，避免直接依賴容器內部檔案路徑。

3. 必須採集檔案時的配置建議：使用萬用字元路徑（例如 /logtail_host/var/log/pods/*/*.log），並開啟 Logtail 配置中的自動探索新檔案選項，使 Logtail 能在日誌輪轉或 Pod 重建後自動跟蹤新路徑。

4. 驗證 Logtail 配置是否應用到對應機器組：確認該 Logtail 配置已綁定到包含目標 Pod 的機器組。

5. 查看 Logtail 自身作業記錄：若大量報錯集中於已銷毀的 Pod，可忽略；若持續報錯且 Pod 仍在運行，則需要修正採集路徑或檢查節點掛載。

Logtail 因 logfiletoobig 跳過檔案導致採集中斷如何解決？

現象：Logtail 作業記錄中出現 logfiletoobig 警示，目標檔案被跳過，日誌採集中斷。

原因：目標記錄檔大小超過 Logtail 預設限制，Logtail 主動跳過該檔案以保護穩定性。

解決步驟：

1. 調整 Logtail 採集配置：在 Logtail 配置或機器組全域參數中做如下調整：

   • 提高 MaxLogFileSize（例如設為 1GB），避免大檔案被跳過。

   • 增大 MaxLogFileInodeCacheSize（例如設為 2000），提升對輪轉檔案的跟蹤能力。

   • 確保 EnableContainerDiscovery 設定為 true，使 Logtail 能自動探索容器日誌路徑。

2. 觸發重新掃描：在 ACK 叢集中執行以下命令，刪除 loongcollector-ds（或 logtail-ds）Pod，由 DaemonSet 自動重建並重新掃描所有容器日誌路徑：

   kubectl delete pod -n kube-system -l k8s-app=loongcollector-ds

3. 驗證與替代方案：觀察Log Service控制台的日誌接收情況，並檢查 Logtail Pod 內是否仍有殘留錯誤。若上述方法無效，建議嘗試接入K8s-標準輸出-新版配置並開啟容器元資訊預覽，使用標準輸出路徑代替檔案路徑採集。

ACK 情境補充排查

在 ACK 叢集情境下，如果完成上述檢查後日誌採集仍然沒有資料，請繼續排查以下兩項。

1. 檢查 ACK CRD 採集配置：執行以下命令，查看 ACK 叢集的 CRD 採集配置：

   kubectl get ClusterAliyunPipelineConfig -A

   確認輸出中的 LogStore 和採集規則與預期一致。

2. 檢查容器鏡像 Volume 聲明：執行以下命令，對容器鏡像執行 docker inspect，檢查 Config.Volumes 欄位：

   docker inspect <鏡像名稱> | grep -A5 Volumes

   若 Config.Volumes 不為空白，表示鏡像聲明了 VOLUME，可能覆蓋記錄檔路徑。需去除鏡像中的 VOLUME 聲明，或將 Volume 掛載到 emptyDir。

登入Logtail容器

• 普通Docker

  1. 在宿主機上執行如下命令，查詢Logtail容器。

     docker ps | grep logtail

     系統將返回如下類似結果。

     223****6e        registry.cn-hangzhou.aliyuncs.com/log-service/logtail                             "/usr/local/ilogta..."   8 days ago          Up 8 days                               logtail-iba

  2. 執行如下命令，在Logtail容器內啟動bash shell。

     docker exec -it 223****6e  bash

     其中，223****6e為容器ID，請根據實際值替換。

• Kubernetes

  1. 執行如下命令，查詢Logtail的Pod。

     kubectl get po -n kube-system | grep logtail

     系統將返回如下類似結果。

     logtail-ds-****d                                             1/1       Running    0          8d
     logtail-ds-****8                                             1/1       Running    0          8d

  2. 執行如下命令，登入Pod。

     kubectl exec -it -n kube-system logtail-ds-****d -- bash

     其中，logtail-ds-****d為Pod ID，請根據實際值替換。

查看Logtail的作業記錄

Logtail日誌儲存在Logtail容器中的/usr/local/ilogtail/目錄中，檔案名稱為ilogtail.LOG和logtail_plugin.LOG。

1. 登入Logtail容器。具體操作，登入Logtail容器。

2. 開啟/usr/local/ilogtail/目錄。

   cd /usr/local/ilogtail

3. 查看ilogtail.LOG和logtail_plugin.LOG檔案。

   cat ilogtail.LOG
   cat logtail_plugin.LOG

查看Logtail的版本號碼、IP地址、啟動時間

1. 在宿主機執行如下命令，查看Logtail的版本號碼、IP地址、啟動時間。

   相關資訊儲存在Logtail容器的/usr/local/ilogtail/app_info.json檔案中。

   kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json

   系統將返回如下類似結果。

   {
      "UUID" : "",
      "hostname" : "logtail-****k",
      "instance_id" : "0EB****_172.20.4.2_1517810940",
      "ip" : "172.20.4.2",
      "logtail_version" : "0.16.2",
      "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64",
      "update_time" : "2018-02-05 06:09:01"
   }

ACK 叢集中 Pod 日誌採集異常的排查資訊擷取

在 ACK 叢集中遇到 Pod 日誌採集異常時，可以通過以下方法擷取排查所需的基礎資訊，並在尋求支援人員時一併提供，以加快問題定位。

擷取 Logtail/LoongCollector 的 IP 位址：

1. 執行以下命令，尋找目標節點上的 LoongCollector/Logtail Pod 名稱：

   kubectl get pods -n kube-system | grep loongcollector

2. 執行以下命令，擷取 IP 位址及其他基礎資訊（<pod-name> 替換為上一步擷取的實際 Pod 名稱）：

   kubectl exec <pod-name> -n kube-system cat /usr/local/ilogtail/app_info.json

向支援人員提供有效排查資訊：尋求協助時，請提供以下資訊：

• Project 名稱

• Logtail 採集配置名稱

• 目標 Pod 名稱

• 容器名稱（Container Name）

執行 docker pull 拉取 LoongCollector/Logtail 鏡像是否會影響本機其他服務？

結論：僅執行 docker pull 命令拉取 LoongCollector 或 Logtail 鏡像，不會對本機上正在啟動並執行其他服務產生任何影響。docker pull 只是將鏡像層下載到本地鏡像倉庫，不會啟動容器，也不會佔用 CPU 或額外記憶體。

注意事項：

• 後續執行 docker run 啟動容器時，請確保宿主機有充足的 CPU 與記憶體資源，避免新容器與現有業務爭搶資源。

• 檢查容器連接埠映射是否與宿主機上已有服務的連接埠衝突，避免影響現有業務。

• 如需長期在 Kubernetes 環境中作業記錄採集組件，建議通過ACK 控制台的組件管理安裝 LoongCollector（DaemonSet 模式），由叢集統一調度資源。

Log Service控制台 ACK 叢集日誌接入頁面缺少 K8s-標準輸出-新版 選項怎麼辦？

現象：在Log Service控制台的 ACK 叢集日誌接入頁面中，找不到K8s-標準輸出-新版入口。

原因：該入口可能由於後端功能臨時下線修複而暫時不可用。

替代方案：

1. 臨時使用舊版接入方式：在控制台選擇舊版K8s-標準輸出入口完成接入。注意舊版已停止維護，僅建議作為臨時過渡方案。

2. 使用 CRD 替代控制台入口（推薦）：直接在叢集內使用 kubectl 建立 AliyunPipelineConfig CRD 來配置新版標準輸出採集，無需依賴控制台入口。請參考本文檔容器標準輸出-新版章節中的 YAML 樣本，將其中參數替換為您的實際 Project、LogStore 與叢集資訊後執行：

   kubectl apply -f aliyun-pipeline-config.yaml

   該方式與通過控制台建立的配置等價，且便於以 GitOps 方式管理採集配置。

Pod 未處於 Running 狀態是否影響 LoongCollector/Logtail 的檔案日誌採集？

結論：會影響。LoongCollector/Logtail 採集的是容器內的檔案；當服務未啟動成功且 Pod 未處於 Running 狀態時，容器內可能尚未組建記錄檔檔案，或者目標日誌路徑不存在，因此無法讀取和採集檔案日誌。

驗證方法：臨時將服務啟動命令設定為類似以下命令，使容器保持運行狀態：

sleep 3600

確認 Pod 進入 Running 狀態後，向實際採集路徑中的目標記錄檔手動寫入測試日誌，再檢查日誌是否已採集到對應 LogStore。完成驗證後，恢複服務原有啟動命令。

為什麼無法根據方法名稱等特定欄位搜尋容器標準輸出日誌？

Log Service（SLS）只能檢索日誌內容中實際存在且已建立索引的欄位。如果容器標準輸出或應用日誌本身未列印方法名稱、調用者資訊等欄位，就無法直接按這些欄位搜尋。

按以下方式處理：

1. 檢查應用代碼或網關（例如 Nginx、Spring Cloud Gateway）的日誌配置，確保方法名稱、調用者資訊等關鍵業務欄位已輸出到容器標準輸出或記錄檔中，並為需要查詢的欄位建立索引。

2. 如果需要補充 Pod 名稱、Namespace、標籤等上下文資訊，在採集配置的輸入配置地區開啟日誌標籤富化。該功能可將環境變數或 Kubernetes Pod 標籤作為中繼資料 Tag 附加到日誌中，供後續查詢和分析。

日誌內容欄位由應用或網關輸出，用於記錄方法名稱、調用者等商務資訊；中繼資料 Tag 是採集階段附加的上下文資訊。中繼資料 Tag 不能補出應用日誌中從未列印的方法名稱或調用者資訊。