查日志只有ES好使？那是你沒這樣用Clickhouse……
一、背景
石墨文檔全部應用部署在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?？梢詫ginx-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的日志采集。
