本文共 2534 字，大约阅读时间需要 8 分钟。
本文PPT来自于2017年云栖大会TI Serverless专场阿里云龙悟分享的《Serverless下日志处理的挑战和展望》整理而成。
由于Serverless的诸多优点，现在越来越多的应用采用Serverless的架构，如上图所示，一个典型的Serverless架构 ：
- Api网关作为用户访问的入口，是各类web、手机等客户端的访问入口
- 应用的静态资源如图片、视频等可放在对象存储OSS上
- 表格存储保存各类meta信息
- 函数服务FC承载应用的核心处理逻辑
在应用采用Serverless架构的情况下，已经没有应用服务器，应用逻辑以事件为驱动进行触发，这样的改动对于应用的开发、运维、运营、客服都提出了更高的要求和不小的挑战。通常来说，日志数据对于一个应用来说至关重要，关系到应用的稳定，以及能否持续、健康发展。那么在Serverless场景下，日志数据处理又有哪些挑战呢？
- 采集多源：是否能够足够高效地从各类数据源（web、手机客户端，api网关、函数服务等）快速、方便、实时进行数据采集；
- 运营管理成本：维护这样一个日志平台需要投入多少人力、时间、机器资源；
- 响应速度： 对于开发、运维、运营、客服等人员，是否都可以方便、便捷地使用这个日志平台来满足各自多样的需求
通常，构建一个完整的日志平台，需要使用多种开源系统，其中典型的代表有kafka，elk，hadoop，spark，storm等，以及用于数据采集的各类agent（logstash，fluentd，beats等），这些软件和系统用于解决特定的问题，只有有机地把这些系统组合才来才能最终达到业务目标，但要能够稳定运行好这些系统，可不是一件容易的事情。
阿里云的日志服务提供了另外一种解决思路，以云服务的形式，提供一站式日志解决方案，集合日志多源采集、存储、实时分析和dashboard展示、数仓对接等丰富功能，来满足多种人员的各类需求。这样在即满足需求的情况下，又免去了维护多个复杂系统的代价，大大降低了日志分析的时间成本。
- 通过嵌入web tracking js代码，可方便地采集客户端的行为日志；
- 通过SDK，API网关的日志、应用APP中的日志实时将日志写入logstore中；
- 产生在函数服务的日志，通过一行配置，FC会自动将stdout的日志采集至日志服务中；
当日志写入用户project的logstore之后，可以根据数据流量，进行秒级动态扩容、缩容。配置索引之后，各类人员可以直接使用。
接下来，我们以日志处理中几个通用场景为例，来说明如何方便地使用日志服务解决实际问题。
在DevOps场景下，基于阿里巴巴内部的使用经验，我们将ops的时间进行划分，其中最耗时的部分是问题调查，而问题调查往往需要从多个维度进行综合的分析，才能准确定位问题的根源： - Metric ： 各类系统、应用指标，常见的如cpu、mem指标，应用访问延时等
- AdHoc Query ：各类条件组合进行的查询，如查询来之某个用户的访问正确率，某个页面的延时等
- Tracing ：对于单次访问的一个完整调用路径，通常可通过访问request id在各个系统中进行关联
- Log、上下文 ：详细的日志数据，以及和关键日志有关联的上下文日志
以下，我们以DevOps下的AdHoc query和tracing、上下文为例来演示如何使用日志服务：
首先，这个查询样例是， 某个用户对某个特定页面进行访问，出现错误或者延时超过1秒的请求情况。我们可以看到，这样的查询方式非常的灵活，可以对各种条件进行自由组合，通常会使用关键词查询、数值比较、模糊查询来进行组合。使用阿里云日志服务，日志写入1秒和即可查询，每次查询，在1秒内，可处理数亿的日志，从容应对海量日志。
接下来，如果当有用户反馈有访问异常的情况下，就可以通过Tracing + 上下午的方式，快速进行定位。
演示视频:
在这个视频中，首先通过用户的id找到错误的访问请求(1)；再根据这个request id快速在应用日志中找到核心日志(2)，发现错误根本原因是后端缓存队列已经满了，不能请求进行更多的请求；通过核心日志的上下文查询功能，快浏览在出核心错误日志上下文日志(3)，用于快速定位问题。
在以上视频样例中，我们快速分析在一个网站上，售卖价格超过100元的商品中，访问次数最高的top 10的商品，分析的结果以饼图的形式来表示。日志服务的sql查询，支持了sql 92绝大部分语法功能，可在1秒内，对1亿条日志进行多个维度统计分析。
转载地址：http://rownm.baihongyu.com/