Serverless与日志
Serverless，即一种无服务器化的思维，开发者不用过多地考虑传统的服务器采购、硬件运维、网络拓扑、资源扩容等基础设施运行问题，让DevOps人员可以将精力回归到业务本身的创新性、稳定性上来。
在绝大部分场景下，使用Serverless架构是一种双赢的选择：
- 用户按照运行时间或消耗的资源付费，每一笔支出都是实际用到的，避免了浪费；同时，使用云计算厂商提供的Serverless服务降低了诸如基础运维带来的企业人员成本。
- 对于Serverless服务提供商而言，众多用户使得云端资源使用率进一步得到优化，让计算更加“绿色”。
Serverless趋势与挑战
容器是Serverless领域的大热门，以其对微服务的良好支持、成本优化，它从诞生以后发展非常迅速。以致于前Kubernetes联合创始人Brendan Burns就曾谈到“未来是由容器主导的，并且这些容器本身也是运行在Serverless的基础设施上“（参考）。
随着Serverless在IT市场格局的不断成长，日志作为后台支撑正成为传统向Serverless架构转变过程中非常关键的一环。引述一张来自serverless.com的统计：
可以看到Severless化的前三项挑战是：Debuging、Monitoring、Testing，都属于DevOps方向的经典问题。Serverless来自运营、运维、安全、管理层面的需求与开发层面上同样迫切。而日志正是解决软件开发诊断、系统监控、安全、运营问题的重要手段。
在Servlerless趋势下，日志是不可忽视的重要角色：
- 业务架构向Serverless的演进正在发生，解决日志采集、存储问题的日志集中化是挑战之一。
- 日志成为很多Serverless场景的强依赖：诊断、监控、DevOps，各类日志分析需求是挑战之二。
Serverless应用的日志集中化
日志集中化是开启分析的前提，包括日志的采集和存储。传统的日志集中化是将日志文件数据从分散的服务器上采集到服务端。在Serverless下面对的需求更加复杂：各种各样形态的数据源，对数据存储的可靠性存储以及后续大数据分析需求。
广义的Serverless，可以分为三类：
- Container as a Service，容器即服务
常见形态有：通过Docker或Kubernetes等软件来部署、管理容器；云服务商提供的host容器、全托管服务（例如：阿里云容器服务、Serverless Kubernetes）。
容器的特点是弹性，在系统运行过程中容器会动态创建出来或被销毁掉，要求动态的日志采集能力，并且传统服务器上的日志采集方案无法直接移植过来。
容器场景下的日志业务种类多，例如微服务、Kubernetes pod有很多类别日志可能分散在多台宿主机上。容器级别的日志采集点设置繁琐易出错且管理成本高。
- Backend as a Service，后端即服务
BaaS是一种更广泛意义的Serverless，可以是存储、host软件、关系型数据库、NoSQL数据库、消息队列、API服务等多个方向上的无服务器化。最早的商业化Serverless平台可能要追溯到谷歌的App Engine，如今AWS、阿里云、Azure等大厂都提供了丰富的云服务。
使用云服务的过程中，用户需要审计日志、服务访问日志、网络流量日志等等。这些日志的采集门槛在于用户无法通过客户端抓取数据。云服务日志采集需要具备实时能力，例如负载均衡（SLB）、对象文件存储（OSS）、自定义网络访问（VPC）、内容分发下载（CDN）等系统处于业务架构的核心链路上，运维监控、风险安全等场景都对实时日志有很强需求。同时，业务的流量峰谷会直接反应到云服务日志的流量上，例如网站会在晚9点后PV走高，就会对应到SLB访问日志量飙升，高吞吐采集和弹性伸缩的日志存储能力是必须的。
- Function as a Service，函数即服务
FaaS是在计算层面的Serverless，正在快速发展，根据BusinessWire的报告，预计到2021年其市场规模会增长到77.2亿美元。典型的代表有：阿里云FunctionCompute、AWS Lambda。它实现了更细粒度的资源租用，按照每一次执行来付费。用户可以通过写代码、配置一些参数来搭建自己的应用。
FaaS的函数实例由触发器或用户主动触发，日志的生命期在函数运行完成后也会结束。第一个需求是有快速的方案将函数运行过程中产生的日志持久化下来。第二是在完成日志收集后，针对不同类型的运行日志、函数运行指标能够完成诊断层面或监控层面的分析需求。
一张图总结如下：
多样化的日志分析需求
可以按照日志的时效性（从秒到年）、面向的用户，从两个维度列举了主要的日志分析需求：
- 开发人员关注实时的日志内容、程序的异常，要求交互的Debug体验和快速的异常模式发现。
- 运维人员关注系统的监控大盘，要求实时的系统、业务指标告警。
- 运营人员通过日志为业务发展制定策略，对每个用户画像实现精细化需求匹配。
- 管理者从日志分析中拿到他所关心的业务营收发展、用户增长情况。
阿里云日志服务的核心能力
阿里云日志服务是针对日志数据一站式服务，提供日志类数据采集、消费、投递及查询分析功能，可以帮助用户提升海量日志处理、分析能力。本节介绍日志服务的三项核心能力，帮助大家为后续的两个Serverless日志实践建立基础背景。
统一的日志采集、管理平台
日志服务提供了相对完整的采集工具或方案支持四个主要场景：从传统服务器（日志、metric），到应用程序（自定义日志），到嵌入式IOT、移动设备（WebTracking、metric、日志等），再到本文的主题Serverless应用（云服务、容器、FaaS的日志或metric）。可以帮助用户将各类数据快速接入到阿里云端的日志服务存储上。
同时，日志服务是一个多租户的平台，通过Shard水平扩展可以支持写入、存储能力的弹性伸缩。各式各样的数据可以存储到不同的日志库（LogStore）中去，满足后续联合分析、分类管理需要。
实时交互的计算分析
将日志统一采集到集中式的数据存储平台后，传统ETL将存储对接各类计算工具来满足复杂多样的需求。比如：
- 将数据做流式计算，结果存储到数据库，用BI报表加载数据库进行业务指标展示。
- small batch对数据构建全文索引，正排和倒排两份存储联合起来支持关键词查询需求。
- 在原始数据上进行计算得到中间结果，在中间结果之上应用告警规则，满足阈值后即触发告警通知。
首先这个业务架构更加复杂化了，完成N个场景需求，需要在存储层对接M个系统；并且需要这些下游系统的专业人员来开发对接、保障稳定性，增加了企业的人力成本和业务时间成本。
日志服务对不断流入的数据实时构建索引，提供LogSearch（全文检索）和LogAnalytic（SQL分析）功能。面向不同的需求，开放给用户统一的用户层接口（查询语句）。不同用途的SQL查询提交给计算引擎得到结果，并结合相应的可视化或通知方式来完成报表分析、实时告警、关键词查询。这个过程可以覆盖日志场景下的主流刚需，具有以下两个特点：
- 动态：动态SQL（用户需求随时变化）在动态数据（实时日志不断产生）上完成计算，秒级返回用户结果。
- 交互：完成一个较复杂的问题诊断或分析往往需要多次交互过程，比如：开发者在收到业务日志的告警信息后，可以根据告警内容快速drill-down到对应的指标仪表盘上查看整体趋势，从仪表盘上点击一个异常指标可以继续drill-down到与之关联的日志上下文上查看内容明细。
开放、连接的日志下游生态
日志服务是开放的系统，存储的数据可以很方便地与其它大数据系统做集成。下面是日志服务下游生态图，展示了在线分析、流式计算、数仓归档、可视化四个主要场景下所支持的消费系统。
总结来说，日志服务的下游生态分为三个层面：
与阿里云产品融合
- 存储: 数据投递到OSS、MaxCompute、 TableStore
- 计算: 支持FunctionCompute触发器, 与Blink, EMR计算系统集成
- 分析、可视化 : 通过ARMS、DataV完成系统监控、数据大盘
与社区生态合作
- 计算: 对接Flink, Storm, Spark, Hive等大数据系统
- 分析、可视化: 支持Jaeger, jdbc, Grafana等数据集成
- 与第三方日志厂商打通（进行中）
实践一：负载均衡访问日志在线分析
阿里云SLB是对多台云服务器进行流量分发的负载均衡服务，可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。“SLB+ECS”是阿里云上的一套经典业务系统架构，本节内容将介绍SLB访问日志的在线分析实践。
开启SLB访问日志
访问日志记录了一次完整的用户请求，是服务异常诊断的必备。SLB记录的七层访问日志相较于在后端ECS上用Nginx记录accesslog，更是有以下两点优势：
- 字段更完整：包括了vip，upstream_latency等信息
- 来源更广泛：涵盖少部分请求未至后端服务器情况
SLB的七层访问日志可一键开通采集到日志服务。其核心链路是在Tengine Proxy上记录请求日志并按照用户的定义的规则转发到用户的日志服务日志库（LogStore）存储。
整个过程的处理延时在秒级，对比业界的“T+1”或小时级延迟日志交付，具有明显的优势。另外，日志服务LogStore支持Shard扩展和自动分裂，可以按照写入流量的变化动态扩容写入、存储能力，帮助用户顺利度过业务高峰时数倍的流量增长。
基于SLB访问日志的业务告警
访问日志中关于请求延时的几个字段：
| 字段 | 说明 |
|---|---|
| client_ip | 请求客户端ip |
| vip_addr | vip地址 |
| upstream_addr | 后端服务器的IP地址和端口 |
| request_time | proxy收到第一个请求报文到返回应答的间隔时间，单位：秒 |
| upstream_response_time | 从SLB向后端建立连接到接受数据完成后关闭连接耗费的时间，单位：秒 |
| status | proxy应答报文的status |
| upstream_status | proxy收到的后端server的响应status |
在日志服务上配置一个告警任务，使用以下SQL计算最近15分钟各ECS Real Server上处理Latency的时间趋势：
* | select date_format(__time__, '%m-%d %H:%i:%s') as t, upstream_addr, avg(upstream_response_time) * 1000 as avg_upstream_response_ms group by t, upstream_addr order by t asc limit 1000配置秒级平均延时超过阈值100 ms时，发送短信通知：
结合drill-down进行交互分析
如下短视频演示了：
- 从SLB运营报表中，根据错误码499深钻到原始日志查看细节，并使用SQL统计：499状态码下top10 request_time的客户端ip来源信息
- 从SLB运营报表中，选中一个SLB实例ID深钻到SLB访问中心，查看该实例的细节报表统计
drill-down使得在报表和日志查询之间可以顺畅地完成跳转，衔接DevOps人员的诊断思路。
实践二： Kubernetes日志采集与诊断分析
Kubernetes日志采集的难点
目前各大云服务商上都提供了host Kubernetes服务，也称为Serverless Kubernetes，对比与经典Kubernetes，用户将不再关心集群与机器，只需要声明容器的镜像、CPU、内存、对外服务方式就可以启动应用。
如下图，在从左向右发展的过程中，日志采集也变得复杂：
- 单Kubernetes node上可能会运行更大规模量级的pod，且每个pod都可能需要采集日志或监控指标，意味着单node上的日志量会更大。
- 单Kubernetes node上可能会运行更多种类的pod，日志源类别的多样化对于日志的采集管理、打标需求也更加迫切。
Kubernetes最原生的日志方案是通过kubectl logs命令行工具，容易上手但是容器崩溃或释放后数据会丢失，并且没有办法结合云上、开源的数据分析工具做分析。因此，官方给出了基于SideCar采集方案，在每个pod内有一个业务容器和一个采集客户端容器，采集客户端容器负责该pod内业务容器的数据采集上报工作。
Sidecar方案本质上是将业务系统与日志系统解耦，它解决了日志持久化存储等基本的需求，但在两个地方上仍有待提升：
- 单Kubernetes node上如果运行了N个pod，就意味着会同时运行着N个日志客户端进程，造成CPU、内存、端口等资源的浪费。
- 为每个Kubernetes pod管理采集配置（采集日志目录，采集规则，存储目标等）非常繁琐，不易维护。
使用Logtail进行Kubernetes日志采集
日志服务使用Logtail（日志服务自研的数据采集客户端）用以补充Kubernets官方基于Fluentd Agent的Sidecar方案，来尝试解决Kubernetes场景下日志处理的一些细节体验问题。
Logtail采集是一种Kubernetes节点级方案，在每个Kubernetes Node上，部署Logtail DaemonSet用于采集该节点下所有容器产生的日志。并且当节点上部署AliyunLogController helm后，就可以监听到节点上的容器、目录变化，用户可以通过CRD配置采集，由AliyunLogController向日志服务申请存储资源、创建采集点。
动态采集支持
- 通过domain socket与docker engine通信来处理该节点上的容器动态采集。增量扫描可以及时地发现node上的容器变化，再加上定期全量扫面机制来保证不会丢失掉任何一个容器更改事件，这个双重保障的设计使得在客户端上可以及时、完整发现候选的监控目标。
- 针对Kubernetes场景，Logtail设计了自定义标识方式来管理机器。一类pod可以声明一个固定的机器标识，Logtail使用这个机器标识向服务端汇报心跳，同时机器组使用这个自定义标识来管理Logtail实例。当Kubernetes节点扩容时，Logtail上报pod对应的自定义机器标识到服务端，服务端就会把这个机器组上的挂载的采集配置下发给Logtail。目前在开源采集客户端上，常见的做法是使用机器ip或hostname来标识客户端，这样在容器伸缩时，需要及时去增删机器组内的机器ip或hostname，否则就会导致数据采集的缺失，需要复杂的扩容流程保证。
数据管理支持
- 将日志从源到目标（日志库）定义为一个采集路由，使用传统方案实现个性化采集路由功能非常麻烦，需要在客户端本地配置，每个pod容器写死这个采集路由，对于容器部署、管理会有强依赖。Logtail解决这个问题的突破点是对环境变量的应用，Kubernetes的env是由多个key-value组成，在部署容器时可以进行env设置。Logtail的采集配置中设计了IncludeEnv和ExcludeEnv配置项，用于加入或排除采集源。例如，业务容器启动时设置log_type环境变量，同时Logtail采集配置中定义了IncludeEnv: log_type=nginx_access_log，来指定收集nginx类用途的pod日志到特定日志库。
- 在数据采集阶段Logtail记录了Kubernetes namespace、pod、container维度的原始文件的位置信息，结合日志服务查询功能高效实现了在分布式存储系统上的日志上下文查看功能，类似Linux上的
grep -A -B和tail -f。细节参考日志上下文查询的设计。
Kubernetes日志的在线诊断
传统的Linux开发者使用grep/tail工具对日志进行实时排查。基于日志服务的实时采集和查询能力，如下短视频中会演示如何完成对Kubernetes日志的在线诊断：
- 在日志分析模式下，以namespace、pod、container三者作为关联日志context-id，点击LiveTail浏览日志原始的上下文信息
- 在LiveTail模式下日志会实时滚动加载，输入关键词可以进行日志过滤和内容飘红，页面上方的historgram展示了每个细粒度时间窗口下的日志产生速率
- 当我们在LiveTail模式下发现了一个值得关注的错误后，可以点击它drill-down回日志分析页面
Kubernetes日志数仓
目标场景：希望做到日志的极低存储成本，将冷热数据分别存储的同时也兼顾ad-hoc分析，例如每天会跑一次全量数据计算。
那么，可以选择：在日志服务上存放近1天的热数据用作问题诊断、业务告警，同时开启数据一键投递OSS，那么日志服务会以分钟粒度将数据复制一份到OSS。
- 全托管投递OSS
日志服务按照用户设置的时间或大小策略触发投递任务，任务运行以Serverless方式提供全托管服务，支持以行存（JSON、CSV）、列存（Parquet）格式文件写入OSS。
- OSS存储
投递到OSS的文件支持Parquet列存储内置压缩或snappy通用压缩格式，同时结合OSS低频存储类型可以最优化存储费用。
- 存储计算分离
OSS上的数据可以结合阿里云Data Lake Analytics、HybridDB、EMR等大数据引擎进行计算，例如：投递到OSS的文件目录结构可以可以拆分为bucket、prefix、datetime三级并分别映射到数仓计算Hive-style的project、table、partition，优化数据扫描过滤的性能。
结语
本文重点介绍了Serverless的发展以及这个浪潮下日志所扮演的角色，并通过阿里云日志服务提供的实时采集、可靠存储、交互式分析能力，为用户搭建Serverless应用日志处理架构提供了两个实践参考。
