iLogtail——一款延迟仅在毫秒级的千万实例可观测采集器利器来了 | 龙蜥技术

2022/02/16 20:00
阅读数 10

编者按:iLogtail 的核心定位就是可观测数据采集的基础设施,广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。本文整理自龙蜥SIG技术周会直播,主要介绍 iLogtail 的开源背景、功能、优势以及它的发展历程,视频回顾里还为大家演示如何使用 iLogtail 采集各类可观测数据,直播视频回放已上线至龙蜥社区官网:首页-支持-视频,欢迎观看。

文/张诚,iLogtail  SIG核心成员、阿里云技术专家

iLogtail 是阿里已开源可观测数据采集器, 作为阿里内部可观测数据采集的基础设施,iLogtail 承载了阿里巴巴集团、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail 运行在服务器、容器、K8s、嵌入式等多种环境,支持采集数百种可观测数据,目前已经有 千万级的安装量 ,每天采集数 十PB 的可观测数据,广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。

一、iLogtail 与可观测性


可观测性并不是一个全新的概念,而是从 IT 系统中的监控、问题排查、稳定性建设、运营分析、BI、安全分析等逐渐演化而来,可观测性相比传统监控,最核心的演进是尽可能多的收集各类可观测数据,来实现目标的白盒化。而 iLogtail 的核心定位就是可观测数据的采集器,能够尽可能多的采集各类可观测性数据,助力可观测平台打造各种上层的应用场景。

二、阿里可观测数据采集的挑战

对于可观测数据的采集,有很多开源的 Agent,例如 Logstash、Filebeats、Fluentd、Collectd、Telegraf 等。 这些 Agent 的功能非常丰富,使 用这些 Agent 的组合再进行一定的扩展,基本可以满足内部各类数据的采集需求。 但由于一些性能、稳定性、管控能力等关键性的挑战无法满足,最终我们还是选择自研:
1、资源消耗。 目前阿里内部有数百万的主机(物理机/虚拟机/容器),每天会产生几十 PB 的可观测数据,每 1 M的内存减少、每 1M/s 的性能提升对于我们的资源节省都是巨大的,带来的成本节约可能是数百万甚至上千万。目前众多开源 Agent 的设计更多的是偏重功能而非性能,基于现有开源 Agent 改造基本不可行。例如:
  • 开源 Agent 普遍单核处理性能在 2-10M/s 左右,而我们希望有一个能达到 100M/s 的性能

  • 在采集目标增加、数据量增加、采集延迟、服务端异常等情况下,开源 Agent 内存都会呈现爆炸式增长,而我们希望即使在各种环境下,内存也能处在较低的水位

  • 开源 Agent 的资源消耗没办法控制,只能通过 cgroup 强行限制,最终的效果就是不断 OOM,不断重启,数据一直采集不上来。而我们希望在指定一个 CPU、内存、流量等资源限制后,Agent 能一直在这个限制范围内正常工作
2、稳定性。 稳定性是永恒的话题,数据采集的稳定性,除了保证数据本身采集的准确性外,还需要保证采集的 Agent 不能影响业务应用,否则带来的影响将是灾难性的。而稳定性建设,除了 Agent 自身的基础稳定性外,还有很多特性目前开源的 Agent 还没有提供:
  • Agent自恢复:Agent遇到Critical的事件后能够自动恢复,并且提供多个维度的自恢复能力,例如进程自身、父子进程、守护进程

  • 全局的多维度监控:能够从全局的角度监控各个不同版本、不同采集配置、不同压力、不同地域/网络等属性的Agent的稳定性问题

  • 问题隔离:作为Agent,无论怎样出现问题,都需要尽可能的隔离问题,例如一个Agent上有多个采集配置,一个配置出问题,不能影响其他配置;Agent自身出现问题,不能影响机器上的应用进程的稳定性

  • 回滚能力:版本更新和发布是再所难免的问题,在出现问题的时候如何快速回滚,而且保证出问题和回滚期间的数据采集还是 at least once甚至是 exactly once

