摘要：?今天谍婉，日志服務(wù)再次升級Kubernetes（k8s）的日志解決方案。1分鐘內(nèi)即可完成整個集群部署镀钓，支持動態(tài)擴容穗熬，提供采集宿主機日志、容器日志丁溅、容器stdout等所有數(shù)據(jù)源的一站式采集唤蔗。
背景
眾所周知，Docker很火唧瘾，Docker中Kubernetes（簡稱k8s）最火措译。相對物理機、VM饰序，Docker提供了更加簡單领虹、輕量、高性價比的部署與運維方法求豫；而k8s在Docker之上塌衰，更進一步提供了對管理基礎(chǔ)設(shè)施的抽象，形成了真正意義上的一站式部署與運維方案蝠嘉。
k8s提供了強有力工作調(diào)度最疆、水平擴展、健康監(jiān)測蚤告、維護高可用性等能力努酸，同時提供了網(wǎng)絡(luò)、文件系統(tǒng)的抽象與管理杜恰，所以對于已有應(yīng)用上k8s或者基于k8s部署應(yīng)用十分便捷获诈。但這里有一部分令開發(fā)和運維人員比較頭疼--日志采集仍源。
難點分析
基于VM或者物理機部署的應(yīng)用，日志采集相關(guān)技術(shù)都比較完善舔涎，有比較健全的Logstash笼踩、Fluentd、FileBeats等亡嫌。但在Docker中嚎于，尤其在k8s中，日志采集并沒有很好的解決方案挟冠，主要原因如下：
采集目標多：需要采集宿主機日志于购、容器內(nèi)日志、容器stdout知染。針對每種數(shù)據(jù)源都有對應(yīng)的采集軟件价涝，但缺乏一站式解決方案。
彈性伸縮難：k8s是一個分布式的集群持舆，服務(wù)、環(huán)境的彈性伸縮對于日志采集帶來了很大的困難伪窖，采集的動態(tài)性以及數(shù)據(jù)完整性是非常大的挑戰(zhàn)逸寓。
運維成本大：現(xiàn)有的方案只能使用多種軟件組合采集，各個軟件組裝起來的系統(tǒng)穩(wěn)定性難以保障覆山，且缺乏中心化的管理竹伸、配置、監(jiān)控手段簇宽，運維負擔(dān)巨大勋篓。
侵入性高：Docker Driver擴展需要修改底層引擎；一個Container對應(yīng)一個采集Agent又會產(chǎn)生資源競爭和浪費魏割。
采集性能低：正常情況下一個Docker Engine會運行數(shù)十個甚至數(shù)百個Container譬嚣，此時開源Agent日志采集性能以及資源消耗十分堪憂。
基于阿里巴巴多年來容器服務(wù)日志采集的經(jīng)驗積累钞它，并結(jié)合阿里云Kubernetes內(nèi)測以來廣大用戶的反饋與訴求拜银，今天，日志服務(wù)為k8s帶來真正意義上的一站式日志解決方案遭垛。
方案介紹
方案簡介
如上圖所示尼桶，我們只需要在Kubernetes集群中的每個節(jié)點上部署一個Logtail的容器，即可實現(xiàn)該節(jié)點上宿主機日志锯仪、容器日志泵督、容器stdout等所有數(shù)據(jù)源的一站式采集。我們針對k8s提供了DaemonSet部署模板庶喜，1分鐘內(nèi)即可完成整個集群部署小腊，并且后續(xù)集群動態(tài)伸縮無需對采集做任何二次部署救鲤。具體請參見使用方式章節(jié)。
日志服務(wù)客戶端Logtail目前已有百萬級部署溢豆，每天采集上萬應(yīng)用蜒简、數(shù)PB的數(shù)據(jù)，歷經(jīng)多次雙11漩仙、雙12考驗搓茬。相關(guān)技術(shù)分享可以參見文章：多租戶隔離技術(shù)+雙十一實戰(zhàn)效果，Polling + Inotify 組合下的日志保序采集方案队他。
依托阿里云日志服務(wù)強大的功能卷仑，對于采集到的日志數(shù)據(jù)，我們提供：
上下文查詢麸折，從茫茫數(shù)據(jù)中快速定位異常數(shù)據(jù)锡凝，并支持定位異常所在Container/Pod的上下文日志
實時的海量數(shù)據(jù)分析，1秒即可完成1億條數(shù)據(jù)的統(tǒng)計分析
自帶報表垢啼、告警功能窜锯，老板、開發(fā)芭析、運維全搞定
流計算對接：storm锚扎、flink、blink馁启、spark streaming等等都支持
外接可視化：Grafana驾孔、DataV輕松對接
日志歸檔投遞：支持投遞OSS歸檔存儲，也支持投遞MaxCompute進行離線分析
采集方案優(yōu)勢
關(guān)于日志服務(wù)整體的優(yōu)勢這里不再贅述惯疙，本文主要探討日志服務(wù)Kubernetes采集方案的相關(guān)優(yōu)勢翠勉。這里我們主要總結(jié)了以下幾點：
方案對比
相對Logstash、Fluentd主流日志采集方式霉颠，對比如下：
logtaillogstashfluentd
采集方式宿主機文件支持支持支持
container文件支持自動發(fā)現(xiàn)靜態(tài)采集靜態(tài)采集
container stdout支持自動發(fā)現(xiàn)插件擴展Docker driver
數(shù)據(jù)處理處理方式正則对碌、anchor、分隔符蒿偎、json任意組合插件擴展插件擴展
自動打標支持不支持k8s不支持k8s
過濾正則插件擴展插件擴展
配置自動更新支持手動加載支持
服務(wù)端配置支持Beta版本支持簡單功能輔助管理軟件擴展
性能采集性能極簡單核160M/s俭缓、正則20M/s單核2M/s左右單核3-5M/s
資源消耗平均CPU 2%、內(nèi)存 40M10倍以上性能消耗10倍以上性能消耗
可靠性數(shù)據(jù)保存支持插件支持插件支持
采集點位保存所有均支持只支持文件插件支持
監(jiān)控本地監(jiān)控支持支持支持
服務(wù)端監(jiān)控支持Beta版本支持簡單功能輔助監(jiān)控軟件擴展
使用方式
部署k8s的日志采集只需分為3個步驟酥郭，1分鐘內(nèi)即可完成集群部署（詳細幫助文檔參見[k8s采集幫助]()）华坦，這可能是你見過的最簡單的k8s日志采集部署方案：
部署Logtail的DaemonSet。體力消耗：一條wget名不从，vi 修改3個參數(shù)惜姐，執(zhí)行一條kubectl命令
日志服務(wù)控制臺創(chuàng)建自定義標識機器組(后續(xù)集群動態(tài)伸縮無需額外操作)。體力消耗：web控制臺點擊幾次，輸入一個ID
日志服務(wù)控制臺創(chuàng)建采集配置(所有采集均為服務(wù)端配置歹袁，無需本地運維)坷衍。體力消耗：stdout采集 web控制臺點擊幾次；文件采集 web控制臺點擊幾次条舔，輸入2個path
除k8s外枫耳，日志服務(wù)還支持標準docker部署方式
核心技術(shù)簡介
自定義標識機器組
日志采集支持k8s彈性伸縮的關(guān)鍵就是Logtail的自定義標識機器組。通常采集Agent遠程管理的方案都以IP或者hostname作為標識孟抗，此方案在集群規(guī)模較小以及環(huán)境變化性不強的情況下較為適用迁杨，當機器規(guī)模擴大、彈性伸縮成為常態(tài)時運維成本承指數(shù)級升高凄硼。
基于集團內(nèi)數(shù)年來的Agent運維經(jīng)驗總結(jié)铅协，我們設(shè)計了一種靈活性更高、使用更加便捷摊沉、耦合度更低的配置&機器管理方式：
機器組除支持靜態(tài)ip設(shè)置外狐史，也支持自定義標識的方式：所有Logtail只要定義了該標識則自動關(guān)聯(lián)到對應(yīng)的機器組。
一個Logtail可屬于多個機器組说墨，一個機器組可包含多個Logtail骏全，實現(xiàn)Logtail與機器組的解耦。
一個采集配置可應(yīng)用到多個機器組尼斧，一個機器組可關(guān)聯(lián)多個采集配置吟温，實現(xiàn)機器組與采集配置的解耦。
以上概念映射到k8s中突颊，可實現(xiàn)各種靈活的配置：
一個k8s集群對應(yīng)一個自定義標識的機器組。同一集群的Logtail使用相同配置潘悼，k8s集群伸縮時對應(yīng)Logtail的DaemonSet自動伸縮律秃，Logtail啟動后立即就會獲取和該機器組關(guān)聯(lián)的所有配置。
一個k8s集群中配置多種不同采集配置治唤。根據(jù)不同Pod需求設(shè)置對應(yīng)的采集配置棒动，所有涉及容器采集的配置均支持IncludeLabel、ExcluseLabel過濾
同一配置可應(yīng)用到多個k8s集群宾添。如果您有多個的k8s集群船惨，若其中有部分服務(wù)日志采集邏輯相同，您可以將同一配置應(yīng)用到多個集群缕陕，無需額外配置粱锐。
容器自動發(fā)現(xiàn)
Logtail和很多軟件（Logspout、MetricBeats扛邑、Telegraf等）一樣內(nèi)置了容器的自動發(fā)現(xiàn)機制怜浅。當前開源的容器自動發(fā)現(xiàn)均采用一次掃描+事件監(jiān)聽的方式，即：初次運行時獲取當前所有的容器信息，后續(xù)監(jiān)聽docker engine的事件信息恶座，增量更新信息搀暑。
此種方式效率相對最高，但有一定概率遺漏部分信息：
獲取所有容器信息到docker engine事件監(jiān)聽建立期間的這部分的增量信息會丟失
事件監(jiān)聽可能會因為某些異常情況而終止跨琳，終止后到監(jiān)聽重新建立期間的增量信息會丟失
考慮以上問題自点，Logtail采用了事件監(jiān)聽與定期全量掃描的方式實現(xiàn)容器的自動發(fā)現(xiàn)：
首先注冊監(jiān)聽事件，其次再全量掃描
每隔一段時間執(zhí)行一次全量掃描脉让，全量更新meta信息（時間間隔高到對docker engine壓力無影響）
容器文件自動渲染
容器日志采集只需要配置容器內(nèi)的文件路徑桂敛，并且支持各種采集模式：極簡、Nginx模板侠鳄、正則埠啃、分隔符、JSON等伟恶。相對傳統(tǒng)的絕對路徑采集碴开，容器內(nèi)日志采集動態(tài)性極強，為此我們專門實現(xiàn)了一套容器路徑的自動匹配與配置渲染方案：
Logtail會根據(jù)配置的容器路徑博秫，查找容器對應(yīng)路徑在宿主機上的映射關(guān)系
根據(jù)宿主機路徑以及容器的元數(shù)據(jù)信息（container name潦牛、pod、namespace...）渲染出正常的采集配置
Logtail文件采集模塊加載渲染的配置并采集數(shù)據(jù)
當容器銷毀時刪除相應(yīng)渲染的配置
可靠性保證
日志采集中的可靠性保證是非常重要也非常困難的工作挡育。在Logtail的設(shè)計中巴碗，進程退出、異常終止即寒、程序升級被認為是常態(tài)橡淆，在這些情況發(fā)生時Logtail需盡可能保證數(shù)據(jù)的可靠性。針對容器數(shù)據(jù)采集的動態(tài)特點母赵，Logtail在之前可靠性保證的基礎(chǔ)上逸爵，新增了容器標準輸出以及容器文件的checkpoint維護機制
容器標準輸出checkpoint管理
容器stdout和stderr的checkpoint獨立保存
checkpoint保存策略：定期dump所有容器當前的checkpoint；配置更新/進程退出時強制保存
配置加載時凹嘲，默認從checkpoint處開始采集师倔，若無checkpoint，則從5秒前采集
考慮到配置刪除時并不會刪除checkpoint周蹭，后臺定期清除無效checkpoint
容器文件checkpoint管理
除文件采集的checkpoint需保存外趋艘，還需保存容器meta的映射關(guān)系
checkpoint加載前需提前加載容器與文件之間的映射關(guān)系
考慮到停止期間無法感知容器狀態(tài)變化，所以每次啟動時會渲染所有當前的配置凶朗。Logtail保證多次加載同一容器配置的冪等性瓷胧。
總結(jié)
阿里云日志服務(wù)提供的解決方案完美地解決了k8s上日志采集難的問題，從之前需要多個軟件棚愤、幾十個部署流程精簡到1款軟件抖单、3個操作即可輕松上云，讓廣大用戶真正體驗到一個字：爽，從此日志運維人員的生活質(zhì)量大大提高矛绘。
目前Logtail除支持宿主機文件耍休、容器文件、容器stdout采集外货矮，還支持以下多種采集方式（這些方式k8s中均支持）：
此外羊精，Logtail即將推出Docker Event、Container Metric采集方式囚玫，敬請期待喧锦！
同志們有更多日志服務(wù)相關(guān)需求或問題請加釘釘群聯(lián)系：
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載抓督，如需轉(zhuǎn)載請發(fā)送郵件至yqeditor@list.alibaba-inc.com燃少；如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：yqgroup@service.aliyun.com 進行舉報铃在，并提供相關(guān)證據(jù)阵具，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容定铜。
