年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。
开源方案探讨
目前行业上主流的可观测开源方案，大概可以分为5个部分。
采集端：承载可观测数据采集及一部分前置的数据处理功能。随着云原生的发展，采集端也需要适应时代潮流，提供对K8s采集的友好支持。常见的采集端有Filebeat、FluentD/Fluent-bIt，以及我们开源的iLogtail。
消息队列：采集Agent往往不会直接将采集到的数据发送到存储系统，而是写入消息队列，起到削峰填谷的作用，避免流量洪峰导致存储系统宕机。常见消息队列为Kafka、RabbitMQ等。
计算：用于消费消息队列中的数据，经过处理、聚合后输出到存储系统。比较常见的为Flink、Logstash等。
存储分析引擎：提供采集数据持久化存储能力，并提供查询分析能力。常见的存储分析引擎为Elasticsearch、ClickHouse及Loki。
可视化：借助Kibana和Grafana提供采集数据的可视化能力。另外，日志服务SLS作为一款云原生观测与分析平台，为Log、Metric、Trace等数据提供大规模、低成本、实时的平台化服务。SLS一站式提供数据采集、加工、查询与分析、可视化、告警、消费与投递等功能，用户可以基于SLS快速构建一套完整的可观测平台。iLogtail企业版作为SLS官方标配的采集器，承载了业务数据采集的职责，而iLogtail社区版正是从企业版发展而来的，功能及性能自然也继承了企业版的绝大部分能力。
iLogtail发展历程
iLogtail的前身源自阿里云的神农项目，自从年正式孵化以来，iLogtail始终在不断演进。
诞生初期，面对阿里云自身和早期客户运维和可观测性需求，iLogtail主要解决的是从单机、小规模集群到大规模的运维监控挑战，此时的iLogtail已经具备了基本的文件发现和轮转处理能力，可以实现日志、监控实时采集，抓取毫秒级延迟，单核处理能力约为10M/s。通过Web前端可支持中心化配置文件自动下发，支持W+部署规模，上千采集配置项，实现日10TB数据的高效采集。
5年，阿里巴巴开始推进集团和蚂蚁金服业务上云，面对近千个团队、数百万终端、以及双11、双12等超大流量数据采集的挑战，iLogtail在功能、性能、稳定性和多租户支持方面都需要进行巨大的改进。至7年前后，iLogtail已经具备了正则、分隔符、JSON等多个格式日志的解析能力，支持多种日志编码方式，支持数据过滤、脱敏等高级处理能力，单核处理能力极简模式下提升到M/s，正则、分隔符、JSON等方式20M/s+。采集可靠性方面，增加文件发现Polling方式兜底、轮转队列顺序保证、日志清理丢失保护、CheckPoint增强；进程可靠性方面，增加异常自动恢复、Crash自动上报、守护进程等。通过全流程多租户隔离、多级高低水位队列、配置级/进程级流量控制、临时降级等机制，支持百万+部署规模，千级别租户，10万+采集配置项，实现日PB级数据的稳定采集。
随着阿里推进核心业务全面上云，以及iLogtail所属日志服务（SLS）正式在阿里云上商业化，iLogtail开始全面拥抱云原生。面对多元的云上环境、迅速发展的开源生态和大量涌入的行业客户需求，iLogtail的发展的重心转移到解决如何适应云原生、如何兼容开源协议和如何去处理碎片化需求等问题上。8年iLogtail正式支持docker容器采集，9年支持containerd容器采集，年全面升级Metric采集，年增加Trace支持。通过全面支持容器化、K8SOperator管控和可扩展插件系统，iLogtail支持千万部署规模，数万内外部客户，百万+采集配置项，实现日数十PB数据的稳定采集。
年11月iLogtail迈出了开源的第一步，将Golang插件代码开源。自开源以来，吸引了数百名开发者的
转载请注明：http://www.0431gb208.com/sjszlff/3741.html
