一、背景

石墨文檔全部應用部署在Kubernetes上，每時每刻都會有大量的日志輸出，我們之前主要使用SLS和ES作為日志存儲。但是我們在使用這些組件的時候，發現了一些問題。

1、成本問題

SLS個人覺得是一個非常優秀的產品，速度快，交互方便，但是SLS索引成本比較貴

• 我們想減少SLS索引成本的時候，發現云廠商并不支持分析單個索引的成本，導致我們無法知道是哪些索引構建得不夠合理
• ES使用的存儲非常多，并且耗費大量的內存

2、通用問題

• 如果業務是混合云架構，或者業務形態有SAAS和私有化兩種方式，那么SLS并不能通用
• 日志和鏈路，需要用兩套云產品，不是很方便

3、精確度問題

• SLS存儲的精度只能到秒，但我們實際日志精度到毫秒，如果日志里面有traceid，SLS中無法通過根據traceid信息，將日志根據毫秒時間做排序，不利于排查錯誤

我們經過一番調研后，發現使用Clickhouse能夠很好地解決以上問題，并且Clickhouse省存儲空間，非常省錢，所以我們選擇了Clickhouse方案存儲日志。但當我們深入研究后，Clickhouse作為日志存儲有許多落地的細節，但業界并沒有很好闡述相關Clickhouse采集日志的整套流程，以及沒有一款優秀的Clickhouse日志查詢工具幫助分析日志，為此我們寫了一套Clickhouse日志系統貢獻給開源社區，并將Clickhouse的日志采集架構的經驗做了總結。先上個Clickhouse日志查詢界面，讓大家感受下石墨最懂前端的后端程序員。

二、架構原理圖

我們將日志系統分為四個部分：日志采集、日志傳輸、日志存儲、日志管理。

• 日志采集：LogCollector采用Daemonset方式部署，將宿主機日志目錄掛載到LogCollector的容器內，LogCollector通過掛載的目錄能夠采集到應用日志、系統日志、K8S審計日志等
• 日志傳輸：通過不同Logstore映射到Kafka中不同的Topic，將不同數據結構的日志做了分離
• 日志存儲：使用Clickhouse中的兩種引擎數據表和物化視圖
• 日志管理：開源的Mogo系統，能夠查詢日志，設置日志索引，設置LogCollector配置，設置Clickhouse表，設置報警等

以下我們將按照這四大部分，闡述其中的架構原理。

三、日志采集

1、采集方式

Kubernetes容器內日志收集的方式通常有以下三種方案。

• DaemonSet方式采集：在每個node節點上部署LogCollector，并將宿主機的目錄掛載為容器的日志目錄，LogCollector讀取日志內容，采集到日志中心。
• 網絡方式采集：通過應用的日志SDK，直接將日志內容采集到日志中心 。
• SideCar方式采集：在每個pod內部署LogCollector，LogCollector只讀取這個pod內的日志內容，采集到日志中心。

以下是三種采集方式的優缺點：

我們主要采用DaemonSet方式和網絡方式采集日志。DaemonSet方式用于ingress、應用日志的采集，網絡方式用于大數據日志的采集。以下我們主要介紹下DeamonSet方式的采集方式。

2、日志輸出

從上面的介紹中可以看到，我們的DaemonSet會有兩種方式采集日志類型，一種是標準輸出，一種是文件。

引用元乙的描述：雖然使用 Stdout 打印日志是 Docker 官方推薦的方式，但大家需要注意：這個推薦是基于容器只作為簡單應用的場景，實際的業務場景中我們還是建議大家盡可能使用文件的方式，主要的原因有以下幾點：

