簡介： SLS針對Logtail本身以及Logtail的管控組件alibaba-log-controller，採用K8s事件的方式，將處理流程中的關鍵事件透出，從而讓用戶能夠更清楚的感知其中發生的異常。

背景

隨着K8s和雲的普及，越來越多的公司將業務系統部署到雲上，並且使用K8s來部署應用。Logtail是SLS提供的日誌採集Agent，能夠非常好的適應K8s下各種場景的日誌採集，支持通過DaemonSet方式和Sidecar方式採集Kubernetes集羣的容器標準輸出或者文件日誌。Logtail作爲一個K8s場景下非常重要一個組件，其自身運行狀態需要有更好的可觀測方案。

K8s中Logtail管控原理

K8s場景下，除了控制檯管控之外，Logtail還提供了環境變量和CRD兩種配置方式，用來配置容器日誌採集。

環境變量方式

環境變量的配置方式，參考文檔

環境變量方式管控原理：

Logtail會去掃描所有的容器信息，並獲取容器中的環境變量信息
過濾其中包含aliyun_logs_前綴的字段，然後組合成採集配置信息，Logtail同時會用改環境變量作爲採集配置中容器過濾的條件
Logtail端收到採集配置的變化後，會調整本地的採集配置，從而實現整個控制流程的閉環。

CRD方式

CRD方式創建採集配置流程，參考文檔。

CRD配置原理如上圖所示：

K8S內部會註冊自定義資源（CRD，CustomResourceDefinition）AliyunLogConfig，並部署alibaba-log-controller
CR對象創建/變化/刪除之後，alibaba-log-controller會監聽到CR對象的變化，從而對CR對象中指定的logstore、採集配置進行相應的操作
Logtail端收到採集配置的變化後，會調整本地的採集配置，從而實現整個控制流程的閉環。

無論是環境變量的配置方式，還是CRD的配置方式，Logtail的狀態都是比較難觀測的。

環境變量配置之後，無論配置的是否正確，都不會影響業務容器的正常運行。但是logtail是否讀到了環境變量裏的配置並且進行了正確的處理，這個用戶只能看到最終的結果。如果配置錯了，用戶也不能拿到及時的反饋，只能看到SLS控制檯上，logstore沒有創建出來或者採集配置沒有創建出來，中間到底哪一個步驟報錯了，用戶也無法感知。
一個CR配置之後，從K8s的角度來看，只能看到CR對象創建成功了。但是CRD對象創建成功之後，alibaba-log-controller內的處理流程，對於用戶來講，就像黑盒一樣。如果出現異常，用戶並不清楚究竟是中間哪一步出了問題。

基於以上的問題，SLS針對Logtail本身以及Logtail的管控組件alibaba-log-controller，採用K8s事件的方式，將處理流程中的關鍵事件透出，從而讓用戶能夠更清楚的感知其中發生的異常。

Logtail事件監控實戰

限制說明

alibaba-log-controller版本大於等於0.3.2
logtail版本大於等於1.1.2
logtail中目前涵蓋的事件
創建project、創建logstore、創建採集配置
alibaba-log-controller中涵蓋的事件
創建project、創建logstore、創建採集配置、創建索引、創建ingress日誌中心、checkpoint寫入

開啓Logtail事件監控

未開啓過K8s事件中心

步驟一：創建K8s事件中心

登錄日誌服務控制檯。

在日誌應用區域的雲產品Lens頁籤中，單擊K8s事件中心。
在事件中心管理頁面，單擊添加。
在添加事件中心頁面，配置相關參數。

如果選擇已有Project，則從Project下拉框中選擇已創建的Project，用於管理K8s事件中心相關資源（Logstore、儀表盤等）。
如果選擇從容器服務選擇K8s集羣，則從K8s集羣下拉框中選擇已創建的K8s集羣。通過此方式創建K8s事件中心，日誌服務默認創建一個名爲k8s-log-{cluster-id}的Project，用於管理K8s事件中心相關資源（Logstore、儀表盤等）。

單擊下一步。

步驟二：部署eventer和node-problem-detector

您需要在Kubernetes集羣中配置eventer和node-problem-detector後才能正常使用K8s事件中心。

阿里雲Kubernetes配置方式阿里雲Kubernetes應用市場中的ack-node-problem-detector已集成eventer和node-problem-detector功能，您只需要部署該組件即可，該組件詳細部署請參見事件監控。

登錄容器服務控制檯。
在左側導航欄中，選擇運維管理 > 組件管理，日誌與監控下，單擊ack-node-problem-detector。

