开发者学堂课程【阿里云可观测峰会：行业实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1060/detail/16102
行业实践
六、阿里云 serverless 可观测实践
原生正在掀起一场新的技术浪潮， service 和可观测都是当下非常火热的一体。那 service架构下用户需要如何排查和定位问题？作为 service服务的提供商，又需要为用户提供怎样的可观测能力？本次分析想要分成三个部分，第一部分 service 简介介绍什么是 service ，下的可观测遇到了什么新的问题。第二部分和第三部分是函数计算，作为阿里云 service 服务的提供商，为用户提供了怎样的可观测能力。第二部分介绍函数计算内置的可观测能力。第三部分介绍函数计算对开源和三方可观测能力的探索。
那首先我们来看什么是 service， service 是于原生技术发展的高级阶段，从物理机到云主机再到 service 发展，可以用人类的进化来打个比方，从采集野果的原始社会，到工火中的古代社会，再到工业设施完善信息化高度发展的现代社会，人总是要想办法填饱肚子。但是随着社会的发展和生产力的进步，人们在如何填饱肚子上花的时间越来越少，更多的时间可以用来实现社会价值和个人理想。那不是人们不吃饭，只是人们不再需要去亲自摘果子，不需要亲自放羊，甚至不需要关心果子是从哪摘的。小羊是如何养的。从物理机到 service 发展也是类似的。物理机时期，开发者需要组装服务器搭建机房，为了承接业务峰值，需要提前准备平时流量几倍的服务器资源。到了云主机时期，开发者不需要组装机器，也可以获取到计算资源，直接基于云主机搭建业务。为了承接峰值流量，提前规划，并且购买云主机，控制结束后释放云主机计算，自由计算资源的利用率得到了进一步的提升，资源成本也有所下降。到了 service 阶段，开发者不但不需要组装服务器，甚至不需要提前购买和释放计算资源，只需要专心的开发业务逻辑 service 云产品来保障业务稳定可靠的运行。开发者只对实际使用的计算资源付费，资源成本进一步下降。那 service 不是没有服务器，只是业务开发者不需要关注服务器代码，仍然是运行在真实存在的服务器之上。计算资源的维护从用户那转转交给了云服务，用户只需要聚焦于业务逻辑代码的开发，按实际的使用量付费。那回到前面人类进化的比喻，人是铁饭是钢与都不是饿得慌。人类的今天依旧要填饱肚子。只不过我们不需要亲自爬树摘果子，不需要亲自放羊，不需要关心果子是从哪摘，小羊是如何养，只需要按照实际的购买量来付费，其余的时间可以实现个人理想。第二张图进行了很好的概括，从物理机到 service 将开发者从复杂的基础设施维护中解放出来，开发者更不关心底层的基础设施，更关心业务逻辑的实现，资源利用率更高，资源成本更低，人力成本更低。
接下来我们介绍 service 的几种形态弹性容器实例 eci ,service, k8S,ASK service 应用引擎 sae 函数计算 FC ,分别是容器级别、集群级别、应用级别和函数级别的抽象。 eci 属于容器资源层，开发者无需管理底层服务器，只需要提供提前打包好的镜像可以运行容器。但是多大的负载需要多少容器什么时候扩容，什么时候缩容、流量如何调度还需要上层来解决。ask 属于容器编排层，帮助开发者进行 eci 的编排，节点的维护和容量的规划由 ASK 来处理。也是 ask 来帮助用户搭建一个托管的集群，那集群还是用户的 ASK 只是帮助用户来搭建集群调度流量。 sae 是面向应用的 service pass 平台，计算集群不再是用户的，而是归云产品所有是 SAE 所有开发者不需要维护并且管理计算集群，只需要部署应用，搭建负载均衡的网关，可以将业务弹性平稳地运行起。 FC 是面向函数的 FaaS 平台，计算资源归云产品所有，是归函数计算所有。开发者不但不需要维护计算集群，也不需要搭建负载均衡的网关。函数计算内置了负载均衡的网关和削峰填谷的队列,开发者只需要编写业务逻辑代码而部署应用含计算来保障应用的弹性稳定运行。其中函数计算的研发和运维效率最高，抽象程度也最高，用户不需要提前购买和配置任何计算资，一行代码可以在函数计算上将应用给跑起来。在这个过程里，只有代码是用户的其他的全部计算资源都是函数计算。
函数计算是如何实现的？我们左边这个图是函数计算的一个简易架构图。首先用户需要将它的应用以计个包或者迹象的格式先上传到函数计算,当调用请求来的时候，分成同步调用和异步调用。同步调用请求会先经过负载均衡的网关到达函数计算系统的网关。系统网关获取调资源调度模块获取计算资源，获取到这个计算资源的地址之后，找到这个计算资源对应的函数执行引擎，并且在函数执行引擎里面执行用户的代码。那异步调用也是请求先通过负载均衡到达函数计算系统网关。这个时候不一样，这个请求来了后，我们会先将这个事件写入消息队列，那会有一个专门的异步事件分发模块，负责从这个消息队列里读取事件消息，再去资源调度模块获取计算资源然后找到这个计算资源执行用户的代码。从这个架构图中我们不发不难发现函数计算架构具有如下的特征.第一个，调度黑盒化，执行环境黑盒化。那调度节点和执行环境都是归云产品所有的调度节点，是这执行环境是这那用户是没有办法感知的，这也给用户的排查问题带来了一定的困难。第二个轻量化实例是以请求级别扩缩容的。这里我们来着重介绍，我们请求来了后，系统网关和异步事件分发模块会去。调度模块这获取计算资源。那调度模块这如果没有计算资源可怎么办？他要去创建计算资源，然后再把这个计算资源的地址返回给系统网关或者是异步事件分发模块。那我们可以看，实力是以请求级别进行扩缩容的，实力的生命周期更短更不可控。那我们什么时候进行实力争实力的，我们已经知道什么时候进行实力的扩容。那什么时候进行实力的缩容？当这个实力理念没有请求执行的时候，等一段时间把这个实力给回收。如果这里面一直有请求执行，那这个实际生命周期会很长。如果这个实例马上没有请求，那它很快会被回收。所以实例的生命周期不确定，生命周期也会更短。实例规格小，最小的规格是 128 兆 1/12 为 CPU 的。这个规格是非常的小，非常的轻量。第三个是组件的分布化。函数计算典型的事件触发场景中，请求要流转多款云产品，函数计算只是其中的一环。基于上面的特征，我们可以发现函数计算和之前的传统开发模式有着很大的区别。那函数计算可观测也面临了如下的挑战。第一个，数据收集难，实例生命周期更短，实例规格更丰富，主要是更小。传统的部署 agent 的可观测技术没有办法施展。我们以预置收集的 agent 为例，它最小需要设 912 兆的内存，最大需要设置 4G 的内存。这个在我们的 128 兆的函数实例里面没有办法实施。另外函数的执行引擎是多用户共享的，是这个执行引擎里面可能有多个用户的函数实例，那传统的部署 agent 的方式也不太支持这种多用户。另外一个是因为函数的这个生命周期是由系统控制的，用户没有办法知道什么时候开始，什么时候结束，这也导致很多可观测数据没有办法成功地发送出去，这个我们一会也会进行详细的讲解。第二个问题是数据分析难，观测数据量很大，数据量也随着用户数的增长而成指数级的增长。这个数据量大的时候，对我们的数据链路的稳定性，然后数据的查询速度包括存储的成本提供，都带来非常大的挑战，这也给我们数据分析在了不少难度。第三个问题，定位难，分布式的组件使得监控数据散落在各处，问题定位流程繁琐。我们举一个刚才事件源触发的例子，试源出发，请求是怎么流转？首先请求会先通过这个事件源，比如是 OSS 或者是 MS 事件源。到了函数计算之后，函数计算会开始执行用户的代码到了这个执行引擎里面。执行引擎里会先处理这个原消息，并且将处理结果存到用户的另外一个数据库里面。比如是 RDS 或者是 ots 那这样一个请求它经历了好几个运营产品。如果用户发现一个请求，它的到端延时非常长的话，它需要怎么办？需要先去上游看是不是有问题，再看函数计算者是不是调度有问题，是不是冷启动时间太长？好在刚才下游是不是数据库连接满了？数据库连接建立太慢了这样定位问题非常的不方便，流程很繁琐。第二个问题是调度黑盒化，执行环境黑盒化，是因为这些执行环境都不是的，用户没有办法进行管理，那只有要求了云产品侧暴露更多的指标，来使这个原本黑盒的链路稍微的白盒化。第三个，函数调用和资源调度都是以请求为粒度的实例，粒度的监控已经不足以帮用户快速定位问题了。我们刚才到这个请求的扩缩容都是以请求为力度的，并且这种世界云出发的这种场景，也是需要也是以请求为力度来串联上下游的。那我们需要提供更细粒度的这个排查和定位问题的能力。
基于以上的几个问题，开发者对函数计算的可观测提出了更高的要求，要求函数计算平台提供功能更全面，上手更简单的客观测能力。我们收集客户需求，我总结出了以下三点目标，第一个，提供开箱即用的可观测平台统一的观测页面。这个很好理解，是用户他不需要进行什么复杂的配置，甚至不需要配置，再上来能用，只要有调用可以看到这些调用对应的客观侧指标。只有三个小点，平台端需要无侵入的进行数据的采集、上报、处理、展示。这个是不需要用户有什么配置。然后这个平台端也不要侵入用户的 runtime 由平台来进行采集、上报、处理和展示好了。 平台和用户各司其职，大家来完成一个完整的客观侧能力的报表
第二个是要求平台端，因为平台太黑盒，要求平台端提供日志，丰富的指标，完备的日志详细的这样练，是提供尽可能多的指标，来让用户充分的了解这个执行环境。第三个是注意更细粒度的客观层能力，是要提供以请求为粒度的这个可观测能力，实现全链路的白盒化。那我们这可观测含静态下可观测引入了一些新的问题，那我们也给这些问题带来一些新的解法，但是这也肯定不是完全摒弃之前的这个开发者的开发习惯的。我们要让开发者更快更顺手的用起，也要兼容传统开发者的开发习惯，那要需要兼容传统开发者以实例为问题定位单元的观测体验。是这本来函数计算是不对外暴露实例的概念的，但是为了让用户对整个底层的计算环境更有信心，然后也希望也是为用户排查和订阅问题更加的方便，我们暴露了实例级别的监控。第三个，数据开放协议开源观测数据已经投递给用户了，允许用户进行自定义的处理，这个数据开放给用户。另外协议一些有标准规范的这些数据我们都使用了开源的规范，那我们也希望使用开源的规范，来方便用户统一对这些数据进行处理。那总结下来是三点，开箱即用兼容体验，开源开放。
通过刚才的这些讲解，想必大家已经对什么是service ？ service 下可观测引入了什么新的问题，有一定的了解。那接下来介绍函数计算是如何为用户提供客观测能力的，进入。
第二部分，函数计算内置客观侧能力。首先我们来看函数计算可观测能力图谱是一张图，是我们今天的所有的能力，我们先来简单的看。首先分成四个大的部分，指标，日志调链和 APM 指标是和云监控集成，我们会在海上计算的这个监控中心上提供云监控的指标。那为了兼容 SS 用户和 Grafana 用户的这个体验，我们也提供 SS dashboard 和 Grafana dashboard 这个解决方案。
日志上是和日志服务无缝集成，提供了函数日志请秋日志实例日志。它们分别是什么？一会也会有详细的介绍。在调用链上，我们也是和阿里云的链路追踪产品进行了无缝的集成，是函数计算会默认上报系统内部关键链路的时间。这些都是基于 open tracing 协议的。并且将这个调用链的上下文信息传给用户的 runtime 用户可以在函数里面基于 yarger 或者 open telemetry 进行自定义的埋点。 APM 上也是和阿里云的 MS 产品集成，用户可以查看一些 runtime 的指标。比如 JVM 的 GC 数据，然后 MySQL 的连接情况。然后同时因为有一些客户也更喜欢使用三方 SaaS 的这个客观侧产品，那我们也提供了一些集成方案，下面会讲到我们如何提供 neurelic 的这个解决方案。
我们先开始详细的介绍我们是如何为用户呈现可观测能力的，分成四个部分，数据的采集、数据存储、数据处理和数据展示。通过前面的介绍，我们知道用户的业务代码是在函数计算的执行引擎中运行的，是在这里执行引擎会根据用户设置的函数内存创建不同规格的函数实例。用户的函数记录是在不同的函数实例中执行的，函数实例是这这可能是 128 兆的。这是一个 G 的，这是 512 兆的。那我们的这个执行引擎实际上是异构的，底层支持 ECS 和神龙裸金属执行环境两种执行环境。那对应的函数实例分别是 Docker 的 container 和这种安全容器。我们在执行引擎的内部实现了一个 agent ，agent 负责函数实例生命周期的管理，函数实例健康状态的检测和观测，数据的收集处理和上报。数据处理侧具有三个特点，无侵入观测数据采集，不占用函数实例的这个 CPU 内存资源。因为 agent 是部署在这个是部署在函数计算本身的，是部署在这个函数实例之外的，占用的是函数计算系统的资源。用户不需要关心我们是如何处理的，也然后这个也不占用用户的资源，是对用户无感知，对函数实例也没有入侵。
第二个是支持异构的执行环境，在不同类型的执行引擎中，日志指标调用链的处理会有一定的区别。那我们也对这些区别进行适配，是分别适配 ECS 执行环境中的日志指标调用链的采集和处理和使用裸金属环境中的支持多租。然后 ECS 环境不存在多租的问题，因为 ECS 它本身是靠是在 ECS 执行环境当中用户是靠 VM 来进行隔离的，那一个 VM 里面只会有一个用户的函数实例，所以这里面都是一个用户的实例，那它执行引擎里面是单组的不存在多组的问题，但神龙不一样了。在神龙裸金属执行环境里面，用户是这种安全容器级别的隔离的。那在一个执行环境里会有不同用户的函数实例，那同一个 agent 需要支持不同用户实例的日志指标和调用链的收集。
第二个，数据存储，数据存储，我们有两种方案，一个是存到函数在云产品自己的数据库里，然后另外一个是存到用户的云产品里，那可能还是在自己的数据库里，会有比较大的问题。一个是当数据量上来的时候，我们的这个数据链路的会对数据链路的稳定性带来了很大挑战，然后数据的查询速度也会变得更慢，然后我们的成本也是会越来越高。同时因为我们自如果还是算自己来存储这些数据的话，用户没有办法获得。也是这个数据只是一个封闭的数据，没有开放给用户，这是不够好的。所以我们选择了把数据存到用户对应产品，也是收集好了这些日志指标和调链之后，分别传给不同的用户的日志服务、链路追踪服务和云监控。用户可以对这些数据进行二次的处理和加工。可快，可扩展性也更强。
我们最终的目标是为了提供一个开箱即用的这个可观测平台，数据已经存到用户对应产品里了。那如何提取？需要提供一个是处理数据的这样一个平台。我们是基于 service 架构实现的，是前端需要查看这些数据的时候。我们有一个这个 service 架构的 web API 来从用户云产品里面获取原始数据，可以将这些原始数据进行处理聚合格式转化传给前面的这个控制台。那我们是基于 server 架构实现的，是在上面创建了三个函数，分别对指标、日志和调用链进行处理，拿数据的展示。经过层层的处理，我们终于可以为用户提供一个开箱即用的完整的统一的可观测平台，里面都能看到哪些信息？这里是进行一些罗列，指标上是非常丰富的，有多层次，然后多维度有集群服务函数的指标请求，实例级别的指标还有计量指标。然后日志是函数级别的日志，实例级别日志请求入职还有实时日志。是你可以实时的查看是 tail 日志，还有是也可以根据 grap 来对日志进行搜索。然后在是调用链还是像会自动上报系统内部的调用链，比如冷启动时间，调度时间这些。然后同时也可以串联上下游，一个是串联，上游是函数计算，可以识别这个开源的。这样链的 header 那如果用户把上游的 header 传进来，海尔钻可以基于用户的这个调用链来创建子调用链。
另外一个是串联下游，函数计算会把这个调用链的上下文传给用户的 runtime 用户的 runtime 里可以是创建一些自定义的子调用链，比如去创建访问数据库的调用链或者是写本地数据的调用链，这些这是函数计算可观测能力的一个全链路的实现。
接下来我们对端侧的数据采集和 service 化的数据处理进行详细的介绍。首先看端侧的数据采集，我们之前到每个执行引擎里面会有一个 agent ，agent 来负责实例生命周期的管理。然后观测数据的采集和上报。那它是如何实现？每个 agent 里面都有一个 container manager container manager 来负责管理函数实例生命周期。当创建新的函数实例的时候， manager 会记录一份函数实例的源数据，并分别启动指标采集、日志采集和调链采集的协程。每个函数实例都有自己的协程，各个函数实例的采集互不影响，在实例销毁的时候，观测协程也会随之关闭。至于这个设计使得数据采集如下的特点，是支持多租，因为它们之间是互不影响的。每个函数实例的数据指标的采集是互不影响的，那很容易支持多租，可以并发收集不同用户的数据，也支持 ego 的执行环境。
数据的采集随着实例生命周期启停，然后不进入用户的 runtime 那采集的都是什么信息？这些指标都是什么指标日志都是什么日志。指标采集主要是请求级别的指标和实力级别的指标，因为我们要为用户提供是请求力度的监控，请求力度的监控是这个请求都经历了什么？在执行的时候它的执行时间有多久？但占用内存是多大？有没有出错？这个请求有没有出错？如果出错，它的错误类型是什么？那它调用类型是同步调用还是异步调用，资源类形式安量实力是预留实力这些是请求级别的指标。实力级别的指标是我们也会在这个函数执行的时间段内采集实例级别的指标，包括这个实例的CPU 、内存、网络、流量，还有里面的请求数是单 11 的并发的请求数。
在日志采集上，我们是收集函数输出到标准输出的日志，是输入到 std out 的日志，包括函数日志、实例日志在调用链上是基于 open tracing 的协议自动上报系统关键链路的耗时，如调用耗时，冷启动耗时，对异步调用的队列积压耗时等。那这里我们对我们是如何来实现这个数据采集端的和我们采集的内容进行了简单的介绍。
那下面我们介绍 service 化的数据处理架构。用户要看的是一个完整的报表，他登了控制台想查看数据，前端收到了用户查看数据的请求，数据从哪来？需要有一个 web API 来被前端返回数据。那这个 Y web API 承担的工作是一个是从用户的云产品理念获取原始数据，另外一个是在这个业务逻辑里去处理这些数据，然后把它以和前端约定的格式返回给前端。我们是将这个逻辑这个API 的处理逻辑捕捉到了函数计算上。那我们也充分地享受了 service 架构的红利，然后这个架构是毫秒级扩容的，可以轻松应对突发流量。因为这种控制台的请求肯定是有明显的波峰波谷的，是白天会有很多用户来使用，然后夜晚会非常的少。那同时作为业务开发者，我也确实是只需要关注我的业务逻辑的实现，不需要关注底层用了多少台计算资源，也不需要去维护服务器是让我的这个开发运维效率更高了。这个是service 架构的优点，作为我也充分地享用了service 的红利。为了保障这个服务的可用性和可靠性，也在国内外进行了多个区域的部署，来尽可能的避免跨洋网络的一个访问慢的问题。
经过前面的层层处理，我们终于可以为用户提供一个比较好的可观测的体验。
主要包括以下三个部分，第一个是提供开箱即用的统一可观测平台。那丰富的指标我们这里提供非常丰富的函数级别、服务级别、请函数级别、服务级别、集群级别，还有请求级别、实例级别的指标。然后这些指标的聚合力度有秒级、非中级、小时级。是尽可能的把函数计算内部的指标都暴露给客户，让客户更信任底层的执行环境，也提供了这个请求力度的监控。可以看到这里有请求的调用结果，然后这个请求的执行时间，内存使用量，然后点开这个请求日志可以看到它的日志。然后点开这个调用链可以看到这个请求的调用链。在这个请求调用链里，可以看到系统是函数计算系统上报的调用链，是调度的时间，还是计算系统调度计算资源的时间，还是计算系统冷启动的时间，包括下载代码、下载自定义镜像的时间，还有是启动这个执行环境的时间，以及用户真正执行用户代码的这个 invocation 的时间。这些都是系统自动上报的，也是用户不需要进行任何 agent 的安装，不需要进行什么配合，可以使用这样一个开箱即用的同一客观测平台。
第二个也是要兼容，也是我们刚才的兼容传统开发者的开发习惯，我们提供实力级别的监控，包括实力级别的指标，可以看 CPU 内存还有网络流量，还有但是阅读请求数这里可以看一个函数维度的聚合，是这个函数的 CPU 情况的一个大概。下面可以看一共有多少个实例，然后每一个实例它的指标是怎么样的？提供了实例级别的日志，甚至还可以登录到这个实例里面去，这样用户对自己的至今环境更加的有信心了。
第三个，数据开放，协议开源。数据开放是我们把所有的观测产品都存入到了用户的云产品听里面了，是完全开放出去。协议开源链路追踪遵循开源的 open tracing 协议，可以串联上游连接下游，串联上游是识别上游开源的这个协议头。点击下游是将 trace 的上下文传入用户 runtime 用户可以基于当前调用链，根据 yarger 或者 open telemetric 进行自定义的埋点。这里是一个简单示例，是一个 MNS trigger 的示例。上游用户是记录了 publish message 和在 MS 队列里面等待的时间。然后到了函数计算之后，函数计算自动记录和调度时间。然后在函数计算的异步消息队列里面堆积的时间还有冷启动的时间。我们又把这个调研链给下游，然后在用户的 runtime 里面是 invocation 这是在用户 runtime 里面发生的事情。然后用户又自己埋点这个自定义的调用链，那可以看到一个完整的端到端的调相连了。那用户再有一个请求它的端到端时间很长的话，通过这个调用链知道。我的这个时间究竟是花在哪里，可以进行更有针对性的排查和定位。
接下来我们根据两个 demo 来看下，来展示一下我们的客观测能力。第一个是函数计算错误问题的定位。我们看这个函数有四十一个错误，然后我们点进去看看到底是为什么出错？先是看服务级别的错误，然后可以看函数级别的错误数，然后最后可以定位到出错的请求。我们看这些都是 function handle 的 error 是我已经处理这个错误。那是什么错误？点进来看请求日志，发现原来是处理一个不存在的object ，那我可以去 OSS 上看。为什么这 object 不存在？是一下子从指标然后下钻到请求，然后再查看它的日志，可以快速地定位问题。
然后第二个是冷启动耗时分析。我有个请求，发现它执行的特别长，但是我实际的业务逻辑又没有很复杂，预计是百毫秒级别结束，但这个请求端到端却执行了7 秒。那我要看是怎么回事？这个请求，那我看它的调用链。我们发现这个函数的直接时间确实只有 170 毫秒，但是它遇到了冷启动，冷启动里面下载代码花了两秒将近 3 秒，然后函数实例启动花4 秒多，这样子冷启动 7 秒的时间。那为了解决这个问题，我们要看能不能缩减一下代码包的大小，让下载代码的时间变少。然后另外也是要优化启动时候的逻辑，让函数启动的时间也变短一点。如果是对冷启动时间特别敏感，也可以使用我们的预留实例来完全的规避冷启动。这里是还是算冷启动优化的最佳实践，用户可以基于这个最佳实践进行自定义的配置。
那进行我们的最后一个部分函数计算，对开源和三方可观测能力的探索。很多客户习惯使用 hum CPM 或者是开源的 SaaS 厂商的监控能力，比如 new relic 呀、 data dog ，但是发现在海上计算当中非常难用起来，观测数据大概率会发送失败，这是怎么回事？大多数的客观字符提供上的 SDK 都是后台定时采集数据的批量发送。但是 FC 实例在请求执行完成之后会立即冻结，实例下次启动来的时候才解冻。如果发送时间刚好处于 10 列冻结时期，那这个数据会发送失败，稳定的失败。
我们来看这张图。 FC service 代表函数计算系统，这里主要是函数的执行引擎 function runtime 是函数实例中的 runtime 首先实例启动之后会先调用 initialize 接口，用户可以在这个 initialize 中做一些自定义的初始化操作，比如建立数据库初始化全局配置启动 arms 的采集初始化结束之后会执行 invoke 逻辑，invoke执行结束后系统会立即 freeze 这个函数实例把这个函数式一个冻结住。如果这个时候到后台的 Flash interval 会发送。观测数据，那数据要发送失败了，后面也有新的请求来。如果后台的观测数据发送时间刚好落在实例的活跃时间内，在这，那它可以发送成功。所以我们看在不做任何处理的情况下，这个数据运气好可以发送成功，运气不好会发送失败。
这个函数实例的生命周期收还是算系统控制的，用户也不可见。因此用户无法预知这些观测数据什么时候可以成功，什么时候会发送失败，这导致了数据的缺失和可观测功能的不稳定。那为了解决这个问题，函数计算扩展了编程模型，允许用户监听生命实力周期，监听这个实例的生命周期，用户可以自己实现 pre freeze 和 pre stop 的函数逻辑，在 freeze 之前，我们会告诉用户，我们会执行你的 free pre phrase 的代码，你可以在 preface 里面 Flash 你的这个观观测数据，然后在回收销毁这个函数实例之前，我们会执行用户的 pre stop 的函数，用户可以在 pre stop 里面关闭连接，停止数据的采集。那基于这个技术，可观测数据可以稳定的发送。
也是使用了上面的这个技术，我们内部得以和 arms APM 进行集成，然后也提供了集成三方 SaaS 厂商，如 neurelic 的解决方案。下面这个图列出了 FC 目前已经集成或者已经提供解决方案的产品和技术，我们也将在这个方向进行持续的探索。
以上是今天关于service 可观测分享的全部内容，可以通过关注进行后续学习。