• Stdout 性能問題，從應用輸出 stdout 到服務端，中間會經過好幾個流程（例如普遍使用的JSONLogDriver）：應用 stdout -> DockerEngine -> LogDriver -> 序列化成 JSON -> 保存到文件 -> Agent 采集文件 -> 解析 JSON -> 上傳服務端。整個流程相比文件的額外開銷要多很多，在壓測時，每秒 10 萬行日志輸出就會額外占用 DockerEngine 1 個 CPU 核；
• Stdout 不支持分類，即所有的輸出都混在一個流中，無法像文件一樣分類輸出，通常一個應用中有 AccessLog、ErrorLog、InterfaceLog（調用外部接口的日志）、TraceLog 等，而這些日志的格式、用途不一，如果混在同一個流中將很難采集和分析；
• Stdout 只支持容器的主程序輸出，如果是 daemon/fork 方式運行的程序將無法使用 stdout；
• 文件的 Dump 方式支持各種策略，例如同步/異步寫入、緩存大小、文件輪轉策略、壓縮策略、清除策略等，相對更加靈活。

從這個描述中，我們可以看出在docker中輸出文件再采集到日志中心是一個更好的實踐。所有日志采集工具都支持采集文件日志方式，但是我們在配置日志采集規則的時候，發現開源的一些日志采集工具，例如fluentbit、filebeat在DaemonSet部署下采集文件日志是不支持追加例如pod、namespace、container_name、container_id等label信息，并且也無法通過這些label做些定制化的日志采集。

基于無法追加label信息的原因，我們暫時放棄了DeamonSet部署下文件日志采集方式，采用的是基于DeamonSet部署下標準輸出的采集方式。

3、日志目錄

以下列舉了日志目錄的基本情況。

因為我們采集日志是使用的標準輸出模式，所以根據上表我們的LogCollector只需要掛載/var/log，/var/lib/docker/containers兩個目錄。

1）標準輸出日志目錄

應用的標準輸出日志存儲在/var/log/containers目錄下，文件名是按照K8S日志規范生成的。這里以nginx-ingress的日志作為一個示例。我們通過ls /var/log/containers/ | grep nginx-ingress指令，可以看到nginx-ingress的文件名。

nginx-ingress-controller-mt2wx_kube-system_nginx-ingress-controller-be3741043eca1621ec4415fd87546b1beb29480ac74ab1cdd9f52003cf4abf0a.log

我們參照K8S日志的規范：/var/log/containers/%{DATA:pod_name}_%{DATA:namespace}_%{GREEDYDATA:container_name}-%{DATA:container_id}.log。可以將nginx-ingress日志解析為：

• pod_name：nginx-ingress-controller-mt2w
• namespace：kube-system
• container_name：nginx-ingress-controller
• container_id：be3741043eca1621ec4415fd87546b1beb29480ac74ab1cdd9f52003cf4abf0a

通過以上的日志解析信息，我們的LogCollector就可以很方便地追加pod、namespace、container_name、container_id的信息。

2）容器信息目錄

應用的容器信息存儲在/var/lib/docker/containers目錄下，目錄下的每一個文件夾為容器ID，我們可以通過cat config.v2.json獲取應用的docker基本信息。

4、LogCollector采集日志

1）配置

我們LogCollector采用的是fluent-bit，該工具是cncf旗下的，能夠更好地與云原生相結合。通過Mogo系統可以選擇Kubernetes集群，很方便地設置fluent-bit configmap的配置規則。

2）數據結構

fluent-bit的默認采集數據結構

• @timestamp字段：string or float，用于記錄采集日志的時間
• log字段：string，用于記錄日志的完整內容

Clickhouse如果使用@timestamp的時候，因為里面有@特殊字符，會處理得有問題。所以我們在處理fluent-bit的采集數據結構，會做一些映射關系，并且規定雙下劃線為Mogo系統日志索引，避免和業務日志的索引沖突。

• _time_字段：string or float，用于記錄采集日志的時間
• _log_字段：string，用于記錄日志的完整內容

