本文作者 | 王骜

听说这个问题你也遇到了？

小王是一名程序员，最近在使用 FaaS （Function as a Service) 服务时遇到了一个头疼的问题：他的 FaaS 应用出现很多报错，但是调用日志页面的请求太多了，没办法简单、快速地查到出现 bug 的原因。

对小王来说，在开发、运维时查看自己的应用出现错误原本是稀松平常的事情，之前小王可以在服务器本地打印的日志中查看关键字，可以查看逻辑是否正确，再检查下执行环境中的报错信息，错误根因基本就被发现了。现在，当小王把应用部署到云上并且将业务交付给 FaaS 服务商来执行后，却只能依赖于 FaaS 服务商提供的日志解决方案查询相关 debug 信息，没有办法像在服务器上进行调试一样，可以直接调查相关的错误原因并且进行修复。

因为这个问题，小王每天都要在几十、或者上百条调用日志的请求列表中，一点点用眼睛搜索，真的眼睛都要废了, 于是忍无可忍的小王开启了自救模式……

主流函数计算产品如何应对？

小王对比了目前国内的主流函数计算产品，他发现这些产品在日志层面有三个共同点：

1. 均以自家的日志服务系统作为日志存储依托；

2. 向用户暴露请求列表页，每一个请求下包含该请求的所有日志；

3. 均支持跳转到日志服务进行自主查询，支持多函数写入同一个日志仓库

以上三个共同点看起来中规中矩，他们均采用自家成熟的日志服务作为日志存储系统，在保证日志安全性的同时也提供了不错的查询体验；面向请求级别的日志也天然的为用户做了隔离，也符合 FaaS 作为事件驱动的调性；但是均支持跳转到所绑定的日志服务产品这一做法可能会褒贬不一。从全面性和准确性上来说没有任何问题，所绑定的日志服务可以作为用户业务日志的 source-of-truth。

不好的是当用户面临茫茫多的日志信息，其中混杂着多个应用的信息和云服务的配置信息，无疑提高了使用成本，并且想要用好自助查询这一功能，需要较长的学习周期。开发者进行 debug 时最关心的就是 errorStack，但是在日志服务中，映入眼帘的更多是无用的信息。

你需要的和你看到的

阿里云函数计算助你一眼定位问题

优化用户的日志查询体验 - 面向文本的日志

为了让用户使用的更舒适，今年 2 月阿里云函数计算 （FC） 全新推出日志关键字搜索功能，目前已经全网上线，接下来用几个例子来讲讲小王是如何通过这个功能，快速定位请求日志，保住眼睛的。

（1）面向文本的日志

在调用日志 - 关键词搜索页面，开发者可以看到完整且详细的当前函数的业务日志（包含函数初始化、调用日志），在这里开发者只关注文本，函数计算帮助你甩掉了日志服务页面中其他无用的信息。

（2）支持查询、高亮

开发者使用关键词搜索时，可以自定义键入文本。像头图中的用户，可以直接在搜索搜索框中键入订单号等特点信息，即可查询到自己想要的日志信息。

### （3）支持简单的查询语句关联操作

关键词查询搜索框支持使用 AND、OR、NOT 等字段链接文本 （与日志服务语法保持一致），为用户的精细搜索提供了可能。

### (4）对于自定义 Runtime 更友好

对于 custom-runtime、custom-container 等需要用户高度自定义的 Runtime，也支持面向文本的日志显示以及关键字搜索，这样容器启动的日志也自然地展示给了用户。

阿里云函数计算（FC）以 custom-container 经典的 python-flask 框架为例，可以看到容器启动，python flask server 启动的日志也可以展现在控制台上。同理，initializer、自定义 Runtime 的日志都可以收集进来。

打开试试

在阿里云函数计算 （FC） 函数详情页面，单击调用日志，查询当前函数的调用记录。通过关键词搜索页签可以查看函数调用日志的内容。

文档链接:https://help.aliyun.com/document_detail/73349.html

阿里云函数计算（FC）不止关注为用户提供极高的工程效率、帮助用户降本提效，也关心用户使用我们的产品是否体验丝滑。

随着业务量的攀升，用户在日志方面的诉求也是越来越多，函数计算控制台中的请求列表与关键字查询的组合可以轻松覆盖 100% 来自开发者的日志需求，让您更快速定位问题，直接进行业务日志的检索。