3、可管控。 可观测数据的应用范围非常的广,几乎所有的业务、运维、BI、安全等部门都会要用,而一台机器上也会产生各种数据,同一台机器产生的数据上也会有多个部门的人要去使用,例如在 2018 年我们统计,平均一台虚拟机上有 100 多个不同类型的数据需要采集,设计 10 多个不同部门的人要去使用这些数据。除了这些之外,还会有其他很多企业级的特性需要支持,例如:
  • 配置的远程管理:在大规模场景下,手工登录机器修改配置基本没有可行性,因此需要一套配置的图形化管理、远程存储、自动下发的机制,而且还要能够区分不同的应用、不同的 Region、不同的归属方等信息。同时因为涉及到远程配置的动态加卸载,Agent还需要能够保证配置 Reload 期间数据不丢不重

  • 采集配置优先级:当一台机器上有多个采集配置在运行时,如果遇到资源不足的情况,需要区分每个不同的配置优先级,资源优先供给高优先级的配置,同时还要确保低优先级的配置不被“饿死”

  • 降级与恢复能力:在阿里,大促、秒杀是家常便饭,在这种波峰期间,可能有很多不重要的应用被降级,同样对应应用的数据也需要降级,降级后,在凌晨波峰过后,还需要有足够的Burst能力快速追齐数据

  • 数据采集齐全度:监控、数据分析等场景都要求数据准确度,数据准确的前提是都能及时采集到服务端,但如何在计算前确定每台机器、每个文件的数据都采集到了对应的时间点,需要一套非常复杂的机制去计算

基于以上的背景和挑战下,我们从 2013 年开始,不断逐渐优化和改进 iLogtail 来解决性 能、稳定性、可管控等问题,并经历了阿里多次双十一、 双十二、春晚红包等项目的考验。 目前 iLogtail 支持包括 Logs、Traces、Metrics 多种类型数据的统一收集,核心的特点主要如下:
  • 支持多种 Logs、Traces、Metrics 数据采集,尤其对容器、Kubernetes 环境支持非常友好

  • 数据采集资源消耗极低,单核采集能力 100M/s,相比同类可观测数据采集的 Agent 性能好 5-20 倍

  • 高稳定性,在阿里巴巴以及数万阿里云客户生产中使用验证,部署量近千万,每天采集数十 PB 可观测数据

  • 支持插件化扩展,可任意扩充数据采集、处理、聚合、发送模块

  • 支持配置远程管理,支持以图形化、SDK、K8s Operator 等方式进行配置管理,可轻松管理百万台机器的数据采集

  • 支持自监控、流量控制、资源控制、主动告警、采集统计等多种高级管控特性

三、iLogtail 发展历程

秉承着阿里人简单的特点,iLogtail 的命名也非常简单,我们最开始期望的就是能够有一个统一去 Tail 日志的工具,所以就叫做 Logtail,添加上“i”的原因主要当时使用了 inotify 的技术,能够让 日志采集的延迟控制在毫秒级 ,因此最后叫做 iLogtail。从 2013 年开始研发,iLogtail 整个发展历程概括起来大致可以分为三个阶段, 分别是飞天 5K 阶段、阿里集团阶段和云原生阶段。

1.飞天 5K 阶段

作为中国云计算领域的里程碑,2013 年 8 月 15 日,阿里巴巴集团正式运营服务器规模达到 5000(5K)的“飞天”集群,成为中国第一个独立研发拥有大规模通用计算平台的公司,也是世界上第一个对外提供5K云计算服务能力的公司。
飞天 5K 项目从 2009 年开始,从最开始的 30 台逐渐发展到 5000,不断解决系统核心的问题,比如说规模、稳定性、运维、容灾等等。而 iLogtail 在这一阶段诞生,最开始就是要解决 5000 台机器的监控、问题分析、定位的工作(如今的词语叫做“可观测性”)。从 30 到 5000 的跃升中,对于可观测问题有着诸多的挑战,包括单机瓶颈、问题复杂度、排查便捷性、管理复杂度等。

在 5K 阶段,iLogtail 本质上解决的是从单机、小规模集群到大规模的运维监控挑战,这一阶段 iLogtail 主要的特点有:

  • 功能:实时日志、监控采集,日志抓取延迟毫秒级

  • 性能:单核处理能力 10M/s,5000 台集群平均资源占用 0.5%CPU 核

  • 可靠性:自动监听新文件、新文件夹,支持文件轮转,处理网络中断

  • 管理:远程 Web 管理,配置文件自动下发

  • 运维:加入集团 yum 源,运行状态监控,异常自动上报

  • 规模:3W+ 部署规模,上千采集配置项,日 10TB 数据

