安丘做网站的,网站菜单导航,那个公司搭建网站,青岛市最大的网络公司是哪里简介#xff1a;11月23日#xff0c;阿里正式开源可观测数据采集器iLogtail。作为阿里内部可观测数据采集的基础设施#xff0c;iLogtail承载了阿里巴巴集团、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail运行在服务器、容器、K8s、嵌入式等多种环境…简介11月23日阿里正式开源可观测数据采集器iLogtail。作为阿里内部可观测数据采集的基础设施iLogtail承载了阿里巴巴集团、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail运行在服务器、容器、K8s、嵌入式等多种环境支持采集数百种可观测数据目前已经有千万级的安装量每天采集数十PB的可观测数据广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。 作者 | 元乙 来源 | 阿里技术公众号
11月23日阿里正式开源可观测数据采集器iLogtail。作为阿里内部可观测数据采集的基础设施iLogtail承载了阿里巴巴集团、蚂蚁的日志、监控、Trace、事件等多种可观测数据的采集工作。iLogtail运行在服务器、容器、K8s、嵌入式等多种环境支持采集数百种可观测数据目前已经有千万级的安装量每天采集数十PB的可观测数据广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。
一 iLogtail与可观测性 可观测性并不是一个全新的概念而是从IT系统中的监控、问题排查、稳定性建设、运营分析、BI、安全分析等逐渐演化而来可观测性相比传统监控最核心的演进是尽可能多的收集各类可观测数据来实现目标的白盒化。而iLogtail的核心定位就是可观测数据的采集器能够尽可能多的采集各类可观测性数据助力可观测平台打造各种上层的应用场景。 二 阿里可观测数据采集的挑战 对于可观测数据的采集有很多开源的Agent例如Logstash、Filebeats、Fluentd、Collectd、Telegraf等。这些Agent的功能非常丰富使用这些Agent的组合再进行一定的扩展基本可以满足内部各类数据的采集需求。但由于一些性能、稳定性、管控能力等关键性的挑战无法满足最终我们还是选择自研
1、资源消耗目前阿里内部有数百万的主机物理机/虚拟机/容器每天会产生几十PB的可观测数据每1M的内存减少、每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日阿里巴巴集团正式运营服务器规模达到50005K的“飞天”集群成为中国第一个独立研发拥有大规模通用计算平台的公司也是世界上第一个对外提供5K云计算服务能力的公司。
飞天5K项目从2009年开始从最开始的30台逐渐发展到5000不断解决系统核心的问题比如说规模、稳定性、运维、容灾等等。而iLogtail在这一阶段诞生最开始就是要解决5000台机器的监控、问题分析、定位的工作如今的词语叫做“可观测性”。从30到5000的跃升中对于可观测问题有着诸多的挑战包括单机瓶颈、问题复杂度、排查便捷性、管理复杂度等。 在5K阶段iLogtail本质上解决的是从单机、小规模集群到大规模的运维监控挑战这一阶段iLogtail主要的特点有
功能实时日志、监控采集日志抓取延迟毫秒级性能单核处理能力10M/s5000台集群平均资源占用0.5%CPU核可靠性自动监听新文件、新文件夹支持文件轮转处理网络中断管理远程Web管理配置文件自动下发运维加入集团yum源运行状态监控异常自动上报规模3W部署规模上千采集配置项日10TB数据
2 阿里集团阶段
iLogtail在阿里云飞天5K项目中的应用解决了日志、监控统一收集的问题而当时阿里巴巴集团、蚂蚁等还缺少一套统一、可靠的日志采集系统因此我们开始推动iLogtail作为集团、蚂蚁的日志采集基础设施。从5K这种相对独立的项目到全集团应用不是简单复制的问题而我们要面对的是更多的部署量、更高的要求以及更多的部门
百万规模运维问题此时整个阿里、蚂蚁的物理机、虚拟机超过百万台我们希望只用1/3的人力就可以运维管理百万规模的Logtail更高的稳定性iLogtail最开始采集的数据主要用于问题排查集团广泛的应用场景对于日志可靠性要求越来越高例如计费计量数据、交易数据而且还需要满足双十一、双十二等超大数据流量的压力考验。多部门、团队从服务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的发展我们期待
iLogtail在性能和资源占用上相比其他开源采集软件具备一定优势相比开源软件在千万部署规模、日数十PB数据的规模性下为我们减少了100TB的内存和每年1亿的CPU核小时数。我们也希望这款采集软件可以为更多的企业带来资源效率的提升实现可观测数据采集的“共同富裕”。目前iLogtail还只是在阿里内部以及很小一部分云上企业虽然有几万家但是面对全球千万的企业这个数字还很小面对的场景相对还较少我们希望有更多不同行业、不同特色的公司可以使用iLogtail并对其提出更多的数据源、处理、输出目标的需求丰富iLogtail支持的上下游生态。性能、稳定性是iLogtail的最基本追求我们也希望能够通过开源社区吸引更多优秀的开发者一起共建iLogtail持续提升这款可观测数据采集器的性能和稳定性。
原文链接 本文为阿里云原创内容未经允许不得转载。
