全部產品
Search
文件中心

Container Service for Kubernetes:採集Kubernetes Pod文本日誌(Sidecar模式)

更新時間:Dec 18, 2025

在 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

  1. 登入Log Service控制台

  2. 單擊建立Project,並配置:

    • 所屬地區:根據日誌來源選擇,建立後不可修改。

    • Project名稱:阿里雲內全域唯一,建立後不可修改。

    • 其他配置保持預設,單擊建立。如需瞭解其他參數,請參見建立Project

建立Logstore

  1. 單擊Project名稱,進入目標Project。

  2. 在左側導覽列,選擇image日誌儲存,單擊+

  3. 在建立Logstore頁面,完成以下核心配置:

    • Logstore名稱:設定一個在Project內唯一的名稱,該名稱建立後不可修改。

    • Logstore類型:根據規格對比選擇標準型或查詢型。

    • 計費模式

      • 按使用功能計費:按儲存、索引、讀寫次數等各項資源獨立計費。適合小規模或功能使用不確定的情境。

      • 按寫入資料量計費:僅按原始寫入資料量計費,提供30天免費儲存,以及免費的資料加工、投遞等功能。適合儲存周期接近30天或資料處理鏈路複雜的業務情境。

    • 資料儲存時間:設定日誌的保留天數(1~3650天,3650為永久儲存),預設為30天。

    • 其他配置保持預設,單擊確定。如需瞭解其他配置資訊,請參考管理Logstore

步驟一:注入LoongCollector Sidecar容器

在業務應用Pod中注入LoongCollector Sidecar容器,並配置共用卷以實現日誌採集。若尚未部署業務應用,或僅用於測試,可直接使用附錄:YAML樣本快速驗證流程。

1. 修改業務Pod YAML配置

  1. 定義共用卷

    在 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  # 請按需修改時區
    
  2. 配置業務容器掛載

    在業務容器(如 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
    
  3. 注入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_CODE

3. 設定優雅終止時間

在 spec.template.spec 中設定足夠的終止寬限期,以確保 LoongCollector 有足夠時間上傳剩餘日誌。

spec:
  # ... 您現有的其他 spec 配置 ...
  template:
    spec:
      terminationGracePeriodSeconds: 600  # 10分鐘優雅停止時間

4. 變數說明

變數

說明

${your_aliyun_user_id}

設定為您的阿里雲帳號(主帳號)ID。更多資訊,請參見配置使用者標識

${your_machine_group_user_defined_id}

自訂設定機器組的自訂標識,用於建立自訂機器組。例如nginx-log-sidecar

重要

請確保該標識在您的Project所在地區內唯一。

${your_region_config}

請根據Log ServiceProject所在地區和訪問的網路類型填寫。其中,地區資訊請參見開服地區

樣本:若Project位於華東1(杭州),則以阿里雲內網訪問時為cn-hangzhou,公網訪問時使用cn-hangzhou-internet

${shared_volume_name}

自訂設定卷的名稱。

重要

volumeMounts節點下的name參數與volumes節點下的name參數需設定為一致,即確保LoongCollector容器和業務容器掛載相同的卷上。

${dir_containing_your_files}

設定掛載路徑,即容器待採集文本日誌所在目錄。

5. 應用配置並驗證

  1. 執行以下命令部署變更:

    kubectl apply -f <YOUR-YAML>
  2. 查看 Pod 狀態,確認 LoongCollector 容器已成功注入:

    kubectl describe pod <YOUR-POD-NAME>

    若看到兩個容器(業務容器 + loongcollector),且狀態正常,則注入成功。

步驟二:建立使用者自訂標識機器組

本步驟將Pod中注入的 LoongCollector Sidecar執行個體註冊到Log Service,實現採集配置的統一管理和下發。

操作流程

  1. 建立機器組

    1. 進入目標Project,在左側導覽列單擊image資源 > 機器組

    2. 在機器組頁面,單擊機器組 > 建立機器組

  2. 配置機器組資訊

    填寫以下參數後,單擊確定

    • 名稱:機器組名稱,建立後不可修改。命名規則如下:

      • 只能包括小寫字母、數字、短劃線(-)和底線(_)。

      • 必須以小寫字母或者數字開頭和結尾。

      • 長度必須在 2~128 字元之間。

    • 機器組標識:選擇使用者自訂標識

    • 使用者自訂標識:填入您在步驟一YAML檔案中為 LoongCollector 容器設定的環境變數ALIYUN_LOGTAIL_USER_DEFINED_ID 的值。必須完全一致,否則無法關聯成功。

  3. 檢查機器組心跳狀態

    建立完成後,單擊目標機器組名稱,在機器組狀態區域,查看心跳狀態。

    • OK:表示LoongCollector 已成功串連到Log Service,機器組註冊成功。

    • FAIL:

      • 可能是配置未生效,配置生效時間大約需要2分鐘,請稍後重新整理頁面重試。

      • 如果2分鐘後仍為FAIL,請參考Logtail機器組問題排查思路進行診斷。

每個 Pod 對應一個獨立的 LoongCollector 執行個體,建議為不同業務或環境使用不同的自訂標識,便於精細化管理。

步驟三:建立採集配置

定義 LoongCollector 應採集哪些記錄檔、如何解析日誌結構、如何過濾內容,並將配置綁定到登入的機器組。

操作流程

  1. image日誌庫頁面,單擊目標Logstore名稱前的image展開。

  2. 單擊資料接入後的image,在快速資料接入彈框中,找到Kubernetes-檔案卡片,單擊立即接入

  3. 機器組配置,完成後單擊下一步

    • 使用情境:選擇K8s情境

    • 部署方式:選擇Sidecar

    • 選擇機器組:在源機器組列表中勾選步驟二中建立的使用者自訂標識機器組,單擊image添加至應用機器組列表。

  4. 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識別完整日誌,保留完整語義結構。

image

image

image

配置步驟: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提供多種資料解析外掛程式,能夠自動將不同格式的原始日誌轉換為結構化資料,為後續的分析、監控和警示提供堅實的資料基礎。

效果樣本:

未經任何處理的原始日誌

結構化解析後的日誌

192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"
body_bytes_sent: 368
http_referer: -
http_user_agent : Mozi11a/5.0 (Nindows NT 10.0; Win64; x64) AppleMebKit/537.36 (KHTML, like Gecko) Chrome/131.0.x.x Safari/537.36
remote_addr:192.168.*.*
remote_user: -
request_length: 514
request_method: GET
request_time: 0.000
request_uri: /nginx-logo.png
status: 200
time_local: 15/Apr/2025:16:40:00

配置步驟:Logtail配置頁面的處理配置地區

  1. 添加解析外掛程式:單擊添加處理外掛程式,根據實際格式配置正則解析、分隔字元解析、JSON 解析等外掛程式。此處以採集NGINX日誌為例,選擇原生處理外掛程式 > NGINX模式解析

  2. 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"';
    重要

    此處的格式定義必須與伺服器上組建記錄檔的格式完全一致,否則將導致日誌解析失敗。

  3. 通用配置參數說明:以下參數在多種資料解析外掛程式中都會出現,其功能和用法是統一的。

    • 原始欄位:指定要解析的源欄位名。預設為content,即採集到的整條日誌內容。

    • 解析失敗時保留原始欄位:推薦開啟。當日誌無法被外掛程式成功解析時(例如格式不匹配),此選項能確保原始日誌內容不會丟失,而是被完整保留在指定的原始欄位中。

    • 解析成功時保留原始欄位:選中後,即使日誌解析成功,原始日誌內容也會被保留。

3. 日誌過濾

在日誌採集過程中,大量低價值或無關日誌(如 DEBUG/INFO 層級日誌)的無差別收集,不僅造成儲存資源浪費、增加成本,還影響查詢效率並帶來資料泄露風險。為此,可通過精細化過濾策略實現高效、安全的日誌採集。

通過內容過濾降低成本

基於日誌內容的欄位過濾(如僅採集 level 為 WARNING 或 ERROR 的日誌)。

效果樣本:

未經任何處理的原始日誌

只採集WARNINGERROR日誌

{"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"}
{"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}
{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}
{"level":"WARNING","timestamp":"2025-09-23T19:11:40+0800","cluster":"yilu-cluster-0728","message":"Disk space is running low","freeSpace":"15%"}
{"level":"ERROR","timestamp":"2025-09-23T19:11:42+0800","cluster":"yilu-cluster-0728","message":"Failed to connect to database","errorCode":5003}

配置步驟: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與外掛程式配置後,單擊下一步,進入查詢分析配置頁面:

  • 系統預設開啟全文索引,支援對日誌原始內容進行關鍵詞搜尋。

  • 如需按欄位進行精確查詢,請在頁面載入出預覽資料後,單擊自動產生索引,Log Service將根據預覽資料中的第一條內容產生欄位索引

配置完成後,單擊下一步,完成整個採集流程的設定。

步驟五:查看上報日誌

完成採集配置並應用到機器組後,系統將自動下發配置並開始採集增量日誌。

  1. 確認記錄檔有新增內容:LoongCollector只採集增量日誌。執行 tail -f /path/to/your/log/file,並觸發業務操作,確保有新的日誌正在寫入。

  2. 查詢日誌:進入目標 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"                          # 啟用全量排空模式

後續操作

  1. 資料視覺效果:藉助可視化儀錶盤監控關鍵計量趨勢。

  2. 資料異常自動預警:設定警示策略,即時感知系統的異常情況。

  3. Log Service僅採集增量日誌,如需採集歷史日誌請參見匯入歷史記錄檔

附錄:YAML樣本

本樣本展示了一個完整的 Kubernetes Deployment 配置,包含業務容器(Nginx)和 LoongCollector Sidecar 容器,適用於通過 Sidecar 模式採集容器日誌。

使用前請完成以下三項關鍵替換:

  1. ${your_aliyun_user_id}替換為您的阿里雲主帳號 UID;

  2. ${your_machine_group_user_defined_id}替換為步驟三中建立的機器組自訂標識,必須完全一致。

  3. 將 ${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配置頁面的處理配置地區,可以通過添加處理外掛程式,對原始日誌進行結構化處理。如需為已有採集配置添加處理外掛程式,可以參考如下步驟:

  1. 在左側導覽列選擇image日誌庫,找到目標Logstore。

  2. 單擊其名稱前的image展開Logstore。

  3. 單擊Logtail配置,在配置列表中,找到目標Logtail配置,單擊操作列的管理Logtail配置

  4. 在Logtail配置頁面,單擊編輯

此處僅介紹常用處理外掛程式,覆蓋常見Tlog情境,如需更多功能,請參考拓展處理外掛程式
重要

外掛程式組合使用規則(適用於 LoongCollector / Logtail 2.0 及以上版本):

  • 原生處理外掛程式與拓展處理外掛程式均可獨立使用,也支援按需組合使用。

  • 推薦優先選用原生處理外掛程式,因其具備更優的效能和更高的穩定性。

  • 當原生功能無法滿足業務需求時,可在已配置的原生處理外掛程式之後,追加配置拓展處理外掛程式以實現補充處理。

順序約束:

所有外掛程式按照配置順序組成處理鏈,依次執行。需要注意:所有原生處理外掛程式必須先於任何拓展處理外掛程式,添加任意拓展處理外掛程式後,將無法繼續添加原生處理外掛程式。

正則解析

通過Regex提取日誌欄位,並將日誌解析為索引值對形式,每個欄位都可以被獨立查詢和分析。

效果樣本:

未經任何處理的原始日誌

使用正則解析外掛程式

127.0.0.1 - - [16/Aug/2024:14:37:52 +0800] "GET /wp-admin/admin-ajax.php?action=rest-nonce HTTP/1.1" 200 41 "http://www.example.com/wp-admin/post-new.php?post_type=page" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0"
body_bytes_sent: 41
http_referer: http://www.example.com/wp-admin/post-new.php?post_type=page
http_user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; ×64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36 Edg/127.0.0.0
remote_addr: 127.0.0.1
remote_user: -
request_method: GET
request_protocol: HTTP/1.1
request_uri: /wp-admin/admin-ajax.php?action=rest-nonce
status: 200
time_local: 16/Aug/2024:14:37:52 +0800

配置步驟:Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇原生處理外掛程式 > 正則解析

  • Regex:用於匹配日誌,支援自動產生或手動輸入:

    • 自動產生:

      • 單擊自動產生Regex

      • 日誌範例中劃選需要提取的日誌內容。

      • 單擊產生正則

        image

    • 手動輸入:根據日誌格式手動輸入Regex

    配置完成後,單擊驗證,測試Regex是否能夠正確解析日誌內容。

  • 日誌提取欄位:為提取的日誌內容(Value),設定對應的欄位名(Key)。

  • 其他參數請參考情境二:結構化日誌中的通用配置參數說明。


分隔字元解析

通過分隔字元將日誌內容結構化,解析為多個索引值對形式,支援單字元分隔字元和多字元分隔字元。

效果樣本:

未經任何處理的原始日誌

按指定字元,切割欄位

05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1",200,18204,aliyun-sdk-java
ip:10.10.*.*
request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1
size:18204
status:200
time:05/May/2025:13:30:28
user_agent:aliyun-sdk-java

配置步驟:Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇原生處理 > 分隔字元解析

  • 分隔字元:指定用於切分日誌內容的字元。

    樣本:對於CSV格式檔案,選擇自訂,輸入半形逗號(,)。

  • 引用符:當某個欄位值中包含分隔字元時,需要指定引用符包裹該欄位,避免錯誤切割。

  • 日誌提取欄位:按分隔順序依次為每一列設定對應的欄位名稱(Key)。規則要求如下:

    • 欄位名只能包含:字母、數字、底線(_)。

    • 必須以字母或底線(_)開頭。

    • 最大長度:128位元組。

  • 其他參數請參考情境二:結構化日誌中的通用配置參數說明。


標準JSON解析

將Object類型的JSON日誌結構化,解析為索引值對形式。

效果樣本:

未經任何處理的原始日誌

標準JSON索引值自動提取

{"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2025:13:30:28"}
ip: 10.200.98.220
request: {"status": "200", "latency" : "18204" }
time: 05/Jan/2025:13:30:28
url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek******&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1
user-agent:aliyun-sdk-java

配置步驟:Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇原生處理外掛程式 > JSON解析

  • 原始欄位:預設值為content(此欄位用於存放待解析的原始日誌內容)。

  • 其他參數請參考情境二:結構化日誌中的通用配置參數說明。


嵌套JSON解析

通過指定展開深度,將嵌套的JSON日誌解析為索引值對形式。

效果樣本:

未經任何處理的原始日誌

展開深度:0,並使用展開深度作為首碼

展開深度:1,並使用展開深度作為首碼

{"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}}
0_s_key_k1_k2_k3_k41:41
0_s_key_k1_k2_k3_k4_k51:51
0_s_key_k1_k2_k3_k4_k52:52
1_s_key:{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}

配置步驟:Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇拓展處理外掛程式 > 展開JSON欄位

  • 原始欄位:需要展開的原始欄位名,例如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數組結構

[{"key1":"value1"},{"key2":"value2"}]
json1:{"key1":"value1"}
json2:{"key2":"value2"}

配置步驟: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通用日誌格式combined解析

1 192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1.1" 200 1234 "https://www.example.com/referrer" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36"
http_referer:https://www.example.com/referrer
http_user_agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.X.X Safari/537.36
remote_addr:192.168.1.10
remote_ident:-
remote_user:-
request_method:GET
request_protocol:HTTP/1.1
request_uri:/index.html
response_size_bytes:1234
status:200
time_local:[08/May/2024:15:30:28 +0800]

配置步驟:Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇原生處理外掛程式 > APACHE模式解析

  • 日誌格式combined

  • APACHE配置欄位:系統會根據日誌格式自動填滿配置。

    重要

    請務必核對自動填滿的內容,確保與伺服器上 Apache 設定檔(通常位於/etc/apache2/apache2.conf)中定義的 LogFormat 完全一致。

  • 其他參數請參考情境二:結構化日誌中的通用配置參數說明。


資料脫敏

對日誌中的敏感性資料進行脫敏處理。

效果樣本:

未經任何處理的原始日誌

脫敏結果

[{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]
[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

配置步驟:Logtail配置頁面的處理配置地區,單擊添加處理外掛程式,選擇原生處理外掛程式 > 脫敏處理

  • 原始欄位:解析日誌前,用於存放日誌內容的原始欄位。

  • 脫敏方式

    • const:將敏感內容替換成所修改的字串。

    • md5:將敏感內容替換為其對應的MD5值。

  • 替換字串:選擇脫敏方式const時,需要輸入字串,用於替換敏感內容。

  • 被替換內容前的內容運算式:用於尋找敏感內容,使用RE2文法配置。

  • 被替換的內容運算式:敏感內容的運算式,使用RE2文法配置。


時間解析

對日誌中的時間欄位進行解析,並將解析結果設定為日誌的__time__欄位。

效果樣本:

未經任何處理的原始日誌

時間解析

{"level":"INFO","timestamp":"2025-09-23T19:11:47+0800","cluster":"yilu-cluster-0728","message":"User logged in successfully","userId":"user-123"}

image

配置步驟: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) 模式進行驗證,以確保相容性。若使用了上述不支援的文法,外掛程式將無法正確解析或匹配。