数字IT基础-数据采集总线

摘要： 日志服务是阿里自产自用的产品，在双十一、双十二和新春红包期间承载阿里云/蚂蚁全站、阿里电商板块、云上几千商家数据链路，每日处理来自百万节点几十PB数据，峰值流量达到每秒百GB， 具备稳定、可靠、低成本，生态丰富等特性。

数字化运营基础

在如今“双十一”不再是线上活动的代名词，而逐步变为一场线上线下同时进行的消费者盛宴。销售、运营、物流、生产商等都在开足马力在各大渠道备战，据统计：

• 消费者在期间被平均推送200+活动消息
• 消费者会花几个小时比较、提前筛选自己中意产品
• 除了线上外，90%线下店铺都挂出针对双十一运营活动

双十一触客渠道也呈现多样化，例如：网络店铺、短信、邮件、微信公众账号、派单与Kitty板、自提柜、智能设备（例如天猫精灵点单）、多媒体设备（例如电视或机顶盒购物）等。

面对如此多的渠道和销售方式，运营和销售如何有效掌控，并通过数字化方式进行运营是一项硬能力。让我们来看几个例子：

例子1：新用户引流

互联网经典书籍《上瘾：构建习惯养成的产品》把用户获取过程分为4个阶段：触发、行动、奖励、投入。作为最开始的触发环节，给用户群发消息是最有效的手段之一。但如何衡量转化效果呢？

我们可以在推广信息中做一个埋点，把用户点击短信带上关联信息，例如设计一个如下的URL，其中放入2个关键参数：

• t: 代表发送的批次编号，也可以作为渠道的标识
• m：代表发送的短信号码

html://mywebsite.com/new?t=1002&m=13860394XX

当用户点点击消息访问站点时，我们在服务端访问日志中会自动记录对应信息:

202.168.1.209 - - [02/Feb/2016:17:44:13+0800] "GEThtml://mywebsite.com/new?t=1002&m=13860394XX  HTTP/1.1" 200 209 - "Mozilla/5.0(Macintosh; Intel Mac OS X10_11_3) AppleWebKit/537.36(KHTML, like Gecko)Chrome/48.0.2564.97 Safari/537.36"

这样我们就能获得推广效果和转化率：

例子2：线上购买意图捕捉

在获取客户后，下一步是让用户付诸于行动。用户在浏览商品时，会有页面的停留，阅读，比较和加入购物车等操作。可以借助Web Tracking和Serve端埋点来进行静态与动态数据采集。

在静态网页和浏览器埋点：

<img src=‘http://${project}.${sls-host}/logstores/${logstore}/track_ua.gif?APIVersion=0.6.0&key1=val1&key2=val2’/> 

通过JS埋点：

varlogger = new window.Tracker('cn-hangzhou.log.aliyuncs.com','ali-test-tracking','web-tracking');
logger.push('customer','zhangsan');
logger.push('product','iphone6s');
logger.push('price',5500);
logger.logger();

在完成数据埋点后，我们可以在日志服务分析功能中，获得每个环节的点击数和转化数字，以衡量购买阶段的效果。

Web Tracking链接：https://help.aliyun.com/document_detail/31752.html
服务端埋点链接：https://help.aliyun.com/document_detail/28979.html

数据采集挑战

从上面例子来看，数据采集是数字化IT的基础。让我们来看一个典型的数据采集架构：

1. 购买一批机器搭建网络服务器
2. 为服务器搭建负载均衡设备
3. 在网络服务器（例如Nginx）模块中使用Kafka等中间件写入数据

该方案通过无状态设计解决了高可用，按需扩容等问题，也是众多厂商采用的方案，在理想状态下运行得非常好。但在现实过程中，往往会遇到如下挑战：

步骤	模块	挑战	成本
端	协议封装与客户端开发	需要开发众多SDK，例如Android、IOS、嵌入式等	研发成本、运维
	客户端传输	面向网络不可用	断点续传功功能
	客户端传输	传输过程中安全问题	HTTPS协议支持与证书
	客户端升级	客户端如果有Bug如何升级	运维成本
传输	网络质量差	网络质量差	购买昂贵专线
	地域与合规	用户数据不能出国，例如欧盟等协议	在全球建各数据中心
	网络选择	运营商速度、质量不一，质量差	购买第三方加速服务