例如你的日志記錄的是{"id":1}，那么實際fluent-bit采集的日志會是{"_time_":"2022-01-15...","_log_":"{\"id\":1}" 該日志結構會直接寫入到kafka中，Mogo系統會根據這兩個字段_time_、_log_設置clickhouse中的數據表。

3）采集

如果我們要采集ingress日志，我們需要在input配置里，設置ingress的日志目錄，fluent-bit會把ingress日志采集到內存里

然后我們在filter配置里，將log改寫為_log_

然后我們在ouput配置里，將追加的日志采集時間設置為_time_，設置好日志寫入的kafka borkers和kafka topics，那么fluent-bit里內存的日志就會寫入到kafka中

日志寫入到Kafka中_log_需要為json，如果你的應用寫入的日志不是json，那么你就需要根據fluent-bit的parser文檔，調整你的日志寫入的數據結構：https://docs.fluentbit.io/manual/pipeline/filters/parser

四、日志傳輸

Kafka主要用于日志傳輸。上文說到我們使用fluent-bit采集日志的默認數據結構，在下圖kafka工具中我們可以看到日志采集的內容。

在日志采集過程中，會由于不用業務日志字段不一致，解析方式是不一樣的。所以我們在日志傳輸階段，需要將不同數據結構的日志，創建不同的Clickhouse表，映射到Kafka不同的Topic。這里以ingress為例，那么我們在Clickhouse中需要創建一個ingress_stdout_stream的Kafka引擎表，然后映射到Kafka的ingress-stdout Topic里。

五、日志存儲

我們會使用三種表，用于存儲一種業務類型的日志。

1、Kafka引擎表

將數據從Kafka采集到Clickhouse的ingress_stdout_stream數據表中。

create table logger.ingress_stdout_stream
(
  _source_ String,
  _pod_name_ String,
  _namespace_ String,
  _node_name_ String,
  _container_name_ String,
  _cluster_ String,
  _log_agent_ String,
  _node_ip_ String,
  _time_ Float64,
  _log_ String
)
engine = Kafka SETTINGS kafka_broker_list = 'kafka:9092', kafka_topic_list = 'ingress-stdout', kafka_group_name = 'logger_ingress_stdout', kafka_format = 'JSONEachRow', kafka_num_consumers = 1;

2、物化視圖

將數據從ingress_stdout_stream數據表讀取出來，_log_根據Mogo配置的索引，提取字段再寫入到ingress_stdout結果表里。

CREATE MATERIALIZED VIEW logger.ingress_stdout_view TO logger.ingress_stdout AS
SELECT
    toDateTime(toInt64(_time_)) AS _time_second_,
fromUnixTimestamp64Nano(toInt64(_time_*1000000000),'Asia/Shanghai') AS _time_nanosecond_,
  _pod_name_,
  _namespace_,
  _node_name_,
  _container_name_,
  _cluster_,
  _log_agent_,
  _node_ip_,
  _source_,
  _log_ AS _raw_log_,JSONExtractInt(_log_, 'status') AS status,JSONExtractString(_log_, 'url') AS url
  FROM logger.ingress_stdout_stream where 1=1;

3、結果表

存儲最終的數據

create table logger.ingress_stdout
(
  _time_second_ DateTime,
  _time_nanosecond_ DateTime64(9, 'Asia/Shanghai'),
  _source_ String,
  _cluster_ String,
  _log_agent_ String,
  _namespace_ String,
  _node_name_ String,
  _node_ip_ String,
  _container_name_ String,
  _pod_name_ String,
  _raw_log_ String,
  status Nullable(Int64),
  url Nullable(String),
)
engine = MergeTree PARTITION BY toYYYYMMDD(_time_second_)
ORDER BY _time_second_
TTL toDateTime(_time_second_) + INTERVAL 7 DAY
SETTINGS index_granularity = 8192;

六、總結流程

1、日志會通過fluent-bit的規則采集到kafka，在這里我們會將日志采集到兩個字段里。

_time_字段用于存儲fluent-bit采集的時間

_log_字段用于存放原始日志

2、通過mogo，在clickhouse里設置了三個表。

app_stdout_stream：將數據從Kafka采集到Clickhouse的Kafka引擎表

app_stdout_view：視圖表用于存放mogo設置的索引規則

app_stdout：根據app_stdout_view索引解析規則，消費app_stdout_stream里的數據，存放于app_stdout結果表中

3、最后mogo的UI界面，根據app_stdout的數據，查詢日志信息

七、Mogo界面展示

1、查詢日志界面

2、設置日志采集配置界面

以上文檔描述是針對石墨Kubernetes的日志采集。