本文链接：https://blog.csdn.net/yunqiinsight/article/details/80059823

摘要：目前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相对更加成熟，在性价比上具有绝对的优势。

原文链接

阅读更多干货好文，请关注扫描以下二维码：