服务端	扩容	流量上涨时，如何自动扩容	购买服务器、手动运维
	防攻击	采集服务器可能被DDOS	运维服务器
	认证	进行用户认证与管理	开发负责的认证与管理模块
	数据加工	数据到服务端后，增加来源IP、服务端时间等字段	服务端开发成本
	上下游对接	对接各种流计算、离线处理系统	硬件采购、程序开发与维护

作为用户最终的目标是为了分析数据。但这些问题的存在，需要在业务、规模与增长上消耗大量人力、精力和物力，干了不一定干得好。

日志服务LogHub功能

阿里云日志服务（Log Service，/原SLS）是针对实时数据一站式服务，其中的LogHub模块就是专为数据采集定制的功能，该功能有如下特点：

1. 30+实时采集手段

LogHub提供30+种开箱即用的数据采集手段，包括直接和云产品打通的日志、移动端、服务端、程序、SDK、网页、嵌入端等，以下我们分别介绍下最常用的四种与试用场景：

方式	应用场景	当前规模	优势
Logtail	X86服务器采集	百万-千万	功能强
Android/IOS SDK	移动端数据采集、手机、POS机等	千万DAU	断点续传
C Producer Library	硬件资源受限的系统（如 IoT、嵌入式、RTOS等）	千万-亿级	资源消耗低
Web Tracking	网页静态数据采集	千万-亿级	轻量级，无验证

1.1 Logtail（部署量最大Agent）

Logtail安装在X86设备上，通过中央服务器进行管控，只需点点鼠标或API就能够在几秒钟内对百万机器下达数据采集指令。Logtail目前每天有几百万的运行实例，适配所有Linux版本、Window、Docker、K8S等环境；支持几十种数据源对接，关于Logtail功能可以参见介绍文档。

得益于阿里巴巴集团场景的不断锤炼，Logtail和开源Agent（例如Fluentd、Logstash、Beats）相比，性能、资源消耗、可靠性和多组合隔离等硬指标上较为领先。可以满足国内最大的直播网站、最大的教育类网站、最大的金融类网站的苛刻要求。和开源Agent主要差距在于日志格式的丰富性（当前Logtail版本已支持Logstash、Beats协议，既可以将这些开源插件无缝跑在Logtail之上）。

2018年Logtail针对Docker/K8S等场景做了非常多的适配工作，包括：

• 一条命令一个参数即可实现部署，资源自动初始化
• 支持CRD方式配置，支持K8S控制台、kubectl、kube api等，与K8S发布、部署无缝集成
• K8S RBAC鉴权，日志服务STS鉴权管理

可以自豪地说，Logtail方案是K8S下所有Agent中最全，最完整的之一，感兴趣可以参见LC3视角：Kubernetes下日志采集、存储与处理技术实践 ：

1.2 C Producer Library系列（面向嵌入式设备新秀）

​ 除X86机器外，我们可能会面对各种更底层IoT/嵌入式设备。针对这种场景，LogHub推出C Producer Library系列SDK，该SDK可以定位是一个“轻量级Logtail”，虽没有Logtail实时配置管理机制，但具备除此之外70%功能，包括：

• 多租户概念：可以对多种日志（例如Metric，DebugLog，ErrorLog）进行优先级分级处理，同时配置多个客户端，每个客户端可独立配置采集优先级、目的project/logstore等
• 支持上下文查询：同一个客户端产生的日志在同一上下文中，支持查看某条日志前后相关日志
• 并发发送，断点续传：支持缓存上线可设置，超过上限后日志写入失败
  专门为IoT准备功能：
• 本地调试：支持将日志内容输出到本地，并支持轮转、日志数、轮转大小设置
• 细粒度资源控制：支持针对不同类型数据/日志设置不同的缓存上线、聚合方式
• 日志压缩缓存：支持将未发送成功的数据压缩缓存，减少设备内存占用

关于C Producer Library的更多内容参见目录：https://yq.aliyun.com/articles/304602

目前针对不同的环境（例如网络服务器、ARM设备、以及RTOS等设备）从大到小我们提供了3种方案：

​ 在X86以及ARM设备测试场景中，C-Producer系列SDK能在稳定服务情况下，极大优化性能和内存空间占用，胜任只有4KB运行内存的火火兔场景（Brick版本）。