單擊安裝、確認。

自建Kubernetes配置方式

部署eventer。更多信息，請參見採集Kubernetes事件。
部署node-problem-detector。更多信息，請參見Github。

已開啓過K8s事件中心

由於Logtail事件監控依賴了比較新的索引，因此可以在K8s事件中心頁面，點擊版本升級的選項，裏面有一個索引更新的按鈕，點擊之後，即可以開啓新的索引字段。

Logtail事件監控大盤

Logtail事件監控大盤將各個步驟的結果完整展示出來，並且以時間軸的方式，展示各個事件的先後順序，同時支持用Project、Logstore、採集配置名參數進行過濾。

針對異常的事件，Logtail事件監控大盤會把異常事件的詳情展示出來：

詳情字段	含義
time	事件發生的時間
source	事件來源，主要有alibaba-log-controller和logtail
resourceName	主要針對CRD場景下，CRD的名字
configName	採集配置的名字
project	採集配置所屬的project
logstore	採集配置所屬的logstore
reason	事件產生的原因
message	事件的詳細信息
errorCode	異常步驟的錯誤碼
errorMessage	異常步驟的報錯信息
requestId	異常步驟的請求標識

針對採集配置的創建、變更、刪除操作，Logtail事件監控提供了相關的記錄，用於進行操作審計

詳情字段	含義
time	事件發生的時間
source	事件來源，主要有alibaba-log-controller和logtail
action	創建、變更或者刪除
level	normal或者warning
configName	採集配置的名字
project	採集配置所屬的project
logstore	採集配置所屬的logstore
logtailconfig	採集配置詳情

應用案例

場景1: 通過CRD配置，logstore數量超過quota限制

一個CRD配置如下：

apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig
metadata:
  name: simple-index-crd-example-0909-no-1
spec:
  logstore: logstore-quota-test-0909-no-1
  logtailConfig:
    inputType: plugin
    configName: simple-index-crd-example-0909-no-1
    inputDetail:
      plugin:
        inputs:
          -
            type: service_docker_stdout
            detail:
              Stdout: true
              Stderr: true
              IncludeEnv:
                collect_crd_index_out: true

apply之後發現CRD已經創建成功，但是logstore沒有創建出來。

通過限制Project、Logstore和採集配置名的條件

打開異常事件詳情列表，可以清楚看到創建logstore步驟的異常情況，錯誤碼是ProjectQuotaExceed，報錯詳情是：project k8s-log-c4551a67027d248bfb049765de783e647, shard count quota exceed。由此，可以直接找到SLS值班的同學，提升quota，從而解決這個問題

場景2: 通過CRD配置，關鍵參數填寫錯誤

一個CRD配置如下：

apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig
metadata:
  name: simple-index-crd-example-0909-mock-4
spec:
  logstore: logstore-quota-test-0909-mock-4
  logtailConfig:
    inputType: pluginss
    configName: simple-index-crd-example-0909-mock-4
    inputDetail:
      plugin:
        inputs:
          -
            type: service_docker_stdout
            detail:
              Stdout: true
              Stderr: true
              IncludeEnv:
                collect_crd_index_out: true

apply之後發現CRD已經創建成功，但是logstore和採集配置也都是沒有創建出來。

通過限制Project、Logstore和採集配置名的條件

打開異常事件詳情列表，可以清楚看到創建採集配置步驟的異常情況，錯誤信息裏提示：invalid input type : pluginss

由此可以知道原來是CRD裏inputType字段的取值有問題，通過採集配置事件詳情列表裏的記錄，也可以清楚看到通過CRD轉換之後的採集配置數據。

場景3: 通過環境變量和CRD方式針對同一個Project/Logstore採集配置進行變更，導致的配置衝突

在多人維護一個K8s集羣的時候，有可能兩個人針對同一份採集配置，通過不同的配置方式進行了修改，這樣的問題排查起來往往很麻煩。

我們模擬這樣一個場景：

部署一個測試的Pod，環境變量配置如下：

可以看到logstore和採集配置已經創建成功

CRD配置如下：

apiVersion: log.alibabacloud.com/v1alpha1
kind: AliyunLogConfig
metadata:
  name: taiye-test-0707
spec:
  logstore: taiye-test-0707
  logtailConfig:
    inputType: plugin
    configName: taiye-test-0707
    inputDetail:
      plugin:
        inputs:
          -
            type: service_docker_stdout
            detail:
              Stdout: true
              Stderr: true
              IncludeEnv:
                conflict-test: true