在 Kubernetes 環境中,當您需要對特定應用的日誌進行精細化管理、實現多租戶隔離或確保日誌採集與應用生命週期嚴格綁定時,Sidecar 模式是理想的日誌採集方案。該模式通過在業務 Pod 中注入一個獨立的 LoongCollector(Logtail) 容器,實現對該 Pod 內日誌的專屬採集,提供了強大的靈活性和隔離性。
工作原理
Sidecar 模式的核心是在您的業務 Pod 內,並排運行一個業務容器和一個 LoongCollector(Logtail) 日誌採集容器。它們通過共用卷和生命週期同步機制協同工作。
日誌共用:業務容器將其產生的記錄檔寫入到一個共用卷(通常是
emptyDir)。 LoongCollector(Logtail) 容器掛載同個共用卷,從而能即時讀取並採集這些記錄檔。配置關聯:每個 LoongCollector(Logtail)Sidecar 容器通過設定一個唯一的
使用者自訂標識來聲明自己的身份。在Log Service控制台,您需要建立一個同樣使用此標識的機器組。這樣,所有使用相同標識的 Sidecar 執行個體都會自動應用到這個機器組上的採集配置。生命週期同步:為確保在 Pod 終止時不丟失日誌,業務容器和 LoongCollector(Logtail)容器通過共用卷中的信令檔案(
cornerstone和tombstone)進行通訊,配合 Pod 的優雅終止寬限期(terminationGracePeriodSeconds),實現業務容器先停止寫入、 LoongCollector(Logtail) 完成日誌發送後再一同退出的優雅停機流程。
準備工作
在採集日誌前,需規劃並建立用於管理與儲存日誌的Project和Logstore。若已有可用資源,可跳過此步驟,直接進入步驟一:注入LoongCollector Sidecar容器。
Project:Log Service的資源嵌入式管理單元,用於隔離和管理不同專案或業務的日誌。
Logstore:日誌儲存單元,用於儲存日誌。
建立Project
建立Logstore
步驟一:注入LoongCollector Sidecar容器
在業務應用Pod中注入LoongCollector Sidecar容器,並配置共用卷以實現日誌採集。若尚未部署業務應用,或僅用於測試,可直接使用附錄:YAML樣本快速驗證流程。
1. 修改業務Pod YAML配置
定義共用卷
在
spec.template.spec.volumes中添加三個共用卷(與containers同級):volumes: # 共用日誌目錄(業務容器寫入,Sidecar 讀取) - name: ${shared_volume_name} # <-- 名稱需與volumeMounts中的name一致 emptyDir: {} # 容器間通訊信令目錄(用於優雅啟停) - name: tasksite emptyDir: medium: Memory # 使用記憶體作為介質,效能更高 sizeLimit: "50Mi" # 共用主機時區配置:同步Pod內所有容器的時區 - name: tz-config # <-- 名稱需與volumeMounts中的name一致 hostPath: path: /usr/share/zoneinfo/Asia/Shanghai # 請按需修改時區配置業務容器掛載
在業務容器(如
your-business-app-container)的volumeMounts中添加以下掛載項:確保業務容器將日誌寫入
${shared_volume_path}目錄,LoongCollector 才能正確採集。volumeMounts: # 掛載共用記錄磁碟區到業務日誌輸出目錄 - name: ${shared_volume_name} mountPath: ${shared_volume_path} # 例如:/var/log/app # 掛載通訊目錄 - name: tasksite mountPath: /tasksite # 與 Loongcollector容器通訊的共用目錄 # 掛載時區檔案 - name: tz-config mountPath: /etc/localtime readOnly: true注入LoongCollector Sidecar容器
在
spec.template.spec.containers數組中追加以下 Sidecar 容器定義:- name: loongcollector image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun command: ["/bin/bash", "-c"] args: - | echo "[$(date)] LoongCollector: Starting initialization" # 啟動LoongCollector服務 /etc/init.d/loongcollectord start # 等待配置下載和服務就緒 sleep 15 # 驗證服務狀態 if /etc/init.d/loongcollectord status; then echo "[$(date)] LoongCollector: Service started successfully" touch /tasksite/cornerstone else echo "[$(date)] LoongCollector: Failed to start service" exit 1 fi # 等待業務容器完成(通過 tombstone 檔案訊號) echo "[$(date)] LoongCollector: Waiting for business container to complete" until [[ -f /tasksite/tombstone ]]; do sleep 2 done # 留出時間上傳剩餘日誌 echo "[$(date)] LoongCollector: Business completed, waiting for log transmission" sleep 30 # 停止服務 echo "[$(date)] LoongCollector: Stopping service" /etc/init.d/loongcollectord stop echo "[$(date)] LoongCollector: Shutdown complete" # 健全狀態檢查 livenessProbe: exec: command: ["/etc/init.d/loongcollectord", "status"] initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 failureThreshold: 3 # 資源配置 resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "2000m" memory: "2048Mi" # 環境變數配置 env: - name: ALIYUN_LOGTAIL_USER_ID value: "${your_aliyun_user_id}" - name: ALIYUN_LOGTAIL_USER_DEFINED_ID value: "${your_machine_group_user_defined_id}" - name: ALIYUN_LOGTAIL_CONFIG value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json" # 啟用全量排空,確保 Pod 終止前發送所有日誌 - name: enable_full_drain_mode value: "true" # 追加 Pod 環境資訊作為日誌標籤 - name: ALIYUN_LOG_ENV_TAGS value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_" # 自動注入 Pod 和 Node 中繼資料作為日誌標籤 - name: "_pod_name_" valueFrom: fieldRef: fieldPath: metadata.name - name: "_pod_ip_" valueFrom: fieldRef: fieldPath: status.podIP - name: "_namespace_" valueFrom: fieldRef: fieldPath: metadata.namespace - name: "_node_name_" valueFrom: fieldRef: fieldPath: spec.nodeName - name: "_node_ip_" valueFrom: fieldRef: fieldPath: status.hostIP # 卷掛載(與業務容器共用) volumeMounts: # 唯讀掛載業務日誌目錄 - name: ${shared_volume_name} # <-- 共用日誌目錄名 mountPath: ${dir_containing_your_files} # <-- 共用目錄在sidercar中的路徑 readOnly: true # 掛載通訊目錄 - name: tasksite mountPath: /tasksite # 掛載時區 - name: tz-config mountPath: /etc/localtime readOnly: true
2. 改造業務容器生命週期邏輯
根據工作負載類型,需改造業務容器以支援與Sidecar協同退出:
短生命週期任務(Job/CronJob)
# 1. 等待 LoongCollector 準備就緒
echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] Business: LoongCollector is ready, starting business logic"
# 2. 執行核心商務邏輯(確保日誌寫入共用目錄)
echo "Hello, World!" >> /app/logs/business.log
# 3. 儲存退出碼
retcode=$?
echo "[$(date)] Business: Task completed with exit code: $retcode"
# 4. 通知LoongCollector業務完成
touch /tasksite/tombstone
echo "[$(date)] Business: Tombstone created, exiting"
exit $retcode長生命週期服務(Deployment / StatefulSet)
# 定義訊號處理函數
_term_handler() {
echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
# 發送QUIT訊號給Nginx進行優雅停止
if [ -n "$NGINX_PID" ]; then
kill -QUIT "$NGINX_PID" 2>/dev/null || true
echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
# 等待Nginx優雅停止
wait "$NGINX_PID"
EXIT_CODE=$?
echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
fi
# 通知LoongCollector業務容器已停止
echo "[$(date)] [nginx-demo] Writing tombstone file"
touch /tasksite/tombstone
exit $EXIT_CODE
}
# 註冊訊號處理
trap _term_handler SIGTERM SIGINT SIGQUIT
# 等待LoongCollector準備就緒
echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"
# 啟動Nginx
echo "[$(date)] [nginx-demo] Starting Nginx..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
# 等待Nginx進程
wait $NGINX_PID
EXIT_CODE=$?
# 非訊號導致的退出也要通知LoongCollector
if [ ! -f /tasksite/tombstone ]; then
echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
touch /tasksite/tombstone
fi
exit $EXIT_CODE3. 設定優雅終止時間
在 spec.template.spec 中設定足夠的終止寬限期,以確保 LoongCollector 有足夠時間上傳剩餘日誌。
spec:
# ... 您現有的其他 spec 配置 ...
template:
spec:
terminationGracePeriodSeconds: 600 # 10分鐘優雅停止時間4. 變數說明
變數 | 說明 |
| 設定為您的阿里雲帳號(主帳號)ID。更多資訊,請參見配置使用者標識。 |
| 自訂設定機器組的自訂標識,用於建立自訂機器組。例如 重要 請確保該標識在您的Project所在地區內唯一。 |
| 請根據Log ServiceProject所在地區和訪問的網路類型填寫。其中,地區資訊請參見開服地區。 樣本:若Project位於華東1(杭州),則以阿里雲內網訪問時為 |
| 自訂設定卷的名稱。 重要
|
| 設定掛載路徑,即容器待採集文本日誌所在目錄。 |
5. 應用配置並驗證
執行以下命令部署變更:
kubectl apply -f <YOUR-YAML>查看 Pod 狀態,確認 LoongCollector 容器已成功注入:
kubectl describe pod <YOUR-POD-NAME>若看到兩個容器(業務容器 +
loongcollector),且狀態正常,則注入成功。
步驟二:建立使用者自訂標識機器組
本步驟將Pod中注入的 LoongCollector Sidecar執行個體註冊到Log Service,實現採集配置的統一管理和下發。
操作流程
建立機器組
進入目標Project,在左側導覽列單擊
。在機器組頁面,單擊。
配置機器組資訊
填寫以下參數後,單擊確定:
名稱:機器組名稱,建立後不可修改。命名規則如下:
只能包括小寫字母、數字、短劃線(-)和底線(_)。
必須以小寫字母或者數字開頭和結尾。
長度必須在 2~128 字元之間。
機器組標識:選擇使用者自訂標識。
使用者自訂標識:填入您在步驟一YAML檔案中為 LoongCollector 容器設定的環境變數
ALIYUN_LOGTAIL_USER_DEFINED_ID的值。必須完全一致,否則無法關聯成功。
檢查機器組心跳狀態
建立完成後,單擊目標機器組名稱,在機器組狀態區域,查看心跳狀態。
OK:表示LoongCollector 已成功串連到Log Service,機器組註冊成功。
FAIL:
可能是配置未生效,配置生效時間大約需要2分鐘,請稍後重新整理頁面重試。
如果2分鐘後仍為FAIL,請參考Logtail機器組問題排查思路進行診斷。
每個 Pod 對應一個獨立的 LoongCollector 執行個體,建議為不同業務或環境使用不同的自訂標識,便於精細化管理。
步驟三:建立採集配置
定義 LoongCollector 應採集哪些記錄檔、如何解析日誌結構、如何過濾內容,並將配置綁定到登入的機器組。
操作流程
在
日誌庫頁面,單擊目標Logstore名稱前的
展開。單擊資料接入後的
,在快速資料接入彈框中,找到Kubernetes-檔案卡片,單擊立即接入。機器組配置,完成後單擊下一步:
使用情境:選擇K8s情境
部署方式:選擇Sidecar
選擇機器組:在源機器組列表中勾選步驟二中建立的使用者自訂標識機器組,單擊
添加至應用機器組列表。
在Logtail配置頁面,按照如下步驟配置Logtail採集規則。
1. 全域與輸入配置
定義採集配置的名稱、日誌來源及採集範圍。
全域配置:
配置名稱:自訂採集配置名稱,在其所屬Project內必須唯一。建立成功後,無法修改。命名規則:
僅支援小寫字母、數字、連字號(-)和底線(_)。
必須以小寫字母或者數字作為開頭和結尾。
輸入配置:
類型:文本日誌採集。
Logtail部署模式:選擇Sidecar
檔案路徑類型:
容器內路徑:採集容器內的記錄檔。
宿主機路徑:採集宿主機本地服務日誌。
檔案路徑:日誌採集的路徑。
Linux:以“/”開頭,如
/data/mylogs/**/*.log,表示/data/mylogs目錄下所有尾碼名為.Log的檔案。Windows:以盤符開頭,如
C:\Program Files\Intel\**\*.Log。
最大目錄監控深度:檔案路徑中萬用字元
**匹配的最大目錄深度。預設為0,表示只監控本層目錄。
2. Tlog與結構化
通過配置Tlog規則,將原始非結構化日誌轉換為結構化、可檢索的資料,提升日誌查詢與分析效率。建議在配置前先添加日誌範例:
在Logtail配置頁面的處理配置地區,單擊添加日誌範例,輸入待採集的日誌內容。系統將基於範例識別日誌格式,輔助產生Regex和解析規則,降低配置難度。
情境一:多行Tlog(如Java堆棧日誌)
由於Java異常堆棧、JSON等日誌通常跨越多行,在預設採集模式下會被拆分為多條不完整的記錄,導致上下文資訊丟失;為此,可啟用多行模式,通過配置行首Regex,將同一日誌的連續多行內容合并為一條完整日誌。
效果樣本:
未經任何處理的原始日誌 | 預設採集模式下,每行作為獨立日誌,堆棧資訊被拆散,丟失上下文 | 開啟多行模式,通過行首Regex識別完整日誌,保留完整語義結構。 |
|
|
|
配置步驟:在Logtail配置頁面的處理配置地區,開啟多行模式:
類型:選擇自訂或多行JSON。
自訂:原始日誌的格式不固定,需配置行首Regex,來標識每條日誌的起始行。
行首Regex:支援自動產生或手動輸入,Regex需要能夠匹配完整的一行資料,如上述樣本中匹配的Regex為
\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*。自動產生:單擊自動產生Regex,然後在日誌範例文字框中,選擇需提取的日誌內容,單擊產生正則。
手動輸入:單擊手動輸入Regex,輸入完成後,單擊驗證。
多行JSON:當原始日誌均為標準JSON格式時,Log Service會自動處理單條JSON日誌內部的換行。
切分失敗處理方式:
丟棄:如果一段文本無法匹配行首規則,則直接丟棄。
保留單行:將無法匹配的文本按原始的單行模式進行切分和保留。
情境二:結構化日誌
當原始日誌為非結構化或半結構化文本(如 Nginx 訪問日誌、應用輸出日誌)時,直接進行查詢和分析往往效率低下。Log Service提供多種資料解析外掛程式,能夠自動將不同格式的原始日誌轉換為結構化資料,為後續的分析、監控和警示提供堅實的資料基礎。
效果樣本:
未經任何處理的原始日誌 | 結構化解析後的日誌 |
| |
配置步驟:在Logtail配置頁面的處理配置地區
添加解析外掛程式:單擊添加處理外掛程式,根據實際格式配置正則解析、分隔字元解析、JSON 解析等外掛程式。此處以採集NGINX日誌為例,選擇。
NGINX日誌配置:將 Nginx 伺服器設定檔(nginx.conf)中的
log_format定義完整地複製並粘貼到此文字框中。樣本:
log_format main '$remote_addr - $remote_user [$time_local] "$request" ''$request_time $request_length ''$status $body_bytes_sent "$http_referer" ''"$http_user_agent"';重要此處的格式定義必須與伺服器上組建記錄檔的格式完全一致,否則將導致日誌解析失敗。
通用配置參數說明:以下參數在多種資料解析外掛程式中都會出現,其功能和用法是統一的。
原始欄位:指定要解析的源欄位名。預設為
content,即採集到的整條日誌內容。解析失敗時保留原始欄位:推薦開啟。當日誌無法被外掛程式成功解析時(例如格式不匹配),此選項能確保原始日誌內容不會丟失,而是被完整保留在指定的原始欄位中。
解析成功時保留原始欄位:選中後,即使日誌解析成功,原始日誌內容也會被保留。
3. 日誌過濾
在日誌採集過程中,大量低價值或無關日誌(如 DEBUG/INFO 層級日誌)的無差別收集,不僅造成儲存資源浪費、增加成本,還影響查詢效率並帶來資料泄露風險。為此,可通過精細化過濾策略實現高效、安全的日誌採集。
通過內容過濾降低成本
基於日誌內容的欄位過濾(如僅採集 level 為 WARNING 或 ERROR 的日誌)。
效果樣本:
未經任何處理的原始日誌 | 只採集 |
| |
配置步驟:在Logtail配置頁面的處理配置地區
單擊添加處理外掛程式,選擇:
欄位名:過濾的日誌欄位。
欄位值:用於過濾的Regex,僅支援全文匹配,不支援關鍵詞部分匹配。
通過黑名單控制採集範圍
通過黑名單機制排除指定目錄或檔案,避免無關或敏感日誌被上傳。
配置步驟:在Logtail配置頁面的地區,啟用採集黑名單,並單擊添加。
支援完整匹配和萬用字元匹配目錄和檔案名稱,萬用字元只支援星號(*)和半形問號(?)。
檔案路徑黑名單:需要忽略的檔案路徑,樣本:
/home/admin/private*.log:在採集時忽略/home/admin/目錄下所有以private開頭,以.log結尾的檔案。/home/admin/private*/*_inner.log:在採集時忽略/home/admin/目錄下以private開頭的目錄內,以_inner.log結尾的檔案。
檔案黑名單:配置採集時需要忽略的檔案名稱,樣本:
app_inner.log:在採集時忽略所有名為app_inner.log的檔案。
目錄黑名單:目錄路徑不能以正斜線(/)結尾,樣本:
/home/admin/dir1/:目錄黑名單不會生效。/home/admin/dir*:在採集時忽略/home/admin/目錄下所有以dir開頭的子目錄下的檔案。/home/admin/*/dir:在採集時忽略/home/admin/目錄下二級目錄名為dir的子目錄下的所有檔案。例如/home/admin/a/dir目錄下的檔案被忽略,/home/admin/a/b/dir目錄下的檔案被採集。
容器過濾
基於容器元資訊(如環境變數、Pod 標籤、命名空間、容器名稱等)設定採集條件,精準控制採集哪些容器的日誌。
配置步驟:在Logtail配置頁面的輸入配置地區,啟用容器過濾,並單擊添加。
多個條件之間為“且”的關係,所有正則匹配均基於 Go 語言的 RE2 正則引擎,功能較 PCRE 等引擎有所限制,請遵循附錄:Regex使用限制(容器過濾)編寫Regex。
環境變數黑/白名單:指定待採集容器的環境變數條件。
K8s Pod標籤黑/白名單:指定待採集容器所在Pod 的標籤條件。
K8s Pod 名稱正則匹配:通過Pod名稱指定待採集的容器
K8s Namespace 正則匹配:通過Namespace名稱指定待採集的容器。
K8s 容器名稱正則匹配:通過容器名稱指定待採集的容器。
容器label黑/白名單:採集容器標籤合格容器,Docker情境使用,K8s情境不推薦使用。
4. 日誌分類
在多應用、多執行個體共用相同日誌格式的情境下,日誌來源難以區分,導致查詢時上下文缺失、分析效率低下。為此,可通過配置日誌主題(Topic)和日誌打標實現自動化的上下文關聯與邏輯分類。
配置日誌主題(Topic)
當多個應用或執行個體的日誌格式相同但路徑不同時(如 /apps/app-A/run.log 和 /apps/app-B/run.log),採集日誌難以區分來源。此時可基於機器組、自訂名稱或檔案路徑提取方式產生 Topic,靈活區分不同業務或路徑來源的日誌。
配置步驟::選擇Topic產生方式,支援如下三種類型:
機器組Topic:採集配置應用於多個機器組時,LoongCollector 會自動使用伺服器所屬的機器組名稱作為
__topic__欄位上傳。適用於按主機劃分日誌情境。自訂:格式為
customized://<自訂佈景主題名>,例如customized://app-login。適用於固定業務標識的靜態主題情境。檔案路徑提取:從記錄檔的完整路徑中提取關鍵資訊,動態標記日誌來源。適用於多使用者/應用共用相同記錄檔名但路徑不同的情況。當多個使用者或服務將日誌寫入不同頂級目錄,但下級路徑和檔案名稱一致時,僅靠檔案名稱無法區分來源,例如:
/data/logs ├── userA │ └── serviceA │ └── service.log ├── userB │ └── serviceA │ └── service.log └── userC └── serviceA └── service.log此時您可以配置檔案路徑提取,並使用Regex從完整路徑中提取關鍵資訊,將匹配結果作為日誌主題(Topic)上傳至Logstore。
檔案路徑擷取規則:基於Regex的擷取的群組
在配置Regex時,系統根據擷取的群組的數量和命名方式自動決定輸出欄位格式,規則如下:
檔案路徑的Regex中,需要對正斜線(/)進行轉義。
擷取的群組類型
適用情境
產生欄位
正則樣本
匹配路徑樣本
產生欄位樣本
單擷取的群組(僅一個
(.*?))僅需一個維度區分來源(如使用者名稱、環境)
產生
__topic__欄位\/logs\/(.*?)\/app\.log/logs/userA/app.log__topic__:userA多擷取的群組-非命名(多個
(.*?))需要多個維度區分來源但無需語義標籤
產生tag欄位
__tag__:__topic_{i}__,其中{i}為擷取的群組的序號\/logs\/(.*?)\/(.*?)\/app\.log/logs/userA/svcA/app.log__tag__:__topic_1__userA;__tag__:__topic_2__svcA多擷取的群組-命名(使用
(?P<name>.*?)需要多個維度區分來源且希望欄位含義清晰、便於查詢與分析
產生tag欄位
__tag__:{name}\/logs\/(?P<user>.*?)\/(?P<service>.*?)\/app\.log/logs/userA/svcA/app.log__tag__:user:userA;__tag__:service:svcA
日誌打標
啟用日誌標籤富化功能,從容器環境變數或 Kubernetes Pod 標籤中提取關鍵資訊並附加為 tag,實現日誌的精細化分組。
配置步驟:在Logtail配置頁面的輸入配置地區,啟用日誌標籤富化,並單擊添加。
環境變數相關:配置環境變數名和tag名,環境變數值將存放在tag名中。
環境變數名:指定需要提取的環境變數名稱。
tag名:環境變數標籤名稱。
Pod標籤相關:配置Pod標籤名和tag名,Pod標籤值將存放在tag名中。
Pod標籤名:需要提取的 Kubernetes Pod 標籤名稱。
tag名:標籤名稱。
步驟四:查詢與分析配置
在完成Tlog與外掛程式配置後,單擊下一步,進入查詢分析配置頁面:
配置完成後,單擊下一步,完成整個採集流程的設定。
步驟五:查看上報日誌
完成採集配置並應用到機器組後,系統將自動下發配置並開始採集增量日誌。
確認記錄檔有新增內容:LoongCollector只採集增量日誌。執行
tail -f /path/to/your/log/file,並觸發業務操作,確保有新的日誌正在寫入。查詢日誌:進入目標 Logstore 的查詢分析頁面,單擊查詢/分析(預設時間範圍為最近15分鐘),觀察是否有新日誌流入。容器文本日誌預設欄位如下:
欄位名稱
說明
__tag__:__hostname__
容器宿主機的名稱。
__tag__:__path__
容器內記錄檔的路徑。
__tag__:_container_ip_
容器的IP地址。
__tag__:_image_name_
容器使用的鏡像名稱。
說明若存在多個相同Hash但名稱或Tag不同的鏡像,採集配置將根據Hash選擇其中一個名稱進行採集,無法確保所選名稱與YAML檔案中定義的一致。
__tag__:_pod_name_
Pod的名稱。
__tag__:_namespace_
Pod所屬的命名空間。
__tag__:_pod_uid_
Pod的唯一識別碼(UID)。
影響日誌採集完整性的關鍵配置說明
確保日誌採集的完整性是LoongCollector Sidecar部署的核心目標。以下配置參數直接影響日誌資料的完整性和可靠性。
LoongCollector 資源配置
在巨量資料量情境下,合理的資源配置是保證端上採集效能的關鍵基礎。關鍵配置參數如下:
# 根據日誌產生速率配置CPU、記憶體資源
resources:
limits:
cpu: "2000m"
memory: "2Gi"
# 影響採集效能的參數
env:
- name: cpu_usage_limit
value: "2"
- name: mem_usage_limit
value: "2048"
- name: max_bytes_per_sec
value: "209715200"
- name: process_thread_count
value: "8"
- name: send_request_concurrency
value: "20"
具體資料量與對應配置關係可以參考Logtail網路類型,啟動參數與設定檔。
服務端 Quota 配置
服務端quota限制或網路異常會導致端上資料發送受阻,從而反壓到檔案採集側,影響日誌完整性。推薦使用CloudLens for SLS監控Project資源配額。
首次採集配置最佳化
Pod啟動時的首次檔案採集策略直接影響資料完整性,特別是在高速資料寫入情境。
通過配置首次採集大小,可以確認首次採集的新檔案的內容位置。首次採集大小預設為 1024 KB。
首次採集時,如果檔案小於 1024 KB,則從檔案內容起始位置開始採集。
首次採集時,如果檔案大於 1024 KB,則從距離檔案末尾1024 KB 的位置開始採集。
首次採集大小,取值範圍為 0~10485760,單位為 KB。
enable_full_drain_mode
這是確保資料完整性的關鍵參數,保證LoongCollector在收到SIGTERM訊號時完成所有資料擷取和發送。
# 影響採集完整性的參數
env:
- name: enable_full_drain_mode
value: "true" # 啟用全量排空模式
後續操作
附錄:YAML樣本
本樣本展示了一個完整的 Kubernetes Deployment 配置,包含業務容器(Nginx)和 LoongCollector Sidecar 容器,適用於通過 Sidecar 模式採集容器日誌。
使用前請完成以下三項關鍵替換:
將
${your_aliyun_user_id}替換為您的阿里雲主帳號 UID;將
${your_machine_group_user_defined_id}替換為步驟三中建立的機器組自訂標識,必須完全一致。將
${your_region_config}替換為與Log Service Project 所在地區及網路類型匹配的配置名。樣本:Project 位於 華東1(杭州),內網訪問——>
cn-hangzhou;公網訪問——>cn-hangzhou-internet。
短生命週期(Job/CronJob)
apiVersion: batch/v1
kind: Job
metadata:
name: demo-job
spec:
backoffLimit: 3
activeDeadlineSeconds: 3600
completions: 1
parallelism: 1
template:
spec:
restartPolicy: Never
terminationGracePeriodSeconds: 300
containers:
# 業務容器
- name: demo-job
image: debian:bookworm-slim
command: ["/bin/bash", "-c"]
args:
- |
# 等待LoongCollector準備就緒
echo "[$(date)] Business: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] Business: LoongCollector is ready, starting business logic"
# 執行商務邏輯
echo "Hello, World!" >> /app/logs/business.log
# 儲存退出碼
retcode=$?
echo "[$(date)] Business: Task completed with exit code: $retcode"
# 通知LoongCollector業務完成
touch /tasksite/tombstone
echo "[$(date)] Business: Tombstone created, exiting"
exit $retcode
# 資源限制
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500"
memory: "512Mi"
# 卷掛載
volumeMounts:
- name: app-logs
mountPath: /app/logs
- name: tasksite
mountPath: /tasksite
# LoongCollector Sidecar容器
- name: loongcollector
image: aliyun-observability-release-registry.cn-hongkong.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
command: ["/bin/bash", "-c"]
args:
- |
echo "[$(date)] LoongCollector: Starting initialization"
# 啟動LoongCollector服務
/etc/init.d/loongcollectord start
# 等待配置下載和服務就緒
sleep 15
# 驗證服務狀態
if /etc/init.d/loongcollectord status; then
echo "[$(date)] LoongCollector: Service started successfully"
touch /tasksite/cornerstone
else
echo "[$(date)] LoongCollector: Failed to start service"
exit 1
fi
# 等待業務容器完成
echo "[$(date)] LoongCollector: Waiting for business container to complete"
until [[ -f /tasksite/tombstone ]]; do
sleep 2
done
echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
# 給足夠時間傳輸剩餘日誌
sleep 30
echo "[$(date)] LoongCollector: Stopping service"
/etc/init.d/loongcollectord stop
echo "[$(date)] LoongCollector: Shutdown complete"
# 健全狀態檢查
livenessProbe:
exec:
command: ["/etc/init.d/loongcollectord", "status"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# 資源配置
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "500m"
memory: "512Mi"
# 環境變數配置
env:
- name: ALIYUN_LOGTAIL_USER_ID
value: "your-user-id"
- name: ALIYUN_LOGTAIL_USER_DEFINED_ID
value: "your-user-defined-id"
- name: ALIYUN_LOGTAIL_CONFIG
value: "/etc/ilogtail/conf/cn-hongkong/ilogtail_config.json"
- name: ALIYUN_LOG_ENV_TAGS
value: "_pod_name_|_pod_ip_|_namespace_|_node_name_"
# Pod資訊注入
- name: "_pod_name_"
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: "_pod_ip_"
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: "_namespace_"
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: "_node_name_"
valueFrom:
fieldRef:
fieldPath: spec.nodeName
# 卷掛載
volumeMounts:
- name: app-logs
mountPath: /app/logs
readOnly: true
- name: tasksite
mountPath: /tasksite
- name: tz-config
mountPath: /etc/localtime
readOnly: true
# 卷定義
volumes:
- name: app-logs
emptyDir: {}
- name: tasksite
emptyDir:
medium: Memory
sizeLimit: "10Mi"
- name: tz-config
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
長生命週期(Deployment / StatefulSet)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-demo
namespace: production
labels:
app: nginx-demo
version: v1.0.0
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
selector:
matchLabels:
app: nginx-demo
template:
metadata:
labels:
app: nginx-demo
version: v1.0.0
spec:
terminationGracePeriodSeconds: 600 # 10分鐘優雅停止時間
containers:
# 業務容器 - Web應用
- name: nginx-demo
image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
# 啟動命令和訊號處理
command: ["/bin/sh", "-c"]
args:
- |
# 定義訊號處理函數
_term_handler() {
echo "[$(date)] [nginx-demo] Caught SIGTERM, starting graceful shutdown..."
# 發送QUIT訊號給Nginx進行優雅停止
if [ -n "$NGINX_PID" ]; then
kill -QUIT "$NGINX_PID" 2>/dev/null || true
echo "[$(date)] [nginx-demo] Sent SIGQUIT to Nginx PID: $NGINX_PID"
# 等待Nginx優雅停止
wait "$NGINX_PID"
EXIT_CODE=$?
echo "[$(date)] [nginx-demo] Nginx stopped with exit code: $EXIT_CODE"
fi
# 通知LoongCollector業務容器已停止
echo "[$(date)] [nginx-demo] Writing tombstone file"
touch /tasksite/tombstone
exit $EXIT_CODE
}
# 註冊訊號處理
trap _term_handler SIGTERM SIGINT SIGQUIT
# 等待LoongCollector準備就緒
echo "[$(date)] [nginx-demo]: Waiting for LoongCollector to be ready..."
until [[ -f /tasksite/cornerstone ]]; do
sleep 1
done
echo "[$(date)] [nginx-demo]: LoongCollector is ready, starting business logic"
# 啟動Nginx
echo "[$(date)] [nginx-demo] Starting Nginx..."
nginx -g 'daemon off;' &
NGINX_PID=$!
echo "[$(date)] [nginx-demo] Nginx started with PID: $NGINX_PID"
# 等待Nginx進程
wait $NGINX_PID
EXIT_CODE=$?
# 非訊號導致的退出也要通知LoongCollector
if [ ! -f /tasksite/tombstone ]; then
echo "[$(date)] [nginx-demo] Unexpected exit, writing tombstone"
touch /tasksite/tombstone
fi
exit $EXIT_CODE
# 資源配置
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "1000m"
memory: "1Gi"
# 卷掛載
volumeMounts:
- name: nginx-logs
mountPath: /var/log/nginx
- name: tasksite
mountPath: /tasksite
- name: tz-config
mountPath: /etc/localtime
readOnly: true
# LoongCollector Sidecar容器
- name: loongcollector
image: aliyun-observability-release-registry.cn-shenzhen.cr.aliyuncs.com/loongcollector/loongcollector:v3.1.1.0-20fa5eb-aliyun
command: ["/bin/bash", "-c"]
args:
- |
echo "[$(date)] LoongCollector: Starting initialization"
# 啟動LoongCollector服務
/etc/init.d/loongcollectord start
# 等待配置下載和服務就緒
sleep 15
# 驗證服務狀態
if /etc/init.d/loongcollectord status; then
echo "[$(date)] LoongCollector: Service started successfully"
touch /tasksite/cornerstone
else
echo "[$(date)] LoongCollector: Failed to start service"
exit 1
fi
# 等待業務容器完成
echo "[$(date)] LoongCollector: Waiting for business container to complete"
until [[ -f /tasksite/tombstone ]]; do
sleep 2
done
echo "[$(date)] LoongCollector: Business completed, waiting for log transmission"
# 給足夠時間傳輸剩餘日誌
sleep 30
echo "[$(date)] LoongCollector: Stopping service"
/etc/init.d/loongcollectord stop
echo "[$(date)] LoongCollector: Shutdown complete"
# 健全狀態檢查
livenessProbe:
exec:
command: ["/etc/init.d/loongcollectord", "status"]
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
# 資源配置
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "2000m"
memory: "2048Mi"
# 環境變數配置
env:
- name: ALIYUN_LOGTAIL_USER_ID
value: "${your_aliyun_user_id}"
- name: ALIYUN_LOGTAIL_USER_DEFINED_ID
value: "${your_machine_group_user_defined_id}"
- name: ALIYUN_LOGTAIL_CONFIG
value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
# 啟用全量排空模式,確保Pod停止時發送所有日誌
- name: enable_full_drain_mode
value: "true"
# 追加 Pod 環境資訊作為日誌標籤
- name: "ALIYUN_LOG_ENV_TAGS"
value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
# 擷取 Pod 和 Node 的資訊
- name: "_pod_name_"
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: "_pod_ip_"
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: "_namespace_"
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: "_node_name_"
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: "_node_ip_"
valueFrom:
fieldRef:
fieldPath: status.hostIP
# 卷掛載
volumeMounts:
- name: nginx-logs
mountPath: /var/log/nginx
readOnly: true
- name: tasksite
mountPath: /tasksite
- name: tz-config
mountPath: /etc/localtime
readOnly: true
# 卷定義
volumes:
- name: nginx-logs
emptyDir: {}
- name: tasksite
emptyDir:
medium: Memory
sizeLimit: "50Mi"
- name: tz-config
hostPath:
path: /usr/share/zoneinfo/Asia/Shanghai
附錄:原生解析外掛程式詳解
在Logtail配置頁面的處理配置地區,可以通過添加處理外掛程式,對原始日誌進行結構化處理。如需為已有採集配置添加處理外掛程式,可以參考如下步驟:
在左側導覽列選擇
日誌庫,找到目標Logstore。單擊其名稱前的
展開Logstore。單擊Logtail配置,在配置列表中,找到目標Logtail配置,單擊操作列的管理Logtail配置。
在Logtail配置頁面,單擊編輯。
此處僅介紹常用處理外掛程式,覆蓋常見Tlog情境,如需更多功能,請參考拓展處理外掛程式。
外掛程式組合使用規則(適用於 LoongCollector / Logtail 2.0 及以上版本):
原生處理外掛程式與拓展處理外掛程式均可獨立使用,也支援按需組合使用。
推薦優先選用原生處理外掛程式,因其具備更優的效能和更高的穩定性。
當原生功能無法滿足業務需求時,可在已配置的原生處理外掛程式之後,追加配置拓展處理外掛程式以實現補充處理。
順序約束:
所有外掛程式按照配置順序組成處理鏈,依次執行。需要注意:所有原生處理外掛程式必須先於任何拓展處理外掛程式,添加任意拓展處理外掛程式後,將無法繼續添加原生處理外掛程式。
正則解析
通過Regex提取日誌欄位,並將日誌解析為索引值對形式,每個欄位都可以被獨立查詢和分析。
效果樣本:
未經任何處理的原始日誌 | 使用正則解析外掛程式 |
| |
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
Regex:用於匹配日誌,支援自動產生或手動輸入:
自動產生:
單擊自動產生Regex。
在日誌範例中劃選需要提取的日誌內容。
單擊產生正則。

手動輸入:根據日誌格式手動輸入Regex。
配置完成後,單擊驗證,測試Regex是否能夠正確解析日誌內容。
日誌提取欄位:為提取的日誌內容(Value),設定對應的欄位名(Key)。
其他參數請參考情境二:結構化日誌中的通用配置參數說明。
分隔字元解析
通過分隔字元將日誌內容結構化,解析為多個索引值對形式,支援單字元分隔字元和多字元分隔字元。
效果樣本:
未經任何處理的原始日誌 | 按指定字元 |
| |
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
分隔字元:指定用於切分日誌內容的字元。
樣本:對於CSV格式檔案,選擇自訂,輸入半形逗號(,)。
引用符:當某個欄位值中包含分隔字元時,需要指定引用符包裹該欄位,避免錯誤切割。
日誌提取欄位:按分隔順序依次為每一列設定對應的欄位名稱(Key)。規則要求如下:
欄位名只能包含:字母、數字、底線(_)。
必須以字母或底線(_)開頭。
最大長度:128位元組。
其他參數請參考情境二:結構化日誌中的通用配置參數說明。
標準JSON解析
將Object類型的JSON日誌結構化,解析為索引值對形式。
效果樣本:
未經任何處理的原始日誌 | 標準JSON索引值自動提取 |
| |
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
原始欄位:預設值為content(此欄位用於存放待解析的原始日誌內容)。
其他參數請參考情境二:結構化日誌中的通用配置參數說明。
嵌套JSON解析
通過指定展開深度,將嵌套的JSON日誌解析為索引值對形式。
效果樣本:
未經任何處理的原始日誌 | 展開深度:0,並使用展開深度作為首碼 | 展開深度:1,並使用展開深度作為首碼 |
| | |
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
原始欄位:需要展開的原始欄位名,例如
content。JSON展開深度:JSON對象的展開層級。0表示完全展開(預設值),1表示當前層級,以此類推。
JSON展開串連符:JSON展開時欄位名的串連符,預設為底線 _。
JSON展開欄位首碼:指定JSON展開後欄位名的首碼。
展開數組:開啟此項可將數組展開為帶索引的索引值對。
樣本:
{"k":["a","b"]}展開為{"k[0]":"a","k[1]":"b"}。如果需要對展開後的欄位進行重新命名(例如,將 prefix_s_key_k1 改為 new_field_name),可以後續再添加一個重新命名欄位外掛程式來完成映射。
其他參數請參考情境二:結構化日誌中的通用配置參數說明。
JSON數組解析
使用json_extract函數,從JSON數組中提取JSON對象。
效果樣本:
未經任何處理的原始日誌 | 提取JSON數組結構 |
| |
配置步驟:在Logtail配置頁面的處理配置地區,將處理模式切換為SPL,配置SPL語句,使用 json_extract函數從JSON數組中提取JSON對象。
樣本:從日誌欄位 content 中提取 JSON 數組中的元素,並將結果分別儲存在新欄位 json1和 json2 中。
* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')Apache日誌解析
根據Apache日誌設定檔中的定義將日誌內容結構化,解析為多個索引值對形式。
效果樣本:
未經任何處理的原始日誌 | Apache通用日誌格式 |
| |
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
日誌格式:combined
APACHE配置欄位:系統會根據日誌格式自動填滿配置。
重要請務必核對自動填滿的內容,確保與伺服器上 Apache 設定檔(通常位於/etc/apache2/apache2.conf)中定義的 LogFormat 完全一致。
其他參數請參考情境二:結構化日誌中的通用配置參數說明。
資料脫敏
對日誌中的敏感性資料進行脫敏處理。
效果樣本:
未經任何處理的原始日誌 | 脫敏結果 |
| |
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
時間解析
對日誌中的時間欄位進行解析,並將解析結果設定為日誌的__time__欄位。
效果樣本:
未經任何處理的原始日誌 | 時間解析 |
|
|
配置步驟:在Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇:
原始欄位:解析日誌前,用於存放日誌內容的原始欄位。
時間格式:根據日誌中的時間內容設定對應的時間格式。
時區:選擇日誌時間欄位所在的時區。預設使用機器時區,即LoongCollector(Logtail)進程所在環境的時區。
附錄:Regex使用限制(容器過濾)
容器過濾時所使用的Regex基於Go語言的RE2引擎,與PCRE等其他引擎相比存在部分文法限制。請在編寫Regex時注意以下事項:
1. 命名分組文法差異
Go語言使用 (?P<name>...) 文法定義命名分組,不支援 PCRE中的 (?<name>...) 文法。
正確樣本:
(?P<year>\d{4})錯誤寫法:
(?<year>\d{4})
2. 不支援的正則特性
以下常見但複雜的正則功能在RE2中不可用,請避免使用:
斷言:
(?=...)、(?!...)、(?<=...)、(?<!...)條件運算式:
(?(condition)true|false)遞迴匹配:
(?R)、(?0)子程式引用:
(?&name)、(?P>name)原子組:
(?>...)
3. 使用建議
推薦使用 Regex101等工具調試Regex時,選擇 Golang (RE2) 模式進行驗證,以確保相容性。若使用了上述不支援的文法,外掛程式將無法正確解析或匹配。
> 建立機器組