使用C Producer系列的客户有： 百万日活的天猫精灵、小朋友们最爱的故事机火火兔、 遍布全球的码牛、钉钉路由器、 兼容多平台的视频播放器、 实时传输帧图像的摄像头等。

这些智能SDK每天DAU超百万，遍布在全球各地的设备上，一天传输百TB数据。关于C Producer Library 的细节可以参考这篇文章: 智能设备日志利器：嵌入式日志客户端（C Producer）发布。

2. 服务端多地域支持

​ 客户端问题解决了后，我们来看看服务端。LogHub 是阿里云化基础设施，在全球阿里云所有Region都有部署。确保无论业务在哪个Region开展，都可以选择就近的Region。

例如欧盟、新加坡等国家有相关的法律约束数据不能出境，对于这类场景我们可以选择合适的数据中心来提供服务。对于同Region下ECS、Docker等服务，我们可以直接使用同Region服务进行处理，节省跨洋传输的成本。

3. 全球加速网络

​ 对全球化业务而言，用户可能分布在全球各地（例如游戏，App、物联网等场景），但在构建数仓业务的过程中，我们往往需要对数据进行集中化处理。例如一款移动App用户散布在全国各省市

• 将日志采集中心定在杭州，那对于西南（例如成都）用户而言，远程进行日志传输的延时和质量难以保障
• 将日志采集中心定在成都，那对位于东部和东北用户又难以权衡，更不用说中国的三大运营商链路质量的影响

​ 2018年6月初LogHub 联合 CDN 推出了一款全球自动上传加速方案：“基于阿里云CDN硬件资源，全球数据就近接入边缘节点，通过内部高速通道路由至LogHub，大大降低网络延迟和抖动 ”。只需简单配置即可构建起快速、稳定的全球数据采集网络，任意LogHub SDK都可以通过Global域名获得自动加速的支持。

​ 
在我们测试case中，经过全球7个区域对比整体延时下降50%，在中东，欧洲、澳洲和新加坡等效果明显。除了平均延时下降外，整体稳定性也有较大提升（参见最下图，几乎没有任何抖动）。确保如何在世界各地，只要访问一个统一域名，就能够高效、便捷将数据采集到期望Region内。

4. 服务端弹性伸缩

​ 在解决网络接入问题后，我们把问题聚焦在服务端流量这个问题上。熟悉Kafka都知道，通过Partition策略可以将服务端处理资源标准化：例如定义一个标准的单元Partition或Shard（例如每个Shard固定5MB/S写，10MB/S读）。当业务高峰期时，可以后台Split Shard以获取2倍的吞吐量。

这种方法看起来很工程化，但在使用过程中有两个难以绕开的现实问题：

• 业务无法预测：事先无法准确预估数据量，预设多少个shard才合适呢
• 人的反应滞后：数据量随时会突增，人不一定能够及时处理，长时间超出服务端负载能力会有数据丢失风险

​ 针对以上情况，LogHub提供了全球首创Shard自动分裂功能：在用户开启该功能后，后台系统实时监控每个shard的流量，如果发现一个shard的写入在一段时间内，有连续出现超过shard处理能力的情况，会触发shard的自动分裂，时刻保障业务流量。

更多细节可以参考这篇文章: 支持Shard自动分裂

5. 丰富上下游生态与场景支持

LogHub也提供丰富上下游与生态对接，包括各种主流流计算、数据仓库等引擎支持：

• 采集端：Logstash、Beats、Log4J等
• 实时消费端（流计算）：Flink/Blink、Storm、Samza等
• 存储端（数仓）：Hadoop、Spark、Presto、Hive等

通过LogHub与日志服务其他功能+产品组合，可以轻松支撑安全、运营、运维和研发对于数据处理的各种场景需求，更多可以参考学习路径 和 用户手册。

写在最后

日志服务是阿里自产自用的产品，在双十一、双十二和新春红包期间承载阿里云/蚂蚁全站、阿里电商板块、云上几千商家数据链路，每日处理来自百万节点几十PB数据，峰值流量达到每秒百GB， 具备稳定、可靠、低成本，生态丰富等特性。

 

阅读原文

更多技术干货 请关注阿里云云栖社区微信号 ：yunqiinsight