2阿里集团阶段

iLogtail 在阿里云飞天 5K 项目中的应用解决了日志、监控统一收集的问题,而当时阿里巴巴集团、蚂蚁等还缺少一套统一、可靠的日志采集系统,因此我们开始推动 iLogtail 作为集团、蚂蚁的日志采集基础设施。从 5K 这种相对独立的项目到全集团应用,不是简单复制的问题,而我们要面对的是更多的部署量、更高的要求以及更多的部门:
  1. 百万规模运维问题:此时整个阿里、蚂蚁的物理机、虚拟机超过百万台,我们希望只用 1/3 的人力就可以运维管理百万规模的 Logtail。

  2. 更高的稳定性:iLogtail 最开始采集的数据主要用于问题排查,集团广泛的应用场景对于日志可靠性要求越来越高,例如计费计量数据、交易数据,而且还需要满足双十一、双十二等超大数据流量的压力考验。

  3. 多部门、团队:从服务 5K 团队到近千个团队,会有不同的团队使用不同的iLogtail,而一个 iLogtail 也会被多个不同的团队使用,在租户隔离上对 iLogtail 是一个新的挑战。

经过几年时间和阿里集团、蚂蚁同学的合作打磨, iLogtail 在多租户、稳定性等方面取得了非常大的进步 ,这一阶段 iLogtail 主要的特点有:
  • 功能:支持更多的日志格式,例如正则、分隔符、JSON 等,支持多种日志编码方式,支持数据过滤、脱敏等高级处理

  • 性能:极简模式下提升到单核 100M/s,正则、分隔符、JSON 等方式 20M/s+

  • 可靠性:采集可靠性支持 Polling、轮转队列顺序保证、日志清理保护、CheckPoint 增强;进程可靠性增加 Critical 自恢复、Crash 自动上报、多级守护

    日志保序采集方案原理(细节可参考《iLogtail 技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》)
    • 多租户:支持全流程多租户隔离、多级高低水位队列、采集优先级、配置级/进程级流量控制、临时降级机制

    多租户隔离整体流程(细节可参考《iLogtail 技术分享(二): 多租户隔离技术+双十一实战效果》)
    • 运维:基于集团 StarAgent 自动安装与守护,异常主动通知,提供多种问题自查工具

    • 规模:百万+部署规模,千级别内部租户,10 万+采集配置,日采集 PB 级数据

    3. 云原生阶段

    随着阿里所有 IT 基础设施全面云化,以及 iLogtail 所属产品 SLS(日志服务)正式在阿里云上商业化,iLogtail 开始全面拥抱云原生。从阿里内部商业化并对外部各行各业的公司提供服务,对于 iLogtail 的挑战的重心已经不是性能和可靠性,而是如何适应云原生(容器化、K8s,适应云上环境)、如何兼容开源协议、如何去处理碎片化需求。这一阶段是iLogtail发展最快的时期,经历了非常多重要的变革:
    • 统一版本:iLogtail 最开始的版本还是基于 GCC4.1.2 编译,代码还依赖飞天基座,为了能适用更多的环境,iLogtail 进行了全版本的重构,基于一套代码实现Windows/Linux、X86/Arm、服务器/嵌入式等多种环境的编译发版

    • 全面支持容器化、K8s:除了支持容器、K8s 环境的日志、监控采集外,对于配置管理也进行了升级,支持通过 Operator 的方式进行扩展,只需要配置一个AliyunLogConfig的K8s自定义资源就可以实现日志、监控的采集

    iLogtail Kubernetes日志采集原理(细节可参考《Kubernetes日志采集原理剖析》)
    • 插件化扩展:iLogtail 增加插件系统,可自由扩展 Input、Processor、Aggregator、Flusher 插件用以实现各类自定义的功能

    iLogtail 插件系统整体流程(细节可参考《iLogtail 插件系统简介》)
    • 规模:千万部署规模,数万内外部客户,百万+采集配置项,日采集数十PB数据

    四、开源背景与期待

    闭源自建的软件永远无法紧跟时代潮流,尤其在当今云原生的时代,我们坚信开源才是 iLogtail 最优的发展策略,也是释放其最大价值的方法。iLogtail 作为可观测领域最基础的软件,我们将之开源,也希望能够和开源社区一起共建,持续优化,争取 成为 世界一流的可观测数据采集器 。对于未来 iLogail 的发展,我们期待:
    1. iLogtail 在性能和资源占用上相比其他开源采集软件具备一定优势,相比开源软件,在千万部署规模、日数 PB 数据的规模性下为我们减少了 100TB 的内存和每年 1 亿的 CPU 核小时数。我们也希望这款采集软件可以为更多的企业带来资源效率的提升,实现可观测数据采集的“共同富裕”。

    2. 目前 iLogtail 还只是在阿里内部以及很小一部分云上企业(虽然有几万家,但是面对全球千万的企业,这个数字还很小),面对的场景相对还较少,我们希望有更多不同行业、不同特色的公司可以使用 iLogtail 并对其提出更多的数据源、处理、输出目标的需求,丰富 iLogtail 支持的上下游生态。

    3. 性能、稳定性是 iLogtail 的最基本追求,我们也希望能够通过开源社区,吸引更多优秀的开发者(钉钉扫面下方二维码或搜索钉钉群号:35576244 入群交流),一起共建 iLogtail,持续提升这款可观测数据采集器的性能和稳定性。

    敲重点!

    本次直播视频回放已上线至龙蜥社区官网(首页-支持-视频),直播 PPT 获取方式:关注龙蜥社区公众号,后台回复【龙蜥课件】【龙蜥视频回放】即可。

    链接汇总:
    1)阿里正式开源可观测数据采集器 iLogtail:https://github.com/alibaba/ilogtail
    2)《iLogtail技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》:https://zhuanlan.zhihu.com/p/29303600
    3)《iLogtail技术分享(二):多租户隔离技术+双十一实战效果》:https://www.sohu.com/a/205324880_465959
    4)《Kubernetes日志采集原理剖析》:https://developer.aliyun.com/article/806369
    5)《iLogtail插件系统简介》:

    https://github.com/alibaba/ilogtail/blob/main/docs/zh/concept%26designs/Overview.md

    6)龙蜥社区 SIG 地址链接》:
    https://openanolis.cn/sig/ilogtail
    —— 完 ——
    加入龙蜥社群

    加入微信群:添加社区助理-龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;加入钉钉群:扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区(OpenAnolis)交流,共同推进龙蜥社区的发展,一起打造一个活跃的、健康的开源操作系统生态!

    关于龙蜥社区

    龙蜥社区OpenAnolis)是由企事业单位、高等院校、科研单位、非营利性组织、个人等在自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月,旨在构建一个开源、中立、开放的Linux 上游发行版社区及创新平台。

    龙蜥社区成立的短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 停服后的应对方案,构建一个兼容国际 Linux 主流厂商的社区发行版。中长期目标是探索打造一个面向未来的操作系统,建立统一的开源操作系统生态,孵化创新开源项目,繁荣开源生态。

    目前,龙蜥OS 8.4已发布,支持 X86_64 、Arm64、LoongArch 架构,完善适配飞腾、海光、兆芯、鲲鹏、龙芯等芯片,并提供全栈国密支持。

    欢迎下载:

    https://openanolis.cn/download

    加入我们,一起打造面向未来的开源操作系统!

    https://openanolis.cn

    往期精彩推荐

    1.知名信息安全厂商渔翁信息加入龙蜥社区,共建开源生态

    2.商用密码领域骨干企业格尔软件加入龙蜥社区,共建信息安全底座

    3.龙蜥社区一周动态 | 2.07-2.13
    4.国产 AI 芯片设计企业嘉楠科技加入龙蜥社区,共建开源生态

    5.网迅科技加入龙蜥社区,共筑网络信息安全长城

    本文分享自微信公众号 - OpenAnolis龙蜥(OpenAnolis)。
    如有侵权,请联系 support@oschina.cn 删除。
    本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

    展开阅读全文
    加载中
    点击引领话题📣 发布并加入讨论🔥
    打赏
    0 评论
    0 收藏
    0
    分享
    返回顶部
    顶部