简介： 函数计算可观测性经历了 1.0 -> 2.0 的倒退，从闭门造车的可观测倒退成开源的可观测，从平台的可观测倒退为开发者的可观测，从 FaaS Only 的可观测演进成了云原生的可观测。
作者：夏莞
背景
Serverless 将成为下一个十年云的默认编程范式
随着 Serverless 概念的进一步遍及，开发者逐步从张望状态进入尝试阶段，越来越多的企业用户开始将业务迁徙到 Serverless 平台。在阿里团体外部，淘宝、飞猪、闲鱼、高德、语雀等外围性能稳步落地，在阿里团体内部，新浪微博、世纪联华、石墨文档、TPLink、蓝墨云班课等各行各业的企业也纷纷解锁 Serverless 应用的不同场景。Serverless 正在成为成为下一个十年云的默认编程范式。
更多案例请参考 函数计算用户案例
Serverless 降本增效免运维的个性为开发者带来了实打实的益处：基于函数计算的 Serverless 计划为蓝墨节俭了 60% 左右的 IT 老本，为石墨文档节约了 58% 的服务器老本；晋升码隆科技的开发效率，实现两周内性能上线；安稳撑持负载的波峰波谷相差 5 倍以上的新浪微博，每天轻松解决数十亿申请。
广告工夫：欢送退出云原生 Serverless 团队（函数计算，Serverless 工作流，Serverless 利用引擎），以公共云、团体、开源社区三位一体的形式打造业界当先的 Serverless 产品体系。职位需要见 JD，招聘长期有效，有趣味的同学能够分割本文作者或 @Chang, Shuai(shuai.chang)。
可观测性成为 Serverless 倒退的绊脚石？
随着 Serverless 的深刻应用，开发者逐步发现 Serverless 架构下的问题定位比传统利用更加艰难，次要起因如下：
- 组件散布化：Serverless 架构的利用往往粘合多个云服务，申请须要流经多款云产品，一旦端到端延时变长或体现不合乎预期，问题定位十分复杂，须要顺次去各个产品侧逐渐排查。
- 调度黑盒化：Serverless 平台承当着申请调度、资源分配的责任，实时弹性扩容会带来不可避免的冷启动，Serverless 的资源伸缩是无需开发者参加也不受开发者管制的。冷启动会影响端对端延时，这次申请有没有遇到冷启动，冷启动的工夫都耗费在哪些步骤，有没有可优化的空间都是开发者急于晓得的问题。
- 执行环境黑盒化：开发者习惯于在本人的机器上执行本人的代码，出了问题登录机器查看异样现场，查看执行环境的 CPU/ 内存 /IO 状况。面对 Serverless 利用，机器不是本人的，登也登不上，看也看不了，开发者眼前一片乌黑。
- 产品非标化：在 Serverless 场景下，开发者无法控制执行环境，无奈装置探针，无奈应用开源的三方监控平台，考察问题的形式不得不产生扭转，传统的考察问题教训无奈施展，十分不棘手。
函数计算是阿里云的 Serverless 产品，在过来的一年，函数计算团队为了更好地答复以上问题做了很多致力。
本文次要介绍函数计算在可观测性上的尝试与函数计算可观测性现状。
Serverless 下可观测性
可观测性是通过内部体现判断零碎外部状态的掂量形式。
– 维基百科
在利用开发中，可观测性帮忙咱们判断零碎外部的健康状况。在零碎安稳运行时，帮忙咱们评估危险，预测可能呈现的问题。当零碎呈现问题时，帮忙咱们疾速定位问题，及时止损。
一个好的可观测性零碎要帮忙用户尽可能快地发现问题、定位问题并且端到端地解决问题。
在 Serverless 这种免运维的平台体系中，可观测性是开发者的眼睛，没有可观测，何谈高可用？
可观测性 1.0
图 1：可观测性根底
可观测性次要蕴含三个局部：日志、指标、链路追踪。
和简直所有 FaaS 产品一样，函数计算（FC）在商业化之初就反对了函数日志和指标的查看。
- 函数日志
用户在 FC 配置 SLS 的 Project 和 Logstore，FC 将函数打到 stdout 的日志转存到用户的 Logstore 中。用户能够通过 SLS 控制台查看函数日志，并借助 SLS 的能力对日志进行剖析和聚合。
- 根本指标
FC 将指标日志推送到云监控，通过云监控提供函数调用数 / 谬误数 / 函数延时 / 函数内存等根本指标。
函数日志和根本指标是利用的听诊器，尽管奢侈简陋，却也能帮忙用户发现问题，定位问题。
即便呈现开发者无奈排查的问题，在用户量不那么大的年代，开发同学能够为用户提供贴身服务，联合后盾日志帮用户定位问题。
函数日志和指标应用详细信息请参考 配置并查看函数日志，监控指标。
可观测性 2.0 — 云原生的可观测
随着 Serverless 的倒退，越来越多的场景在 Serverless 落地，应用规模越来越大，产品架构越来越简单，利用听诊器的可观测性 1.0 曾经不能满足各行各业开发者的监控诉求。这种近乎黑盒的执行环境给开发者带来了强烈的距离感与不信任感。
开发者须要 掌控本人的利用，想要晓得每一个申请在函数计算经验了怎么的历程，想要看看端到端的延时长是不是因为冷启动，想要查看函数实例的执行环境，想要在申请出现异常时第一工夫定位问题，想要复用相熟的开源观测平台。
在面对这些需要时，团队外部也通过了长时间的强烈探讨，一部分同学认为咱们应该反对这些需要，另一部分同学则认为这些需要某种程度上与 Serverless 实质相违反，Serverless 就是要屏蔽底层的计算资源，用户不须要关怀底层计算资源的状况。另一方面咱们裸露了这些指标有什么用呢，用户就算看到了有冷启动，看到了零碎工夫耗费，看到了底层实例的 CPU，用户又不能有任何本质操作，这些指标真的意义吗？这两种观点争论不休，而我，是动摇的反对者。
起初团队搬到了 EFC，每天都要期待着那不知什么时候会来的电梯（输出你要去的楼层，去对应的电梯宁静地期待，看不到电梯目前所在楼层）。电梯通知咱们，你就在这里等哦，我必定会来的，然而我当初到了哪层，我什么时候下来你大可不必晓得，你晓得了也没用，我的这个调度必定是最优的，你要置信业余电梯的调度算法。可是，我怎么能置信你呢？
于开发者而言，函数计算也是那不知什么时候会来的电梯吧，咱们和开发者说您的申请咱们肯定会稳固执行的，您的执行环境肯定很衰弱，申请过多咱们会主动扩容的，然而以后实例的监控指标，我什么时候扩容您大可不必晓得，咱们的调度必定是最优的，您要置信业余研发团队的调度算法。同样的，开发者又怎么置信咱们呢？
Serverless 的可观测性不单单要帮忙开发者排查问题，也要逐渐揭开 Serverless 那层神秘的面纱，赢取开发者对 Serverless 的信赖。
于是有了函数计算可观测性 2.0，咱们心愿可观测性 2.0 能够成为利用的心电图。
图 2：函数计算可观测性现状
- 为了答复申请在函数计算的生命历程，串联分布式系统的上下游服务，拥抱开源可观测能力，咱们集成了 OpenTracing，反对链路追踪。
- 为了裸露零碎状态，提供利用级别监控，咱们集成了 ARMS(Java)，内置了 APM 能力。
- 为了放慢端到端定位问题的速度，咱们反对了申请级别指标（FC Insights），公布了监控核心，问题发现 / 考察一站式解决。
- 为了兼容开发者已有的用户体验，咱们拥抱开源，集成 OpenTracing，反对 Grafana Dashboard；咱们反对三方监控平台，实现代码简直零革新接入 APM 监控零碎。
- 为了兼容传统开发者的可观测体验，反对探针装置，咱们拓展了编程模型，反对函数 LifeCycle，为集成三方监控提供可能。
图 3：函数计算兼容开源可观测能力
相比于本人发明创造 FaaS 可观测性新体验，函数计算兼容开源可观测能力，集成 Jaeger，反对 Grafana 大盘，也反对以十分小的改变接入 New Relic 等优良三方监控平台。函数计算是首家兼容开源、拥抱容器生态和云原生开发者的 FaaS 提供商，可观测体验的平滑迁徙撑持利用在容器和 Serverless 平台的平滑迁徙。
集成 OpenTracing，反对链路追踪
FC 与链路追踪服务集成，为开发者提供了残缺的调用链路还原、调用量统计、链路拓扑剖析、冷启动定位等工具。帮忙开发者疾速剖析和诊断分布式架构下的性能瓶颈。
FC 链路追踪具备以下特点：
• 拥抱开源：齐全兼容 OpenTracing 协定，没有附加学习老本；
• 被动记录：上报申请在函数计算中耗费的端对端工夫；
• 调度通明：裸露代码筹备工夫与实例启动工夫，是首个裸露冷启动延时与具体工夫耗费的 FaaS 产品；
• 承前启后：串起上下游利用，既能够通过 span context 与上游利用连贯，又将 span context 传入函数，连贯上游服务。
图 4：链路追踪链路示例
图 5：链路追踪综合能力详情
集成 ARMS，内置 APM 能力
FC 无缝对接 ARMS 利用监控，开发者只需为函数新增一个环境变量即可开启 APM 利用监控性能，ARMS 探针以对代码无入侵的形式监测利用性能，提供利用级别的可观测性，包含函数实例的 CPU、内存指标、Java 虚拟机指标、代码 Profiling 信息、SQL 查问等函数实例的指标。
图 6：ARMS 示例
公布监控核心(Insights)，问题发现考察一站式解决
FC 反对申请级别指标，通过为用户每个申请多打一条指标日志的形式为申请装上摄像头。通过申请级别指标，用户能够分明地看到申请的执行工夫、应用内存，是否异样、谬误类型、冷启动状况，traceID 等信息。也能够基于申请级别指标串联起所有的可观测性能力。
监控核心则是 FC 可观测性能力的集大成者，监控核心集成了 Metrics、Logs、Tracing 的能力，能够在一个站点实现预览指标、查看日志、剖析链路的能力，争取做到问题发现考察一站式解决。
监控核心具备如下特点：
- 多维度：反对 Region、Service、Function、Qualifier、Request 多维度的指标，展现各个维度下的调用数和谬误散布；
- 多层次：集成 Metrics、Logs、Tracing 的能力，全方位多层次对利用进行监控；
- 全链路：联合指标、日志、链路等信息，层层递进，抽丝剥茧，真正做到能够在一个站点发现问题，定位问题并解决问题。
图 7：监控核心示例
扩大编程模型，集成三方监控
函数实例的生命周期齐全由平台管制，用户无法控制实例的启动与回收，也不感知实例的暂停与重启，这就使得在函数计算上执行除主线程外的背景线程分外艰难。监控探针就是诸多重要的背景线程的一种。
FC 扩大了编程模型，公布 Runtime LifeCycle 性能，Runtime LifeCycle 会监听函数实例生命周期事件，容许函数实例在暂停和回收前回调用户的函数逻辑。这一性能的公布使 FC 集成三方 APM 监控成为可能。用户只须要在实例暂停前将采集的指标收回去、在实例回收前将内存中的数据清理掉就能够在 APM 平台上实时地查看监控指标了。
图 8：Tingyun APM 示例
图 9：NewRelic APM 示例
总结
函数计算可观测性经历了 1.0 -> 2.0 的倒退，从闭门造车的可观测倒退成开源的可观测，从平台的可观测倒退为开发者的可观测，从 FaaS Only 的可观测演进成了云原生的可观测。
作为首家兼容开源可观测、拥抱容器生态和云原生开发者的 FaaS 提供商，函数计算也将更有实力实现开发者业务的平滑迁徙。
将来布局
FC 可观测性相比于一年前后退了一小步，从黑盒的可观测演进成了强劲烛光的可观测，但间隔“Serverless 利用白盒化”的指标还有着很长的路要走。咱们心愿可能兼容开发者的监控体验，撑持着用户平滑地释怀地将业务迁到 Serverless 上来。
接下来咱们会持续投入做以下事件：
- 欠缺监控核心，反对报警配置，预警异样指标；
- 提供实例级别指标，做到代码问题可定位，环境现场可追溯；
- 集成开源我的项目，集成 Prometheus，Opentelemetry，配置 Grafana 大盘；
- 丰盛指标内容，目前还有一些指标是不好透出的，没有裸露的，咱们要逐渐都裸露进去；
心愿函数计算的可观测性成为一盏灯，照亮每一个 Serverless 利用。
原文链接
本文为阿里云原创内容，未经容许不得转载。