摘要: 目前logtail已承载阿里云全站、所有云产品服务、全球各Region部署、阿里巴巴集团(淘宝、天猫、菜鸟等)上重要服务的数据采集。每天采集接近百万服务器上数PB的实时数据,对接数千个应用与消费者。
什么是日志
提到日志,很多人的第一印象就是系统打到本地的Log文件,出问题的时候看一下这个Log文件,用来排查问题。更进一步可以根据这个Log文件做实时的监控、第三方审计、入侵检测、行为分析、数据大盘制作等等。
马老师说过:阿里巴巴不是零售,我们是一家数据公司,为了数据才做电商、做物流、卖东西。我们认为日志是记录世间人和物所有行为的一种方式,是数据中极其重要又极其庞大的一个组成部分。会产生日志的设备有:服务器、交换机、手机、传感器、IOT设备、智能设备...产生的日志类型有:网络的七层日志、OS日志、订单日志、支持日志、GPS定位日志、用户点击日志...产生的日志形式有:文本文件、二进制文件、syslog、udp日志...如何充分利用这些日志资源才是我们的核心技术和竞争力。
什么是日志采集
数据的价值是什么?数据的价值在于把数据变成行动。这里一个非常重要的过程是数据分析。提到数据分析,大部分人首先想到的都是Hadoop、流计算、机器学习等数据加工的方式。如果从整个过程来看,数据分析其实包含了4个过程:采集,存储,计算和理解四个主要步骤:
- 采集:从各种产生数据的源头,将数据集中到存储系统。包括硬盘上的历史数据、用户网页的点击、传感器等等。
- 存储:以各种适合计算的模式集中式存储数据,其中既包含大规模的存储系统(例如数仓),也有例如临时的存储(例如Kafka类消息中间件)。
- 计算:形态多种多样,但大部分计算完成后会将结果再放入存储,而这个过程也可能迭代多次。
- 理解:利用机器学习、可视化、通知等手段提炼出结论性或具有代表意义的数据并将结果呈现出来。
数据的采集是一门很大的范畴,从实时性上和每次传输数据规模上分,一般可以分为3类:
- 实时采集:例如access log、database change log等
- 定时任务:例如每隔5分钟从FTP或数据源去批量导出数据
- 线下导数据:例如邮寄硬盘、AWS Snowmobile 卡车、阿里云的闪电立方等
从数据的价值以及体量上而言,实时数据采集毫无疑问最重要的,而其中最大的部分就是日志实时采集。
为何使用Agent
实现日志的实时采集一般有2种方式:
- 直接上传:在应用程序(或依赖的框架)中将日志直接上传到服务端。例如各种日志上传的SDK、Log4j的appender、docker driver等
- 通过Agent采集:应用本身只产生日志,由Agent作为代理采集到服务端。例如将日志打到磁盘、syslog转发、从中间框架(docker engine、mysql、应用自带的monitor模块)中抽取等
下面我们来详细剖析一下二者区别:
对比项 | 直采 | Agent |
---|---|---|
实现复杂度 | 高,需要针对不同的应用/设备/日志存储端分别实现 | 低,无需专门实现 |
性能开销 | 低,直接上传,无额外性能开销 | 较高,需要一层中转,例如本地磁盘、网络等,有一部分额外开销 |
应用影响 | 高,由于日志采集和应用在同一进程,隔离性很难保证 | 较低,日志采集和应用处于不同进程/设备,采集异常对于应用影响较低 |
耦合度 | 紧耦合 | 松耦合 |
可扩展性 | 低,如果更换采集协议、采集目的端,代价极高 | 高,只需更改Agent,无需对应用本身进行改造 |
可靠性 | 较低,日志随应用生灭,应用crash时数据可靠性很难保证 | 较高,通常由磁盘/中间框架实现持久化,具备一定的可靠性 |
从以上分析来看,两种采集方式各有优缺点、也有各自适应的场景:
- 直采:适用于对性能/资源要求较高的场景,例如IOT/智能设备等对于资源要求极高,没有额外的资源独立部署采集Agent;例如负载均衡设备、CDN节点等日志产生量极高(每秒数百MB或者数GB的日志),只有直接上传方能满足性能要求
- Agent采集:只要应用可以将日志输出(以文件形式保存到磁盘、syslog等)或者支持通用的接口拉取,Agent即可将日志采集到。大部分场景下松耦合、可扩展性、可维护性相比Agent额外开销更具优势
为何选用Logtail
日志采集Agent有很多,例如Logstash、Fluentd、Beats系列(FileBeats、MetricBeats、Packetbeat、Winlogbeat、Auditbeat、Heartbeat)、Nxlog、Telegraf、Heka、Nifi、Logspout、Datadog agent、Sematext agent、Splunk addon系列、Sumologic collector。。。
业界有那么多的Agent,每个Agent各种各样的功能和特性看起来让人眼花缭乱。但围绕日志采集这个最原始的需求展开,无非也就是功能、性能、稳定性、运维代价这4个方面:
- 功能:作为选择Agent最基本需求,主要分为输入源、数据处理(除日志解析外,还包括过滤、压缩等)、数据输出。
- 性能:不同类型Agent之间会有数十倍的性能差距。当日志产生速率较低且资源充足时,此项可以忽略;但大部分情况下采集Agent是作为整个集群的基础软件,在集群规模庞大的情况下,即使每台机器节省1%的CPU、10MB的内存也是很大一笔资金节省。
- 稳定性:稳定的重要性无需多言,除保证自身运行的稳定外,Agent还需保证不能超出限定的资源使用Quota,以免对应用产生影响。
- 运维代价:日志采集的运维主要包括:Agent部署、动态伸缩、配置管理、Agent升级、Agent异常监控。当只有数台主机时,Agent可以使用人肉的方式进行管理,但当集群规模扩大到数百及以上时,运维必须依赖有效的机制。
阿里云日志服务也有自己的采集Agent--Logtail。目前logtail已承载阿里云全站、所有云产品服务、全球各Region部署、阿里巴巴集团(淘宝、天猫、菜鸟等)上重要服务的数据采集。每天采集接近百万服务器上数PB的实时数据,对接数千个应用与消费者。之所以使用Logtail作为采集Agent也是经过上述四个方面的综合考虑。由于采集Agent数量众多,这里我们选择目前最主流的3款Agent进行对比:
Logtail | Logstash | Fluentd | Beats系列 | ||
---|---|---|---|---|---|
功能 | 文本文件采集 | 支持 | 支持 | 支持 | 支持 |
syslog | 支持 | 支持 | 支持 | 不支持 | |
处理方式 | 正则、anchor、分隔符、json任意组合 | 插件扩展 | 插件扩展 | 只支持multiline | |
过滤 | 正则 | 插件扩展 | 插件扩展 | 不支持 | |
压缩 | lz4 | 插件扩展 | 插件扩展 | 支持 | |
功能扩展 | 支持插件 | 支持插件 | 支持插件 | 支持(修改源码) | |
性能 | 采集性能 | 极简单核160M/s、正则20M/s | 单核2M/s左右 | 单核3-5M/s | 极简单核15M/s |
资源消耗 | 平均CPU 2%、内存 40M | 10倍以上性能消耗 | 10倍以上性能消耗 | 内存消耗较低 | |
稳定性 | 多租户隔离 | 自实现的隔离 | 线程级隔离 | 线程级隔离 | goroutine隔离 |
硬性资源限制 | 支持 | 支持 | 支持 | 不支持 | |
资源动态调整 | 支持 | 不支持 | 不支持 | 不支持 | |
数据保存 | 支持 | 插件支持 | 插件支持 | 不支持 | |
进程守护 | 支持 | 辅助软件支持 | 辅助软件支持 | 辅助软件支持 | |
采集点位保存 | 所有均支持 | 只支持文件 | 插件支持 | 只支持文件 | |
运维代价 | 本地监控 | 支持 | 支持 | 支持 | |
服务端监控 | 支持 | Beta版本支持简单功能 | 辅助监控软件扩展 | 不支持 | |
集群自动缩扩容 | 自定义标识机器组 | 不支持 | 不支持 | 不支持 | |
运行时配置变更 | 支持 | 支持 | 支持 | 支持 | |
服务端配置管理 | 支持 | Beta版本支持简单功能 | 辅助软件扩展 | 不支持 | |
自动升级 | 支持 | 辅助软件扩展 | 辅助软件扩展 | 不支持 |
相对主流的采集Agent,Logtail在采集功能上有一定的不足,对于输入源、处理方式等支持没有开源软件的多,但从目前的功能来看,可以满足95%以上的日志采集需求。但日志采集并不是能够采集到就可以。相对开源软件,Logtail的优势是有集团百万服务器、上万应用的练兵环境,很多问题纯粹从Agent和开源社区的角度并不会考虑到。因此经历了数年的迭代优化,在性能、稳定性、运维代价上,Logtail相对更加成熟,在性价比上具有绝对的优势。
原文链接
干货好文,请关注扫描以下二维码: