玩转AIGC训练营：课时7：函数计算的可观测性
课时7：函数计算的可观测性
内容介绍
一、Logging、Metrics、Tracing 概述
二、日志/指标/链路追踪
三、性能问题排查
一、Logging、Metrics、Tracing 概述
可观测性是什么？
可观测性：逻辑百科中这样说，可观测性是通过外部表现判断系统内部状况的衡量方式；在应用开发领域可观测性可以帮助判断系统内部的健康状况，在系统出现问题的时候可以帮助定位问题、排查问题、分析问题，在系统平稳运行的时候帮助评估风险预测可能出现的问题。评估风险类似于天气预报，预测到明天下雨出门就要带伞，在函数计算的应用开发中如果观察到函数的持续升高，那很有可能就是业务团队努力工作导致业务规模迅速扩张，在这个例子当中，为了避免达到限制触发流控开发者就需要提前来提升并发度度，这就是预测风险的能力。
可观测性包括以上三个方面，Logging ，Metrics，Tracing
Logging 是日志，日志记录了函数运行的关键信息，这些信息是离散的，并且是聚集的，结合错误日志和函数代码可以快速的定位问题。
Metrics 是指标，是聚合的数据，通常以图表的形式来呈现，图表中的 TPS、错误率等核心指标可以反应函数的运行情况与健康状况。
Tracing 是链路追踪是请求级别的追踪，在分布式系统中可以看到请求在各个模块的延时，分析性能瓶颈。
二、日志/指标/链路追踪
*配置日志
*在服务中配置 LogProject/Logstore
*记录日志
*通过编程语言内嵌的日志打印语句
*函数计算提供的日志打印语句
*查看日志
*Demo
在函数计算中查看函数日志，在传统服务器的开发方式里面可以将日志记录到磁盘的某个文件中，再通过日志收集工具收集文件的内容。在函数计算中开发者不需要维护服务器，函数计算与日志服务可以将函数日志记录到开发者提供的日志仓库里，也就是 Logstore,日志是服务配置中的一项，为服务配置 LogProjec t和 Logstore 同一服务下的所有函数通过 STDR 去打印日志都回收集到对应的 Logstore 中。
在各个开发语言中提供打日志的库都会收集到，函数计算收集所有打印到 STDR 的日志并且将日志上传到用户的 Logstore 里面，函数计算的调用是请求为主的，每次调用对应一个函数，也就对应一个ID。请求量大也就对应日志多，区分日志对应的请求就需要把ID一起记录到日志当中，函数计算提供内置的日志语句打印的每条日志前面都会带上 ID 方便日志的筛选；函数日志收集到日志服务的 Logstore 里，查看日志就可以登录日志服务的控制台进入设置的 Logstore 里查看日志，同时函数计算控制台也集成了日志服务，可以在函数计算控制台上查看日志。
函数计算控制台有两种查询方式，分为简单查询、高级查询。简单查询中列出每个 ID 对应的日志，可以通过 ID 日志进行筛选，高级查询是嵌入了日志服务的控制台可以通过色库语句进行查询；
做一个 demo，登录函数计算的控制台
登录后新建一个服务
函数计算控制台是提供了绑定日志功能的，控制台帮忙生成一个LogProject 和 Logstore，勾选就会设置帮助创建，日志就会都到下面。
看一下hello world 和 print World 的区别
点击保存并执行，会发现用函数计算提供打出来的日志是带有当前的执行时间和ID；print 打出来的日志就只有内容
要在控制台看日志的话会显示在控制台里面，Logstore 的查询功能就会看到Logstore 的日志
简单查询
高级查询
这里可以直接查询比如说有几个函数都是打到 hello world 里面，可以通过函数名称、服务名称、来找到指定函数
查看指标的两种或方式：
①是通过函数详情查看监控指标
②通过配置日志大盘
函数计算提供了丰富的系统指标，函数详情查看监控指标是不需要用户任何配置通过控制台查看；
日志大盘不仅可以看到函数运算提供的监控指标，同时可以和开发者的日志关联到一起生成自定义的监控指标。
首先看一下默认的监控指标
这里可以看到之前使用的函数情况、执行时间、错误情况、调用次数等
返回首页-配置日志大盘，新建关联（关联自己的 Serverless）
就可以看到监控大盘了，会展示一些指标
链路追踪
链路追踪可以分析分布式系统中请求在各个链路的时延
链路追踪是分布式系统排查问题的重要一环，可以分析分布式系统中请求在各个链路的时延有以下几种情况
1. 函数计算作为整个链路中的一环，可以看到请求在函数计算上的时延，时延包括系统启动的时间和非智能函数执行时间可以帮用户分析性能瓶颈。
2. 函数计算当中调用 SDK 可以默认看到 SD K的调动时延
3. 开发者在函数代码中访问数据库等产品可以手动在函数中埋点来分析这段时延。
tracing-service 和 tracing-function 有两个大段一个是系统的启动时间一个是函数的执行时间，系统的启动时间大概是650毫秒准备代码，启动 right time 用了400毫秒。
函数代码是函数去调用了其他服务，比如说去访问了 IDS，可以看到请求在函数计算整个的一个延时瀑布图，可以帮助用户分析性能瓶颈。
三、性能问题排查
最后解读性能排查，详细介绍排查示例
场景一：新版本发布后，函数错误率升高
场景二：函数性能差，执行超时
场景三：业务量迅速扩张，并发度即将到达并发度限制
①场景一是新版本发布后，函数错误率升高，首先发布版本之后要首先观察函数的各项指标，一旦错误率升高就要立即回滚来避免故障 ，查看函数日志定位错误原因，修复问题再次上新。
②场景二是函数性能差，执行超时，在函数内部可能耗时的地方进行埋点，查看请求的瀑布图，定位时间长的原因并且修复问题。
③场景三是业务量迅速扩张，并发度即将到达并发度限制，在Metrics 看到当前并发度观察到并发度持续上升的时候就需要及时提升并发度。
