iLogtail开源之路-亚洲ca88官方网站

  2022年6月底，阿里云iLogtail代码完好开源，正式发布了完好功用的iLogtail社区版。iLogtail作为阿里云SLS官方标配的搜集器，多年以来一向安稳服务阿里集团、蚂蚁集团以及许多公有云上的企业客户，现在现已有千万级的装置量，每天搜集数十PB的可观测数据，广泛运用于线上监控、问题剖析/定位、运营剖析、安全剖析等多种场景。此次完好开源，iLogtail社区版初次在内核才能上与企业版彻底对齐，开发者能够构建出与企业版功用适当的iLogtail云原生可观测性数据搜集器。

  iLogtail的中心定位是可观测数据的搜集器，协助开发者构建共同的数据搜集层，助力可观测渠道打造各种上层的运用场景。iLogtail一向秉承敞开共建的准则，欢迎任何办法的社区评论沟通及公建。

  可观测性指的是从系统的外部输出揣度及衡量系统内部状况。在咱们日子傍边也会遇到许多可观测的软弱。轿车仪表盘便是一个很典型的可观测软弱，在驾驭轿车进程中，特别需求高度注重便是行进安全问题。而轿车仪表盘下降了辨认轿车内部状况的门槛，即便非轿车工程专业人员也能经过仪表盘快速辨认轿车的内部状况。

  别的，咱们往常的治病能够以为是人体可观测的软弱。在古代，医疗水平比较落后，全体来说人体是一个黑盒，只能经过外表的望闻问切来确诊病因，可是这种办法过度的依靠医师的经历、缺少有力的数据支撑。而到了近代，跟着心电图、X光等医疗设备的开展，人体的内部机制变得越来越通明，大幅提高了医疗水平，给人们的身体健康带来了福音。经过上述的软弱咱们能够看到，可观测性不只要能定性地反应系统内部状况，最重要的是要定量的证明系统内部状况，需求有满意的数据依据，也便是咱们说到的可观测数据的质量和精确性。

  回到咱们软件职业，经过几十年的飞速开展，整个开发形式、系统架构、布置形式、根底设施等也都经过了几回颠覆性的革新，这些革新带来了更快的开发和布置功率，但随之而来整个的系统也愈加的杂乱、开发所依靠人和部分也更多、布置形式和运转环境也愈加动态和不确定，这也对可观测数据搜集提出了更高的要求。首要需求习气开发形式快速迭代的需求，需求能够与DevOps流程等进行高度的集成，经过轻量级、主动化集成的办法完结开发、测验、运维的一体化；也需求习气布置架构分布式、容器化的需求，提高事务服务动态、及时、精确发现的才能；终究，云原生的开展也带来了更多的上下游依靠，因而也需求习气数据来历、数据类型越来越多的需求。

  Logs、Traces、Metrics作为可观测性数据的三大支柱，根本能够满意各类监控、告警、剖析、问题排查等需求。这儿大致剖析下这三类数据的特色、转化办法以及适用场景：

  Logs：作为软件运转状况的载体，经过日志能够具体解说系统运转状况及复原事务处理的进程。常见日志类型包含运转日志、拜访日志、买卖日志、内核日志、满日志、过错日志等。

  Metrics：是指对系统中某一类信息的核算聚合，相比照较离散。一般有name、labels、time、values组成，Metrics数据量一般很小，相对本钱更低，查询的速度比较快。

  Traces：是最规范的调用日志，除了界说了调用的父子联系外（一般经过TraceID、SpanID、ParentSpanID），一般还会界说操作的服务、办法、特色、状况、耗时等具体信息。

  三者间的转化联系：Logs在调用链场景结构化后其实能够转变为Trace，在进行聚合、降采样操作后会变成Metrics。

  搜集端：承载可观测数据搜集及一部分前置的数据处理功用。跟着云原生的开展，搜集端也需求习气年代潮流，供给对K8s搜集的友爱支撑。常见的搜集端有Filebeat、FluentD/Fluent-bIt，以及咱们开源的iLogtail。

  音讯行列：搜集Agent往往不会直接将搜集到的数据发送到存储系统，而是写入音讯行列，起到削峰填谷的效果，避免流量洪峰导致存储系统宕机。常见音讯行列为Kafka、RabbitMQ等。

  核算：用于消费音讯行列中的数据，经过处理、聚合后输出到存储系统。比较常见的为Flink、Logstash等。

  存储剖析引擎：供给搜集数据耐久化存储才能，并供给查询剖析才能。常见的存储剖析引擎为Elasticsearch、ClickHouse及Loki。

  别的，日志服务SLS作为一款云原生观测与剖析渠道，为Log、Metric、Trace等数据供给大规划、低本钱、实时的渠道化服务。SLS一站式供给数据搜集、加工、查询与剖析、可视化、告警、消费与投递等功用，用户能够依据SLS快速构建一套完好的可观测渠道。iLogtail企业版作为SLS官方标配的搜集器，承载了事务数据搜集的责任，而iLogtail社区版正是从企业版开展而来的，功用及功用天然也承继了企业版的绝大部分才能。

  iLogtail的前身源自阿里云的神农项目，自从2013年正式孵化以来，iLogtail一向在不断演进。

  诞生初期，面临阿里云本身和前期客户运维和可观测性需求，iLogtail首要处理的是从单机、小规划集群到大规划的运维监控应战，此刻的iLogtail现已具有了根本的文件发现和轮转处理才能，能够完结日志、监控实时搜集，抓取毫秒级推迟，单核处理才能约为10M/s。经过Web前端可支撑中心化装备文件主动下发，支撑3W+布置规划，上千搜集装备项，完结日10TB数据的高效搜集。

  2015年，阿里巴巴开端推动集团和蚂蚁金服事务上云，面临近千个团队、数百万终端、以及双11、双12等超大流量数据搜集的应战，iLogtail在功用、功用、安稳性和多租户支撑方面都需求进行巨大的改进。至2017年前后，iLogtail现已具有了正则、分隔符、JSON等多个格局日志的解析才能，支撑多种日志编码办法，支撑数据过滤、脱敏等高档处理才能，单核处理才能极简形式下提高到100M/s，正则、分隔符、JSON等办法20M/s+。搜集可靠性方面，添加文件发现Polling办法兜底、轮转行列次序确保、日志整理丢掉维护、CheckPoint增强；进程可靠性方面，添加反常主动康复、Crash主动上报、看护进程等。经过全流程多租户阻隔、多级凹凸水位行列、装备级/进程级流量操控、暂时降级等机制，支撑百万+布置规划，千等级租户，10万+搜集装备项，完结日PB级数据的安稳搜集。

  跟着阿里推动中心事务全面上云，以及iLogtail所属日志服务（SLS）正式在阿里云上商业化，iLogtail开端全面拥抱云原生。面临多元的云上环境、迅速开展的开源生态和许多涌入的职业客户需求，iLogtail的开展的重心转移到处理怎么习气云原生、怎么兼容开源协议和怎么去处理碎片化需求等问题上。2018年iLogtail正式支撑docker容器搜集，2019年支撑containerd容器搜集，2020年全面晋级Metric搜集，2021年添加Trace支撑。经过全面支撑容器化、K8S Operator管控和可扩展插件系统，iLogtail支撑千万布置规划，数万内外部客户，百万+搜集装备项，完结日数十PB数据的安稳搜集。

  2021年11月iLogtail迈出了开源的第一步，将Golang插件代码开源。自开源以来，招引了数百名开发者的注重，而且也有不少开发者贡献了processor跟flusher插件。2022年6月C++中心代码也正式开源了，自此开发者能够依据该版别构建完好的云原生可观测数据搜集方案。

  可观测数据搜集Agent作为一个根底设施，往往需求每台机器都有布置，比方现在阿里内部稀有百万的装机量，每天会发生几十PB的可观测数据。因而不管是内存仍是CPU的一点点节约，都能带来比较大的本钱收益。特别是，K8s Sidecar形式关于内存的要求愈加严苛，由于iLogtail与事务容器一同布置，iLogtail布置量会随事务规划扩展而增加。

  从规划初期，咱们就比较注重iLogtail的资源占用问题，挑选了主体部分C++、插件部分Golang完结，而且经过一些技能细节（详见下文）的优化，使得内存仍是CPU相关于同类Agent都有较大的优势。

  关于日志搜集，比较常见的手法是轮询机制，这是一种主动勘探的搜集办法，经过定时检测日志文件有无更新来触发日志搜集；相应的也存在一种被迫监听的事情形式，依靠于操作系统的事情告诉（对操作系统有必定的要求），常见的事情告诉机制是Linux 2.6.13内核版别引进的inotify机制。轮询相对事情告诉的完结杂乱度要低许多、天然支撑跨渠道而且关于系统约束性不高；但轮询的搜集推迟以及资源耗费较高，而且在文件规划较大时轮询一次的时刻较长，比较简略发生搜集推迟。

  为了一同统筹搜集功率以及跨渠道的支撑，iLogtail选用了轮询（polling）与事情（inotify）并存的形式进行日志搜集，既凭借了inotify的低推迟与低功用耗费的特色，也经过轮询的办法统筹了运转环境的全面性。

  inotify归于事情监听办法，依据用户装备监听对应的目录以及子目录，当监听目录存在改动，内核会发生相应的告诉事情。

  此外，咱们也经过一些技能手法，确保了polling、inotify两种机制的高效合作，全体近一步提高了iLogtail运转功率。

  事情兼并：为避免轮询事情和inotify事情屡次触发事情处理行为，iLogtail在事情处理之前将重复的轮询/inotify事情进行兼并，削减无效的事情处理行为；

  轮询主动降级：假如在系统支撑且资源满意的场景下，inotify不管从推迟和功用耗费都要优于轮询，因而当某个目录inotify能够正常作业时，则该目录的轮询进行主动降级，轮询距离大幅下降到对CPU根本无影响的程度。

  日志次序性搜集是日志搜集需求供给的根本功用，也是一个搜集的难点，需求考虑如下场景：

  习气不同的日志轮转(rotate)机制：日志轮转是指当日志满意必定条件（时刻或文件巨细）时，需求进行重命名、紧缩等操作，之后创立新的日志文件继续写入。别的，不同运用日志库轮转文件的格局不尽相同，有的时刻结束，有的数字结束等。

  习气不同的搜集途径装备办法：优异的日志搜集agent并不应该强制约束用户的装备办法，尤其在指定日志搜集文件名时，需求习气不同用户的装备习气。不管是精准途径匹配，仍是含糊匹配，例如*.log或*.log*，都不能呈现日志轮转时多搜集或许少搜集的状况。

  为了完结日志文件的次序搜集，首要需求界说好文件的仅有标识。咱们知道在文件系统中，能够经过dev+inode的组合仅有标识一个文件。文件的move操作尽管能够改动文件名，但并不触及文件的删去创立，dev+inode并不会改动，因而经过dev+inode能够十分便当的判别一个文件是否发生了轮转。可是dev+inode只能确保同一时刻文件的仅有性，当触及文件快速删去创立的时分，前后两个文件的dev+inode很或许是相同的。因而朴实经过dev+inode判别轮转并不可行，iLogtail引进了文件签名（signature）的概念，运用日志文件的前1024字节的hash作为文件的signature，只要当dev+inode+signature共同的状况下才会以为该文件是轮转的文件。此外，iLogtail内部也引进了文件轮转行列，确保了文件的次序搜集。

  iLogtail作为一个可观测数据根底搜集组件，除了资源、功用外，可靠性也是一项要害目标。关于一些反常场景，iLogtail也有充沛的规划考虑，确保了在网络反常、流量突增、进程重启等场景下仍然能够完结正常的搜集使命。

  问题描绘：iLogtail需求许多布置在不同的事务机器上，运转环境是杂乱多变的，运用日志burst写入、网络暂时性堵塞、服务端Quota缺乏、CPU/磁盘负载较高档状况在所难免，当这些状况发生时，很简略形成日志搜集进展落后于日志发生进展，此刻，iLogtail需求在合理的资源约束下尽或许保留住这些日志，等候网络康复或系统负载下降时将这些日志搜集到服务器，而且确保日志搜集次序不会由于搜集堵塞而紊乱。

  iLogtail内部经过坚持轮转日志file descriptor的翻开状况来避免日志搜集堵塞时未搜集完结的日志文件被file system收回（在文件轮转行列中的file descriptor一向坚持翻开状况，确保文件引证计数至少为1）。一同，经过文件轮转行列的次序读取确保日志搜集次序与日志发生次序共同。

  若日志搜集进展长期继续落后于日志发生进展，彻底的不收回机制，则很有或许呈现文件轮转行列会无限增加的状况，从而导致磁盘被写爆，因而iLogtail内部关于文件轮转行列设置了上限，当size超越上限时制止后续Reader的创立，只要这种继续的极点状况呈现时，才会呈现丢日志搜集的状况。当然，在问题被扩大之前，iLogtail也会经过报警的办法，告诉用户及时介入修正问题。

  问题描绘：装备更新或进行晋级时需求中止搜集并从头初始化搜集上下文，iLogtail需求确保在装备更新/进程晋级时，即便日志发生轮转也不会丢掉日志。

  为确保装备更新/晋级进程中日志数据不丢掉，在iLogtail在装备从头加载前或进程主动退出前，会将当时一切搜集的状况保存到本地的checkpoint文件中；当新装备运用/进程发动后，会加载上一次保存的checkpoint，并经过checkpoint康复之前的搜集状况。

  可是在老版别checkpoint保存结束到新版别搜集Reader创立完结的时刻段内，很有或许呈现日志轮转的状况，因而新版别在加载checkpoint时，会查看对应checkpoint的文件名、dev+inode有无改动。

  若文件名与dev+inode改动则从当时目录查找对应的dev+inode，若查找到则比照signature是否改动。若signature未变则以为是文件轮转，依据新文件名创立Reader；若signature改动则以为是该文件被删去后从头创立，疏忽该checkpoint。

  问题描绘：在进程crash或宕机时，iLogtail需求供给容错机制，不丢数据，尽或许的少重复搜集。

  进程crash或宕机没有退出前记载checkpoint的机遇，因而iLogtail还会定时将搜集进展dump到本地：除了康复正常日志文件状况外，还会查找轮转后的日志，尽或许下降日志丢掉危险。

  业界干流的Agent关于每个装备会分配独立的线程/go runtime来进行数据读取，而iLogtail数据的读取只装备了一个线程，首要原因是：

  数据读取的瓶颈并不在于核算而是磁盘，单线程足以完结一切装备的事情处理以及数据读取。

  单线程的另一个优势是能够使事情处理和数据读取在无锁环境下运转，相对多线程处理性价比较高。

  但单线程的状况下会存在多个装备间资源分配不均的问题，假如运用简略的FCFS（ First Come First Serve）办法，一旦一个写入速度极高的文件占有了处理单元，它就一向运转下去，直到该文件被处理完结并主动开释资源，此办法很有或许形成其他搜集的文件被饿死。

  因而咱们选用了依据时刻片的搜集调度方案，使各个装备间尽或许公正的调度，避免搜集文件饿死的现象发生。iLogtail将Polling以及Inotify事情兼并到无锁的事情行列中，每个文件的修正事情会触发日志读取。每次读取从前次记载的偏移方位开端，并测验在固定的时刻片内将文读取到EOF处。假如时刻片内读取结束，则表明事情处理完结，删去事情；不然，将事情从头Push到行列尾部，等候下一次调用。

  经过以上规划，确保了iLogtail能够高功用的进行数据搜集。比照数据能够详见：

  依据时刻片的搜集调度确保了各个装备的日志在数据读取时得到公正的调度，满意了多租户阻隔中根本的公正性，但关于阻隔性并未起到协助效果。例如当部分搜集装备因处理杂乱或网络反常等原因堵塞时，堵塞装备仍然会进行处理，终究会导致行列抵达上限而堵塞数据读取线程，影响其他正常装备。为此咱们规划了一套多级凹凸水位反应行列用以在不同搜集装备间完结读取、解析、发送各个过程的有用的和谐，为了更好的完结不同装备间阻隔性，所以iLogtail会为每个装备创立一组行列。

  多级：iLogtail从搜集到输出总体要经过读取->

  解析->

  发送三个过程，iLogtail在相邻过程间别离设置一个行列。

  凹凸水位：每个行列设置凹凸两个水位，高水位时中止非紧迫数据写入，只要康复到低水位时才答应再次写入。

  反应：在预备读取当时行列数据时会同步查看下一级行列状况，下一级行列高水位则越过读取；当时行列从高水位消费到低水位时，异步告诉相关的前一级行列。

  关于一些堵塞场景的可靠性也需求考虑，首要包含事情处理、数据读取逻辑以及数据发送操控三个方面：

  事情处理与数据读取无关，即便读取相关的行列满也照旧处理，这儿的处理首要是更新文件meta、将轮转文件放入轮转行列，可确保在装备堵塞的状况下，即便文件轮转也不会丢掉数据。

  当装备相关的解析行列满时，假如将事情从头放回行列尾，则会形成较多的无效调度，使CPU空转。因而iLogtail在遇到解析行列满时，将该事情放到一个专门的blocked行列中，当解析行列异步反应时从头将blocked行列中的数据放回事情行列。

  Sender中每个装备的行列相关一个SenderInfo，SenderInfo中记载该装备当时网络是否正常、Quota是否正常以及最大答应的发送速率。每次Sender会依据SenderInfo中的状从行列中取数据，这儿包含：网络失利重试、Quota超限重试、状况更新、流控等逻辑。

  iLogtail进程由两部分组成，一是C++编写的主体二进制进程，供给了管控、文件搜集、C++加快处理的功用；二是Golang编写的插件部分，经过插件系统完结了处理才能的扩展以及更丰厚的上下游生态支撑。

  处理才能扩展：iLogtail选用PipeLine的规划，经过Input插件搜集到数据，会经过搜集装备中设定的Processor处理，之后经过Aggregator插件打包，终究经过Flusher发送到日志存储系统。数据处理环境包含数据切分、字段提取、过滤、数据增强等环节，一切插件能够自由组合。此外，针关于正则、Json、分隔符等特定格局，iLogtail还供给了C++加快才能。

  快速迭代：开发者也能够依据自己的需求，定制开发相应的插件。由于每个插件彼此独立，所以开发者只需求依照接口规范开发即可，下手门槛较低。以Processor插件接口为例，只需求完结以下接口，即可快速供给一个处理插件。

  作为容器编列范畴的规范，Kubernetes（K8s）运用的场景越来越广泛，iLogtail 在K8s下也供给了齐备的搜集才能。

  形式：在K8s的每个node上布置一个iLogtail，由该iLogtail搜集节点上一切容器的日志到日志系统。

  长处：运维简略、资源占用少、支撑搜集容器的规范输出和文本文件、装备办法灵敏。

  缺陷：iLogtail需求搜集节点上一切容器的日志，各个容器之间的阻隔性较弱，且关于事务超级多的集群或许存在必定的功用瓶颈。

  形式：一个POD中随同事务容器运转一个iLogtail容器，用于搜集该POD中事务容器发生的日志。

  长处：Sidecar办法为每个需求搜集日志的容器创立一个Sidecar容器，多租户阻隔性好、功用好。

  形式：当事务容器用PVC挂载日志目录或许需求大局衔接API Server获取K8s元数据等场景，能够挑选在集群中布置一个单副本的iLogtail Deployment进行数据搜集。

  自K8s面世以来，docker运转时一向是干流，可是跟着K8s将dockershim移除，K8s官方引荐优先挑选containerd 或 CRI-O作为容器运转时。docker比例现在尽管仍是干流可是现已在呈逐年下降的趋势，contailerd、cri-o位置逐年都在快速上升。因而，从K8s支撑全面性上，iLogtail需求支撑干流的运转时，现在现已支撑Docker和Containerd两种容器引擎的数据搜集。

  K8s供给了强壮的运维布置、弹性弹性、毛病康复才能，极大地便当了分布式系统的开发和办理，可是这也带来了可观测数据搜集难度的增大。特别是一些短Job场景，比方一些机器学习的训练使命，生命周期只要几分钟乃至几秒，怎么快速精确地发现所需求搜集的容器至关重要。

  经过监听Docker Event及增量获取机制，及时感知容器新增与开释。

  容器过滤及阻隔性：依据容器上下文信息，供给搜集容器过滤才能，能够将不同搜集装备运用到不同的搜集容器上，既能够确保搜集的阻隔性，也能够削减不必要的资源糟蹋。

  元信息相关：依据容器上下文信息和容器环境变量，供给在日志中富化K8s元信息的才能。

  规范输出：iLogtail能够依据容器元信息主动辨认不同运转时的规范输出格局和日志途径，不需求额定手动装备。

  容器内文件：关于overlay、overlay2的存储驱动，iLogtail能够依据日志类型及容器运转时主动拼接出搜集途径，简略高效。

  此外，关于CICD主动化布置和运维程度要求较高的用户，iLogtail还供给了K8s原生支撑，支撑经过CRD的办法进行搜集装备办理。现在该功用仅企业版可用，后续会逐渐开源。该方案中，iLogtail K8s新增了一个CustomResourceDefinition扩展，名为AliyunLogConfig。一同开发了alibaba-log-controller用于监听AliyunLogConfig事情并主动创立iLogtail的搜集装备，从而完结日志搜集作业。

  iLogtail开源，秉承技能同享与开发者共建的准则，所以中心功用是彻底开源的，因而能够以为在中心搜集才能上（包含搜集处理功用、功用、可靠性等）与企业版是彻底对标的。

  SLS供给了关于Log、Metric、Trace的共同存储剖析才能，运用iLogtail企业版将数据搜集到SLS，能够更好的构建各类上层运用。凭借SLS能够完结日志上下文预览、Exactly Once等高档特性。

  凭借SLS渠道，能够完结第三方Agent的管控才能。例如，未来SLS也会跟DeepFlow进行深度集成。

  SLS作为可观测渠道，既能够承载可观测数据存储剖析的功用，也能够承载流量管道的效果，能够简化架构布置。

  支撑的操作系统、系统架构愈加丰厚，企业版支撑Windows系统跟ARM架构。

  主动化装置布置才能更高，凭借阿里云的运维服务，能够完结iLogtail批量主动装置。

  与阿里云ECS、ACK、ASK、EMR等高度集成，能够一键装置布置，搜集数据能够快速接入，内置剖析。

  大规划/杂乱场景专业化支撑：比方K8s短job，单节点大流量日志、大规划搜集装备等。

  SLS供给了关于Log、Metric、Trace的共同存储剖析才能，而且也能够承载流量管道效果，具有强壮的数据加工才能，依据SLS能够快速构建出一套云原生可观测渠道。智能告警中枢、智能算法服务近一步增强了该渠道的智能化水平。用户能够依据此渠道，快捷高效的构建各类ITOps、DevOps、SecOps、BusinessOps上层运用。

  iLogtail企业版作为SLS官方标配官方标配搜集器，在SLS数据接入范畴充当着排头兵的责备，承载了许多的接入流量。

  技能同享一向是iLogtail秉承的理念，咱们期望和欢迎更多开发者参加共建。咱们期望跟开发者一同，将iLogtail的上下游生态建的更丰厚。为了提高开发者的体会，咱们也会继续的改进iLogtail中心才能跟比例才能，进一步下降开发门槛，丰厚测验系统建造，为开发者供给必要的技能支撑。

  怎么高效办理搜集装备一向是可观测搜集器的痛点，为此咱们也会在不久将来开源服务端大局管控方案及iLogtail监控方案，也欢迎开发者参加共建，一同打造共同的管控生态。

  终究，OpenTelemetry作为可观测范畴的规范，iLogtail也将活跃拥抱。K8s原生体会也是咱们寻求的方向，咱们也有方案推出iLogtail Operator。

  iLogtail作为阿里云SLS供给的可观测数据搜集器，能够运转在服务器、容器、K8s、嵌入式等多种环境，支撑搜集数百种可观测数据（日志、监控、Trace、事情等），现已有千万级的装置量。现在，iLogtail已正式开源，欢迎运用及参加共建。

上一篇：我国智能数据采集器商场现状剖析及远景猜测陈述 下一篇：便携数据采集器职业深度研讨陈述