共计 1785 个字符，预计需要花费 5 分钟才能阅读完成。
据说这个问题你也遇到了？
小王是一名程序员，最近在应用 FaaS（Function as a Service) 服务时遇到了一个头疼的问题：他的 FaaS 利用呈现很多报错，然而调用日志页面的申请太多了，没方法简略、疾速地查到呈现 bug 的起因。
对小王来说，在开发、运维时查看本人的利用呈现谬误本来是稀松平时的事件，之前小王能够在服务器本地打印的日志中查看关键字，能够查看逻辑是否正确，再查看下执行环境中的报错信息，谬误根因根本就被发现了。当初，当小王把利用部署到云上并且将业务交付给 FaaS 服务商来执行后，却只能依赖于 FaaS 服务商提供的日志解决方案查问相干 debug 信息，没有方法像在服务器上进行调试一样，能够间接考察相干的谬误起因并且进行修复。
因为这个问题，小王每天都要在几十、或者上百条调用日志的申请列表中，一点点用眼睛搜寻，真的眼睛都要废了, 于是忍气吞声的小王开启了自救模式……
支流函数计算产品如何应答？
小王比照了目前国内的支流函数计算产品，他发现这些产品在日志层面有三个共同点：
a. 均以自家的日志服务零碎作为日志存储依靠；
b. 向用户裸露申请列表页，每一个申请下蕴含该申请的所有日志；
c. 均反对跳转到日志服务进行自主查问，反对多函数写入同一个日志仓库
以上三个共同点看起来中规中矩，他们均采纳自家成熟的日志服务作为日志存储系统，在保障日志安全性的同时也提供了不错的查问体验；面向申请级别的日志也人造的为用户做了隔离，也合乎 FaaS 作为事件驱动的调性；然而均反对跳转到所绑定的日志服务产品这一做法可能会褒贬不一。从全面性和准确性上来说没有任何问题，所绑定的日志服务能够作为用户业务日志的 source-of-truth。
不好的是当用户面临茫茫多的日志信息，其中混杂着多个利用的信息和云服务的配置信息，无疑进步了应用老本，并且想要用好自助查问这一性能，须要较长的学习周期。开发者进行 debug 时最关怀的就是 errorStack，然而在日志服务中，映入眼帘的更多是无用的信息。
你须要的和你看到的
阿里云函数计算助你一眼定位问题
优化用户的日志查问体验 – 面向文本的日志
为了让用户应用的更舒服，往年 2 月阿里云函数计算（FC）全新推出 日志关键字搜寻性能，目前曾经全网上线，接下来用几个例子来讲讲小王是如何通过这个性能，疾速定位申请日志，保住眼睛的。
（1）面向文本的日志
在调用日志 – 关键词搜寻页面，开发者能够看到残缺且具体的以后函数的业务日志（蕴含函数初始化、调用日志），在这里开发者只关注文本，函数计算帮忙你甩掉了日志服务页面中其余无用的信息。
（2）反对查问、高亮
开发者应用关键词搜寻时，能够自定义键入文本。像头图中的用户，能够间接在搜寻搜寻框中键入订单号等特点信息，即可查问到本人想要的日志信息。
具体操作请返回下方链接查看：
https://www.bilibili.com/vide…
（3）反对简略的查问语句关联操作
关键词查问搜寻框反对应用 AND、OR、NOT 等字段链接文本（与日志服务语法保持一致），为用户的精密搜寻提供了可能。
具体操作请返回下方链接查看：
https://www.bilibili.com/vide…
(4）对于自定义 Runtime 更敌对
对于 custom-runtime、custom-container 等须要用户高度自定义的 Runtime，也反对面向文本的日志显示以及关键字搜寻，这样容器启动的日志也天然地展现给了用户。
阿里云函数计算（FC）以 custom-container 经典的 python-flask 框架为例，能够看到容器启动，python flask server 启动的日志也能够展示在管制台上。同理，initializer、自定义 Runtime 的日志都能够收集进来。
关上试试
在阿里云函数计算（FC）函数详情页面，单击 调用日志 ，查问以后函数的调用记录。通过 关键词搜寻 页签能够查看函数调用日志的内容。
文档链接:
https://help.aliyun.com/docum…
阿里云函数计算（FC）不止关注为用户提供极高的工程效率、帮忙用户降本提效，也关怀用户应用咱们的产品是否体验丝滑。
随着业务量的攀升，用户在日志方面的诉求也是越来越多，函数计算控制台中的申请列表与关键字查问的组合能够轻松笼罩 100% 来自开发者的日志需要，让您更疾速定位问题，间接进行业务日志的检索。
