摘要：在Kubernetes服務(wù)化垒在、日志處理實(shí)時(shí)化以及日志集中式存儲(chǔ)趨勢(shì)下，Kubernetes日志處理上也遇到的新挑戰(zhàn)扔亥，包括：容器動(dòng)態(tài)采集场躯、大流量性能瓶頸、日志路由管理等問(wèn)題旅挤。本文介紹了“Logtail + 日志服務(wù) + 生態(tài)”架構(gòu)踢关，介紹了：Logtail客戶端在Kubernetes日志采集場(chǎng)景下的優(yōu)勢(shì)；日志服務(wù)作為基礎(chǔ)設(shè)施一站式解決實(shí)時(shí)讀寫粘茄、HTAP兩大日志強(qiáng)需求签舞；日志服務(wù)數(shù)據(jù)的開放性以及與云產(chǎn)品瘪菌、開源社區(qū)相結(jié)合，在實(shí)時(shí)計(jì)算屹培、可視化、采集上為用戶提供的豐富選擇蓄诽。
Kubernetes日志處理的趨勢(shì)與挑戰(zhàn)
Kubernetes的serveless化
Kubernetes容器技術(shù)促進(jìn)了技術(shù)棧的去耦合仑氛，通過(guò)引入棧的分層使得開發(fā)者可以更加關(guān)注自身的應(yīng)用程序和業(yè)務(wù)場(chǎng)景锯岖。從Kubernetes本身來(lái)看出吹，這個(gè)技術(shù)解耦也在更進(jìn)一步發(fā)展捶牢，容器化的一個(gè)發(fā)展的趨勢(shì)是：這些容器都將會(huì)在無(wú)服務(wù)器的基礎(chǔ)設(shè)施上運(yùn)行秋麸。
談到基礎(chǔ)設(shè)施灸蟆，首先可以聯(lián)想到云，目前在AWS孽水、阿里云女气、Azure的云上都提供了無(wú)服務(wù)器化的Kubernetes服務(wù)缘滥。在serverless Kubernetes上朝扼，我們將不再關(guān)心集群與機(jī)器擎颖，只需要聲明容器的鏡像、CPU驮俗、內(nèi)存王凑、對(duì)外服務(wù)方式就可以啟動(dòng)應(yīng)用索烹。
如上圖，左右兩邊分別是經(jīng)典Kubernetes每篷、serverless Kubernetes的形態(tài)焦读。在從左向右發(fā)展的過(guò)程中仑嗅，日志采集也變得復(fù)雜：
在一個(gè)Kubernetes node上仓技，可能會(huì)運(yùn)行更大規(guī)模量級(jí)的pod脖捻，每個(gè)pod上都可能有日志或監(jiān)控指標(biāo)采集需求地沮，意味著單node上的日志量會(huì)更大摩疑。
一個(gè)Kubernetes node上可能會(huì)運(yùn)行更多種類的pod雷袋，日志采集來(lái)源變得多樣化片排，各類日志的管理率寡、打標(biāo)需求越來(lái)越迫切冶共。
日志實(shí)時(shí)性需求越來(lái)越強(qiáng)
首先要強(qiáng)調(diào)的是捅僵，并非所有日志都需要實(shí)時(shí)處理庙楚，當(dāng)前很多"T+1"時(shí)效的日志交付依然非常重要馒闷，比如：做BI可能天級(jí)別延遲足夠，ctr預(yù)估可能1小時(shí)延遲的日志也可以捺疼。
但是啤呼，在有些場(chǎng)景下翅敌，秒級(jí)或更高時(shí)效性的日志是必備前提條件哼御，下圖橫坐標(biāo)從左到右的對(duì)比展示了數(shù)據(jù)實(shí)時(shí)性對(duì)于決策的重要性恋昼。
舉兩個(gè)場(chǎng)景來(lái)談一下實(shí)時(shí)日志對(duì)于決策的重要性：
告警處理液肌。搞devops同學(xué)都深有體會(huì)嗦哆，線上問(wèn)題越早發(fā)現(xiàn)老速、越早處理我們就可以更淡定橘券，處理時(shí)間拖得久了故障就可能跟著升級(jí)旁舰。實(shí)時(shí)日志幫助我們更快發(fā)現(xiàn)系統(tǒng)的異常指標(biāo)毯焕，觸發(fā)應(yīng)急處理流程纳猫。
AIOps续担。目前已經(jīng)有一些算法基于日志做異常點(diǎn)檢測(cè)物遇、趨勢(shì)預(yù)測(cè)：根據(jù)日志的pattern變化態(tài)勢(shì)發(fā)現(xiàn)正常和異常情況下各類型日志出現(xiàn)的分布询兴；針對(duì)IT業(yè)務(wù)系統(tǒng)诗舰，給定參數(shù)因子眶根、變量對(duì)諸如硬盤故障等問(wèn)題進(jìn)行建模属百，加以實(shí)時(shí)日志來(lái)實(shí)現(xiàn)故障事件預(yù)警族扰。
日志的集中式存儲(chǔ)
日志來(lái)源有很多怒竿，常見的有：文件耕驰，數(shù)據(jù)庫(kù)audit log耍属，網(wǎng)絡(luò)數(shù)據(jù)包等等。并且兢哭，針對(duì)同一份數(shù)據(jù)迟螺，對(duì)于不同的使用者（例如：開發(fā)矩父、運(yùn)維窍株、運(yùn)營(yíng)等）球订、不同的用途（例如：告警冒滩、數(shù)據(jù)清洗开睡、實(shí)時(shí)檢索、批量計(jì)算等）梁呈，存在使用多種方式重復(fù)消費(fèi)日志數(shù)據(jù)的情況。
在日志數(shù)據(jù)的系統(tǒng)集成上醋虏，從數(shù)據(jù)源到存儲(chǔ)節(jié)點(diǎn)再到計(jì)算節(jié)點(diǎn)颈嚼，可以定義為一個(gè)pipeline。如下圖艰匙，從上到下的變化是：日志處理正在從O(N^2) pipelines向O(N) pipelines演進(jìn)署驻。
在過(guò)去旺上，各類日志用特定的方式來(lái)存儲(chǔ)宣吱，采集到計(jì)算鏈路不具被通用和復(fù)用條件征候，pipeline非常復(fù)雜倍奢，數(shù)據(jù)存儲(chǔ)也可能重復(fù)冗余卒煞。當(dāng)前日志數(shù)據(jù)集成上畔裕，通過(guò)依賴一個(gè)中樞（Hub）來(lái)簡(jiǎn)化日志架構(gòu)的復(fù)雜度、優(yōu)化存儲(chǔ)利用率乍构。這個(gè)基礎(chǔ)設(shè)施級(jí)別的Hub非常重要岂丘，需要支持實(shí)時(shí)pub/sub奥帘，能夠處理高并發(fā)的寫入寨蹋、讀取請(qǐng)求已旧，提供海量的存儲(chǔ)空間运褪。
Kubernetes日志采集方案的演進(jìn)
前面一節(jié)總結(jié)了Kubernetes日志處理上的趨勢(shì)吐句，那么家下來(lái)會(huì)盤點(diǎn)一下Kubernetes上幾種常見日志采集的做法嗦枢。
命令行工具
Kubernetes集群上要看日志文虏，最基礎(chǔ)的做法就是登機(jī)器氧秘，運(yùn)行kubectl logs就可以看到容器寫出的stdout/stderr丸相。
基礎(chǔ)的方案沒(méi)法滿足更多需求：
只支持標(biāo)準(zhǔn)輸出
數(shù)據(jù)不能持久化
除了看做不了別的事
節(jié)點(diǎn)日志文件落盤
在Kubernetes node維度去處理日志，docker engine將容器的stdout/stderr重定向到logdriver座硕，并且在logdriver上可以配置多種形式去持久化日志华匾，比如以json格式保存文件到本地存儲(chǔ)。
和kubectl命令行相比有鹿，更進(jìn)一步是把日志做到了本地化存儲(chǔ)印颤∧昃郑可以用grep/awk這些Linux工具去分析日志文件內(nèi)容矢否。
這個(gè)方案相當(dāng)于回到了物理機(jī)時(shí)代僵朗，但仍然存在很多問(wèn)題沒(méi)有解決：
基于docker engine和logdriver，除了默認(rèn)的標(biāo)準(zhǔn)輸出粪薛，不支持應(yīng)用程序的日志
日志文件rotate多次或者Kubernetes node被驅(qū)逐后數(shù)據(jù)會(huì)丟失
沒(méi)法跟開源社區(qū)搏恤、云上的數(shù)據(jù)分析工具集成
基于這個(gè)方案的一個(gè)進(jìn)化版本是在node上部署日志采集客戶端藤巢，將日志上傳到中心化日志存儲(chǔ)的設(shè)施上去掂咒。目前這也是推薦的模式俏扩，會(huì)在下一節(jié)再做介紹录淡。
sidecar模式日志客戶端采集
一種伴生模式嫉戚，在一個(gè)pod內(nèi)，除了業(yè)務(wù)容器外帆啃，還有一個(gè)日志客戶端容器努潘。這個(gè)日志客戶端容器負(fù)責(zé)采集pod內(nèi)容器的標(biāo)準(zhǔn)輸出疯坤、文件压怠、metric數(shù)據(jù)上報(bào)服務(wù)端菌瘫。
這個(gè)方案解決了日志持久化存儲(chǔ)等基本的功能需求，但兩個(gè)地方有待提升：
一個(gè)節(jié)點(diǎn)上如果運(yùn)行了N個(gè)pod忿等，就意味著會(huì)同時(shí)運(yùn)行著N個(gè)日志客戶端，造成CPU虚汛、內(nèi)存卷哩、端口等資源的浪費(fèi)冷溶。
Kubernetes下需要為每個(gè)pod單獨(dú)進(jìn)行采集配置（采集日志目錄逞频，采集規(guī)則苗胀，存儲(chǔ)目標(biāo)等）歌亲，不易維護(hù)陷揪。
日志直寫
直寫方案一般是通過(guò)修改應(yīng)用程序本身來(lái)實(shí)現(xiàn)悍缠，在程序內(nèi)部組織幾條日志扮休，然后調(diào)用類似HTTP API將數(shù)據(jù)發(fā)送到日志存儲(chǔ)后端玷坠。
帶來(lái)的好處是：日志格式可以按需DIY八堡，日志源和目標(biāo)的路由可以任意配置。
也可以看到使用上的限制：
侵入代碼會(huì)對(duì)業(yè)務(wù)改造有直接的依賴挂谍，推動(dòng)業(yè)務(wù)改造一般比較漫長(zhǎng)口叙。
應(yīng)用程序在發(fā)數(shù)據(jù)到遠(yuǎn)端遇到異常（比如網(wǎng)絡(luò)抖動(dòng)妄田，接收服務(wù)端內(nèi)部錯(cuò)誤）時(shí)，需要在有限內(nèi)存中緩存數(shù)據(jù)做重試启具，最終還是有概率造成數(shù)據(jù)丟失富纸。
Kubernetes日志處理架構(gòu)
來(lái)自社區(qū)的架構(gòu)
目前見到比較多的架構(gòu)中晓褪，采集工作通過(guò)每個(gè)Kubernetes node上安裝一個(gè)日志客戶端完成：
Kubernetes官方推薦的是treasure data公司開源的fluentd勤庐，它的性能現(xiàn)愉镰、插件豐富度比較均衡丈探。
社區(qū)有也不少在使用elastic公司開源的beats系列，性能不錯(cuò)拔莱，插件支持略少一些碗降。針對(duì)一種數(shù)據(jù)需要部署特定的客戶端程序，比如文本文件通過(guò)filebeats來(lái)采集塘秦。
也有些架構(gòu)在使用logstash讼渊，ETL支持非常豐富，但是JRuby實(shí)現(xiàn)導(dǎo)致性能很差尊剔。
日志客戶端把數(shù)據(jù)格式化好之后用指定協(xié)議上傳到存儲(chǔ)端爪幻，常見的選擇有Kafka。Kafka支持實(shí)時(shí)訂閱、重復(fù)消費(fèi)船庇，后期可以再根據(jù)業(yè)務(wù)需要把數(shù)據(jù)同步到其它系統(tǒng)去，比如：業(yè)務(wù)日志到Elastic Search做關(guān)鍵詞查詢姓蜂，結(jié)合Kibana做日志可視化分析束莫；金融場(chǎng)景日志要長(zhǎng)期留存饿敲，可以選擇投遞Kafka數(shù)據(jù)到AWS S3這樣的高性價(jià)比存儲(chǔ)上暑脆。
這個(gè)架構(gòu)看起來(lái)簡(jiǎn)潔有效，但在Kubernetes下距離完美還有些細(xì)節(jié)問(wèn)題要解決：
首先鲤孵，這是一個(gè)標(biāo)準(zhǔn)的節(jié)點(diǎn)級(jí)采集方案，Kubernetes下fluentd等客戶端的程序部署、采集配置管理是個(gè)難題，在日志采集路由幌氮、數(shù)據(jù)打標(biāo)慢洋、客戶端配置等問(wèn)題沒(méi)有針對(duì)性優(yōu)化太防。
其次酿愧，在日志的消費(fèi)上庞钢，雖然Kafka的軟件生態(tài)足夠豐富风皿，但是仍然需要專業(yè)人員來(lái)維護(hù)鲁僚，要做業(yè)務(wù)規(guī)劃执虹、考慮機(jī)器水位盖灸、處理硬件損壞徙垫。如果要查詢分析日志吴旋，還需要有對(duì)Elastic Search系統(tǒng)有足夠了解褂傀。我們知道在PB級(jí)數(shù)據(jù)場(chǎng)景下叠国，分布式系統(tǒng)的性能、運(yùn)維問(wèn)題開始凸顯晴楔，而駕馭這些開源系統(tǒng)需要很強(qiáng)的專業(yè)能力顽决。
日志服務(wù)的Kubernetes日志架構(gòu)實(shí)踐
我們提出基于阿里云日志服務(wù)的Kubernetes日志處理架構(gòu)蚓耽，用以補(bǔ)充社區(qū)的方案，來(lái)嘗試解決Kubernetes場(chǎng)景下日志處理的一些細(xì)節(jié)體驗(yàn)問(wèn)題敲长。這個(gè)架構(gòu)可以總結(jié)為：“Logtail + 日志服務(wù) + 生態(tài)”遂填。
首先哆窿，Logtail是日志服務(wù)的數(shù)據(jù)采集客戶端缩搅，針對(duì)Kubernetes場(chǎng)景下的一些痛點(diǎn)做了針對(duì)性設(shè)計(jì)筑累。也是按照Kubernetes官方建議的方式嘴脾，在每個(gè)node上只部署一個(gè)Logtail客戶端韵洋，負(fù)責(zé)這個(gè)node上所有的pod日志采集齿桃。
其次，針對(duì)關(guān)鍵詞搜索和SQL統(tǒng)計(jì)這兩個(gè)基本的日志需求：日志服務(wù)提供了基礎(chǔ)的LogHub功能炸茧，支持?jǐn)?shù)據(jù)的實(shí)時(shí)寫入偶翅、訂閱秦爆；在LogHub存儲(chǔ)的基礎(chǔ)上桐早，可以選擇開啟數(shù)據(jù)的索引分析功能侠驯，開啟索引后可以支持日志關(guān)鍵詞查詢以及SQL語(yǔ)法分析。
最后，日志服務(wù)的數(shù)據(jù)是開放的觉既。索引數(shù)據(jù)可以通過(guò)JDBC協(xié)議與第三方系統(tǒng)對(duì)接背亥，SQL查詢結(jié)果與諸如阿里云DataV盾戴、開源社區(qū)的Grafana系統(tǒng)很方便地集成；日志服務(wù)的高吞吐的實(shí)時(shí)讀寫能力支撐了與流計(jì)算系統(tǒng)的對(duì)接，spark streaming宪巨、blink、jstorm等流計(jì)算系統(tǒng)上都有connector支持；用戶還可以通過(guò)全托管的投遞功能把數(shù)據(jù)寫入到阿里云的對(duì)象存儲(chǔ)OSS，投遞支持行存（csv隆豹、json）、列存（parquet）格式茅逮，這些數(shù)據(jù)可以用作長(zhǎng)期低成本備份璃赡，或者是通過(guò)“OSS存儲(chǔ)+E-MapReduce計(jì)算”架構(gòu)來(lái)實(shí)現(xiàn)數(shù)據(jù)倉(cāng)庫(kù)判哥。
日志服務(wù)的優(yōu)勢(shì)
從四個(gè)點(diǎn)上來(lái)描述日志服務(wù)的特點(diǎn)：
在可靠性和穩(wěn)定性上，它支撐了阿里集團(tuán)和螞蟻金服多次雙十一和雙十二的大促碉考。
在功能上一站式覆蓋了Kafka + ElasticSearch大部分場(chǎng)景塌计。
作為云上的基礎(chǔ)設(shè)施可以方便地實(shí)現(xiàn)彈性伸縮，對(duì)于用戶來(lái)說(shuō)豆励，大促時(shí)不需要操心買機(jī)器擴(kuò)容夺荒、每天壞上數(shù)十個(gè)盤需要維修等問(wèn)題。
日志服務(wù)也同樣具備云的0預(yù)付成本良蒸、按需付費(fèi)的特點(diǎn)技扼，并且目前每月有500MB的免費(fèi)額度。
回顧第一節(jié)中提到的Kubernetes日志處理的趨勢(shì)與挑戰(zhàn)嫩痰，這里總結(jié)了日志服務(wù)的三個(gè)優(yōu)勢(shì)：
作為日志基礎(chǔ)設(shè)施剿吻，解決了各種日志數(shù)據(jù)集中化存儲(chǔ)問(wèn)題。
服務(wù)化的產(chǎn)品帶給用戶更多的易用性串纺，與Kubernetes在serverless的目標(biāo)上也是契合的丽旅。
功能上同時(shí)滿足實(shí)時(shí)讀寫、HTAP需求纺棺，簡(jiǎn)化了日志處理的流程與架構(gòu)榄笙。
日志服務(wù)結(jié)合社區(qū)力量進(jìn)行Kubernetes日志分析
Kubernetes源自社區(qū)，使用開源軟件進(jìn)行Kubernetes日志的處理也是一些場(chǎng)景下的正確選擇祷蝌。
日志服務(wù)保證數(shù)據(jù)的開放性茅撞，與開源社區(qū)在采集、計(jì)算巨朦、可視化等方面進(jìn)行對(duì)接米丘，幫助用戶享受到社區(qū)技術(shù)成果。
如下圖糊啡，舉一個(gè)簡(jiǎn)單的例子：使用流計(jì)算引擎flink實(shí)時(shí)消費(fèi)日志服務(wù)的日志庫(kù)數(shù)據(jù)拄查，源日志庫(kù)的shard并發(fā)與flink task實(shí)現(xiàn)動(dòng)態(tài)負(fù)載均衡，在完成與MySQL的meta完成數(shù)據(jù)join加工后棚蓄，再通過(guò)connector流式寫入另一個(gè)日志服務(wù)日志庫(kù)做可視化查詢堕扶。
Logtail在Kubernetes日志采集場(chǎng)景下的設(shè)計(jì)
在本文第二節(jié)我們回顧了Kubernetes日志采集方案演進(jìn)過(guò)程中遇到的問(wèn)題，第三節(jié)介紹了基于阿里云日志服務(wù)的功能梭依、生態(tài)稍算。在這一節(jié)會(huì)重點(diǎn)對(duì)Logtail采集端的設(shè)計(jì)和優(yōu)化工作做一些介紹，細(xì)數(shù)Logtail如何解決Kubernetes日志采集上的痛點(diǎn)睛挚。
Kubernetes采集的難點(diǎn)
采集目標(biāo)多樣化
容器stdout/stderr
容器應(yīng)用日志
宿主機(jī)日志
開放協(xié)議：Syslog邪蛔、HTTP等
采集可靠性
性能上需要滿足單node上大流量日志場(chǎng)景，同時(shí)兼顧采集的實(shí)時(shí)性
解決容器日志易失性問(wèn)題
在各種情況下盡量保證采集數(shù)據(jù)的完整性
動(dòng)態(tài)伸縮帶來(lái)的挑戰(zhàn)
容器擴(kuò)扎狱、縮容對(duì)自動(dòng)發(fā)現(xiàn)的要求
降低Kubernetes部署的復(fù)雜度
采集配置易用性
采集配置怎么部署侧到、管理
不同用途的pod日志需要分門別類存儲(chǔ)勃教，數(shù)據(jù)路由怎么去管理
Logtail高可靠采集
Logtail支持至少at-least-once采集的語(yǔ)義保證，通過(guò)文件和內(nèi)存兩種級(jí)別的checkpoint機(jī)制來(lái)保證在容器重啟場(chǎng)景下的斷點(diǎn)續(xù)傳匠抗。
日志采集過(guò)程中可能遇到各種各樣的來(lái)自系統(tǒng)或用戶配置的錯(cuò)誤故源，例如日志格式化解析出錯(cuò)時(shí)我們需要及時(shí)調(diào)整解析規(guī)則。Logtail提供了采集監(jiān)控功能汞贸，可以將異常和統(tǒng)計(jì)信息上報(bào)日志庫(kù)并支持查詢绳军、告警。
優(yōu)化計(jì)算性能解決單節(jié)點(diǎn)大規(guī)模日志采集問(wèn)題矢腻，Logtail在不做日志字段格式化的情況（singleline模式）下做到單cpu核100MB/s左右的處理性能门驾。針對(duì)網(wǎng)絡(luò)發(fā)送的慢IO操作，客戶端將多條日志batch commit到服務(wù)端做持久化多柑，兼顧了采集的實(shí)時(shí)性與高吞吐能力奶是。
在阿里集團(tuán)內(nèi)部，Logtail目前有百萬(wàn)級(jí)規(guī)模的客戶端部署竣灌，穩(wěn)定性是不錯(cuò)的聂沙。
豐富的數(shù)據(jù)源支持
應(yīng)對(duì)Kubernetes環(huán)境下復(fù)雜多樣的采集需求，Logtail在采集源頭上可以支持：stdout/stderr初嘹，容器及汉、宿主機(jī)日志文件，syslog屯烦、lumberjack等開放協(xié)議數(shù)據(jù)采集坷随。
將一條日志按照語(yǔ)義切分為多個(gè)字段就可以得到多個(gè)key-value對(duì)，由此將一條日志映射到table模型上漫贞，這個(gè)工作使得在接下來(lái)的日志分析過(guò)程中事半功倍甸箱。Logtail支持以下一些日志格式化方式：
多行解析育叁。比如Java stack trace日志是由多個(gè)自然行組成的迅脐，通過(guò)行首正則表達(dá)式的設(shè)置來(lái)實(shí)現(xiàn)日志按邏輯行切分。
自描述解析豪嗽。支持csv谴蔑、json等格式，自動(dòng)提取出日志字段龟梦。
通過(guò)正則隐锭、自定義插件方式滿足更多特定需求。
對(duì)于一些典型的日志提供內(nèi)置解析規(guī)則计贰。比如钦睡，用戶只需要在web控制臺(tái)上選擇日志類別是Nginx訪問(wèn)日志，Logtail就可以自動(dòng)把一條訪問(wèn)日志按照Nginx的log format配置抽取出client_ip躁倒、uri等等字段荞怒。
應(yīng)對(duì)節(jié)點(diǎn)級(jí)容器動(dòng)態(tài)伸縮
容器天生會(huì)做常態(tài)化擴(kuò)容洒琢、縮容，新擴(kuò)容的容器日志需要及時(shí)被采集否則就會(huì)丟失褐桌，這要求客戶端有能力動(dòng)態(tài)感知到采集源衰抑，且部署、配置需要做到足夠的易用性荧嵌。Logtail從以下兩個(gè)維度來(lái)解決數(shù)據(jù)采集的完整性問(wèn)題：
部署
通過(guò)DaemonSet方式來(lái)快速部署Logtail到一個(gè)Kubernetes node上呛踊，一條指令就可以完成，與K8S應(yīng)用發(fā)布集成也很方便啦撮。
Logtail客戶端部署到node上以后谭网，通過(guò)domain socket與docker engine通信來(lái)處理該節(jié)點(diǎn)上的容器動(dòng)態(tài)采集。增量掃描可以及時(shí)地發(fā)現(xiàn)node上的容器變化赃春，再加上定期全量掃面機(jī)制來(lái)保證不會(huì)丟失掉任何一個(gè)容器更改事件蜻底，這個(gè)雙重保障的設(shè)計(jì)使得在客戶端上可以及時(shí)、完整發(fā)現(xiàn)候選的監(jiān)控目標(biāo)聘鳞。
采集配置管理
Logtail從設(shè)計(jì)之初就選擇了服務(wù)端集中式采集配置管理薄辅，保證采集指令可以從服務(wù)端更高效地傳達(dá)給客戶端。這個(gè)配置管理可以抽象為"機(jī)器組+采集配置"模型抠璃，對(duì)于一個(gè)采集配置站楚，在機(jī)器組內(nèi)的Logtail實(shí)例可以即時(shí)獲取到機(jī)器組上所關(guān)聯(lián)的采集配置，去開啟采集任務(wù)搏嗡。
針對(duì)Kubernetes場(chǎng)景窿春，Logtail設(shè)計(jì)了自定義標(biāo)識(shí)方式來(lái)管理機(jī)器。一類pod可以聲明一個(gè)固定的機(jī)器標(biāo)識(shí)采盒，Logtail使用這個(gè)機(jī)器標(biāo)識(shí)向服務(wù)端匯報(bào)心跳旧乞，同時(shí)機(jī)器組使用這個(gè)自定義標(biāo)識(shí)來(lái)管理Logtail實(shí)例。當(dāng)Kubernetes節(jié)點(diǎn)擴(kuò)容時(shí)磅氨，Logtail上報(bào)pod對(duì)應(yīng)的自定義機(jī)器標(biāo)識(shí)到服務(wù)端尺栖，服務(wù)端就會(huì)把這個(gè)機(jī)器組上的掛載的采集配置下發(fā)給Logtail。目前在開源采集客戶端上烦租，常見的做法是使用機(jī)器ip或hostname來(lái)標(biāo)識(shí)客戶端延赌，這樣在容器伸縮時(shí)，需要及時(shí)去增刪機(jī)器組內(nèi)的機(jī)器ip或hostname叉橱，否則就會(huì)導(dǎo)致數(shù)據(jù)采集的缺失挫以，需要復(fù)雜的擴(kuò)容流程保證。
解決采集配置管理難題
Logtail提供兩種采集配置的管理方式窃祝，用戶根據(jù)自己的喜好任選來(lái)操作：
CRD掐松。與Kubernetes生態(tài)深度集成，通過(guò)在客戶端上事件監(jiān)聽可以聯(lián)動(dòng)創(chuàng)建日志服務(wù)上的日志庫(kù)、采集配置大磺、機(jī)器組等資源泻仙。
WEB控制臺(tái)。上手快量没，可視化方式來(lái)配置日志格式化解析規(guī)則玉转，通過(guò)wizard完成采集配置與機(jī)器組的關(guān)聯(lián)。用戶只需要按照習(xí)慣來(lái)設(shè)置一個(gè)容器的日志目錄殴蹄，Logtail在上開啟采集時(shí)會(huì)自動(dòng)渲染成宿主機(jī)上的實(shí)際日志目錄究抓。
我們將日志從源到目標(biāo)（日志庫(kù)）定義為一個(gè)采集路由。使用傳統(tǒng)方案實(shí)現(xiàn)個(gè)性化采集路由功能非常麻煩袭灯，需要在客戶端本地配置刺下，每個(gè)pod容器寫死這個(gè)采集路由，對(duì)于容器部署稽荧、管理會(huì)有強(qiáng)依賴橘茉。Logtail解決這個(gè)問(wèn)題的突破點(diǎn)是對(duì)環(huán)境變量的應(yīng)用，Kubernetes的env是由多個(gè)key-value組成姨丈，在部署容器時(shí)可以進(jìn)行env設(shè)置畅卓。Logtail的采集配置中設(shè)計(jì)了IncludeEnv和ExcludeEnv配置項(xiàng)，用于加入或排除采集源蟋恬。在下面的圖中翁潘，pod業(yè)務(wù)容器啟動(dòng)時(shí)設(shè)置log_type環(huán)境變量，同時(shí)Logtail采集配置中定義了IncludeEnv: log_type=nginx_access_log歼争，來(lái)指定收集nginx類用途的pod日志到特定日志庫(kù)拜马。
所有在Kubernetes上采集到的數(shù)據(jù)，Logtail都自動(dòng)進(jìn)行了pod/namesapce/contanier/image維度的打標(biāo)沐绒，方便后續(xù)的數(shù)據(jù)分析俩莽。
日志上下文查詢的設(shè)計(jì)
上下文查詢是指：給定一條日志，查看該日志在原機(jī)器乔遮、文件位置的上一條或下一條日志扮超，類似于Linux上的grep -A -B。
在devops等一些場(chǎng)景下申眼，邏輯性異常需要這個(gè)時(shí)序來(lái)輔助定位瞒津，有了上下文查看功能會(huì)事半功倍蝉衣。然后在分布式系統(tǒng)下括尸，在源和目標(biāo)上都很難保證原先的日志順序：
在采集客戶端層面，Kubernetes可能產(chǎn)生大量日志病毡，日志采集軟件需要利用機(jī)器的多個(gè)cpu核心解析濒翻、預(yù)處理日志，并通過(guò)多線程并發(fā)或者單線程異步回調(diào)的方式處理網(wǎng)絡(luò)發(fā)送的慢IO問(wèn)題。這使得日志數(shù)據(jù)不能按照機(jī)器上的事件產(chǎn)生順序依次到達(dá)服務(wù)端有送。
在分布式系統(tǒng)的服務(wù)端層面淌喻，由于水平擴(kuò)展的多機(jī)負(fù)載均衡架構(gòu)，使得同一客戶端機(jī)器的日志會(huì)分散在多臺(tái)存儲(chǔ)節(jié)點(diǎn)上雀摘。在分散存儲(chǔ)的日志基礎(chǔ)上再恢復(fù)最初的順序是困難的裸删。
傳統(tǒng)上下文查詢方案，一般是根據(jù)日志到達(dá)服務(wù)端時(shí)間阵赠、日志業(yè)務(wù)時(shí)間字段做兩次排序涯塔。這在大數(shù)據(jù)場(chǎng)景下存在：排序性能問(wèn)題、時(shí)間精度不足問(wèn)題清蚀，無(wú)法真實(shí)還原事件的真實(shí)時(shí)序匕荸。
Logtail與日志服務(wù)（關(guān)鍵詞查詢功能）相結(jié)合來(lái)解決這個(gè)問(wèn)題：
一個(gè)容器文件的日志在采集上傳時(shí)，其數(shù)據(jù)包是由一批的多條日志組成枷邪，多條日志對(duì)應(yīng)特定文件的一個(gè)block榛搔，比如512KB。在這一個(gè)數(shù)據(jù)包的多條日志是按照源文件的日志序排列东揣，也就意味著某日志的下一條可能是在同一個(gè)數(shù)據(jù)包里也可能在下一個(gè)數(shù)據(jù)包里践惑。
Logtail在采集時(shí)會(huì)給這個(gè)數(shù)據(jù)包設(shè)置唯一的日志來(lái)源sourceId，并在上傳的數(shù)據(jù)包里設(shè)置包自增Id嘶卧，叫做packageID童本。每個(gè)package內(nèi)，任意一條日志擁有包內(nèi)的位移offset脸候。
雖然數(shù)據(jù)包在服務(wù)端后存儲(chǔ)可能是無(wú)序狀態(tài)穷娱，但日志服務(wù)有索引可以去精確seek指定sourceId和packageId的數(shù)據(jù)包。
當(dāng)我們指定容器A的序號(hào)2日志（source_id:A运沦，package_id:N泵额，offset:M）查看其下文時(shí)，先判斷日志在當(dāng)前數(shù)據(jù)包的offset是否為數(shù)據(jù)包的末尾（包的日志條數(shù)定義為L(zhǎng)携添，末尾的offset為L(zhǎng)-1）：如果offset M小于(L-1)嫁盲，則說(shuō)明它的下一條日志位置是：source_id:A，package_id:N烈掠，offset:M+1羞秤；而如果當(dāng)前日志是數(shù)據(jù)包的最后一條，則其下一條日志的位置是：source_id:A左敌，package_id:N+1瘾蛋，offset:0。
在大部分場(chǎng)景下矫限，利用關(guān)鍵詞隨機(jī)查詢獲取到的一個(gè)package哺哼，可以支持當(dāng)前包長(zhǎng)度L次數(shù)的上下文翻頁(yè)佩抹，在提升查詢性能同時(shí)也大大降低的后臺(tái)服務(wù)隨機(jī)IO的次數(shù)。
