数字化运营基础
在如今“双十一”不再是线上活动的代名词，而逐步变为一场线上线下同时进行的消费者盛宴。销售、运营、物流、生产商等都在开足马力在各大渠道备战，据统计：
- 消费者在期间被平均推送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的基础。让我们来看一个典型的数据采集架构：
- 购买一批机器搭建网络服务器
- 为服务器搭建负载均衡设备
- 在网络服务器（例如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， 具备稳定、可靠、低成本，生态丰富等特性。
阿里云官网上提供同款产品，只要5分钟便可开通并开启数字化IT之旅，欢迎试用。