杨琪
9 年专注于操作系统、网络、云原生、Serverless 相关技术研发工作。从传统网络到容器网络技术都有所了解，具有丰富的后端研发实践经验。
大家都有对线上系统排障的经验，我一直认为查找bug是计算机行业中最神秘、最有创造性的一项活动，众多老手能够凭借自己丰富的经验以神乎其技的方式迅速找到问题根源，事后无论是本人还是旁观者似乎都很难系统性的描述查找bug的思路，仿佛是灵感一现，模模糊糊觉得是哪里的问题，于是便动手去查。这给计算机行业添加了一些艺术成分，但也暗示着这种方式很难复制。
这好比医学，各种现代化的手段比如CT、B超、核磁共振能够清晰的反映我们身体的内部结构，医生再以这些信息作为依据，为病人进行诊断，这些可视化工具帮助现代医学以更加科学的方式进步。计算机世界的基础是0和1，更应该以确定性为基础，其上运行的系统应该像现代医学一样，能够通过一些工具直观地反映内部运行状态，如果生病能够反映病灶，如果不那么健康能够预警，如果非常健康也能达到体检的效果。
对云原生有了解的读者对于CNCF这个组织肯定不会陌生，CNCF提供的全景图中，有一块区域列举了可观测性领域相关的众多项目，可观测性作为一种观察系统的理念，不同于基于固定模式的监控，它强调更加深入了解系统，了解系统的指标、拓扑、性能瓶颈、请求链路等细粒度信息，通过对数据的挖掘发现问题的答案，并简化信息的访问。
随着微服务的发展，一个线上应用可能包含数十个甚至上百个微服务，数量众多的服务如何治理是大家最先看到的问题，但面对如此规模的系统，很难有一个人能够完整全面的了解系统的每一个组件，如何监控以及观测系统也比以往任何时候更加重要。
研发人员更愿意花费精力在Day0/Day1环节，这是一个系统的早期方案确定以及研发阶段，因为这个环节更加充满创造性，非常适合富有挑战精神的开拓者；但这一现象的反面是，Day2 环节往往被忽视，在这个环节需要真正部署应用，并监控、维护、优化、再迭代这个线上业务，直到整个应用生命周期的终点，这是一个长期且相对不那么有创造性的阶段，本文聚焦在Day2阶段的可观测性这一主题，结合云原生以及Serverless场景，强调它的价值。
前文有描述一个老手排查线上问题的例子，可观测性目的是将整个系统更加透明化，不再依赖个体经验去猜测系统的细节逻辑。但可观测性也不是“银弹”，能够代替工程师定位bug，它更像是一种理念，尤其在微服务以及云原生时代下，这种理念的价值在于能够应对系统日益复杂，难于观测，难于控制的挑战。
可观测性最初以谷歌发布的Dapper论文为理论基础，使用三种遥测数据：日志、指标和请求轨迹作为组成部分。
日志能够携带完整的上下文信息，能提供最为完备的原始信息，方便后续进行信息的二次加工，但是缺点是数据的传输以及存储开销巨大。
指标数据能够提供更加抽象的统计信息，开销相对固定，方便监控以及告警。
请求轨迹信息能够从单个请求的角度描述系统的拓扑，如果对每个请求都进行记录，开销依然非常大。
日志以及指标信息能够很好的描述系统中的单个服务，而请求轨迹描述了系统处理请求时的跨服务的整体信息。
近几年为了更好满足系统可观测性，诞生出了OpenTelemtry、Prometheus、Fluentd、Elastic等非常优秀的项目，简单介绍一下OpenTelemetry：
OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.
OpenTelemetry 和一些可观测性后台（比如Jaeger或者Prometheus）不同，主要提供的是一组API以及SDK规范，规范了Logs、Metrics、Trace数据的格式，不提供后端服务（比如存储、查询、可视化等），支持插件化的Exporter，以规范化收集和发送遥测数据为目的。
OpenTelemtry对于可观测性的价值就像Kubernetes对于容器编排的价值一样，OpenTelemetry拥有强大的社区支持，基于这个标准，各个系统模块能提供强大的互操作性，用户能够自然而然的享受到最新的可观测性工具，降低学习以及迁移成本。
OpenTelemetry 能够很好的解决云计算虚拟化时代的可观测性问题，但是Kubernetes环境下的可观测性不同于虚拟机环境。
Kubernetes组件是分布式部署的，它们之间通过声明式语义协作，以周期性调谐方式推进流程。在Kubernetes环境下的可观测性并不只是简单采集应用维度的数据，还需要收集各个组件的数据，这种高度抽象的以应用为中心的API对于开发者而言非常便捷，但却给可观测性带来了巨大的挑战。
Kubernetes 环境下应用负载的高度动态特性
在Kubernetes环境下，有一个经典的比喻，将应用划分为“宠物”以及“牲口”，Kubernetes 能够很好的支持无状态应用，计算存储分离之后，无状态应用也是 Kubernetes 生态下最为主流的应用负载。无状态应用的工作负载就类比于“牲口”，容器实例会因为工作节点上的资源紧缺、调度优先级、节点宕机等原因被随时迁移，“牲口”一词想表达的含义是保持数量不变，但是个体是可以替换的。传统基础架构并不会这么“动态”，虚拟机不会频繁的重启，各种可观测性数据都能够长期在一个稳定的节点上采集。这也使得Kubernetes环境下可观测性更加困难。
虽然相比虚拟机环境，在Kubernetes环境下做可观测性更加困难，但依然有许多方案可供选择。
一些开源项目比如LogsStash、Fluentd 都可以收集日志，它们以DaemonSet的方式部署在每个节点之上，能兼容多种输出格式，对于输出到标准输出的日志，这些方案能够确保日志被妥善保存到后端日志采集系统中。如果更进一步，采用类似ElasticStack的整体方案，能够提供日志收集、检索、展示一系列功能。
Kubernetes 暴露了三种API用于支持Metrics，基础监控 metrics.k8s.io，用户自定义 mtrics custom.metrics.k8s.io，外部组件 metrics external.metrics.k8s.io，Metrics Server实现了基础监控API，Prometheus Adapter实现了后面两种API，这些指标数据后续都可以作为HPA的弹缩指标。
基于Mesh方案能够在Kubernetes环境下，做到无侵入的trace收集，但有一定的性能损耗；对于动态语言，比如java，可以通过类似java agent的方式以兼容OpenTelemetry标准的方式上报trace数据，同样也是无侵入的；对于其他语言，也有非常丰富的SDK支持以OpenTelemetry标准上报Trace数据。
云原生给企业带来的价值是降本增效，期望为企业提供按需使用、随时扩展、按量计费的一种资源交付方式，这种特性经常被比作云原生时代的水和电。
https://blogs.vmware.com/vov/2018/08/07/how-technology-powers-our-cloud-native-development-environment/
上图列举了云原生时代各种服务形态，从传统时代需要自建机房管理风火水电，然后到IaaS的不需要管理风火水电，到最后FaaS时代只需要关心业务以及数据，很明显能看到一个趋势，让业务能够更加专注于业务。
Serverless技术因为屏蔽了服务器的各种运维复杂度，比如资源申请，环境搭建，扩缩容等等细节都由平台来进行维护，能够让业务更加专注于业务。所以Serverless技术成为企业上云的一种新的方式。
Gartner最近发布了他们对于2022技术趋势的一个预测报告，其中有一个条目叫做Cloud-Native Platform，它所表达的这一类平台会向他的用户提供一种“可扩展的弹性的”服务，也就是用户能够直接使用，而不需要关心细节。这就非常符合Serverless的核心观念，也就很好地证明了Serverless是未来的一种趋势。
Cloud-Native Platforms (CNPs)
To truly deliver digital capabilities anywhere and everywhere, enterprises must turn away from the familiar “lift and shift” migrations and toward CNPs. CNPs use the core capabilities of cloud computing to provide scalable and elastic IT-related capabilities “as a service” to technology creators using internet technologies, delivering faster time to value and reduced costs.
---《Gartner Identifies the Top Strategic Technology Trends for 2022》
Serverless平台除开k8s固有的组件分布式、调度黑盒、标准不统一这些因素之外，还有额外一些阻碍可观测性的困难。其中最重要的一点就是可观测性和Serverless的哲学相违背，Serverless提供的是基础设施免运维的语义，那么为什么还需要提供一套可观测性的工具让用户去关注底层？用户获取这些信息之后并不能干预底层资源的调度和运作，这些信息有什么意义吗？
面对这些困惑，各大厂商Serverless产品依然提供了可观测性的支持，这里的原因与可观测性的目的相关，正如前文介绍，可观测性更像是一种白盒方式观察系统的手段，不同于监控，监控是以发现故障并及时响应为目的。对于一个完全正常运行的应用，可观测性也有它的价值，比如发现系统的拓扑、获得某个请求的上下文、发现系统中可能存在的瓶颈、以及发现可以进一步优化的模块等，这些都是可观测性在Serverless平台的价值。
再比如，基于 OpenTelemetry 采集的指标数据后续可以用于实时、基于预测的弹缩，或者AIOps等场景，这在Serverless场景下对于缩短冷启动延迟有很大价值。
除开技术层面的收益，可观测性还有一些“软性”价值。以腾讯云TEM为例，提供面向应用的 Serverless 服务形态，这对于很多客户是一个比较新的事物，客户从自己熟悉的VM环境迁移到 Serverless 平台，碰到问题往往会怀疑是平台的问题，需要平台协助排查，这在客户数量比较少的时候，平台可以做到贴身服务客户，但一旦用户量上来，这不是一种可持续的方式。如何将令人信服信息展示给用户，甚至协助客户发现以及定位问题，这就是可观测性对于一个 Serverless 平台提供的“软性”价值——增强用户信心、节省平台人力成本。
具体如何做 Serverless 平台的可观测性呢？在平台建设初期，可以依照 Kubernetes 可观测性的做法提供包含Logs、Metrics、Trace信息的数据，并随着平台的不断成熟，再逐渐丰富 Serverless 平台特有的一些可观测性数据，以腾讯云的TEM为例，可以从以下几个方面去丰富可观测性的支持。
面向应用的Serverless平台以jar/war程序包或者镜像作为输入，其中程序包需要经过镜像构建环节才能运行在资源底座上，整个构建过程各个环节是否成功、耗时多少都是需要展现的信息，这些信息能够帮助用户进一步优化镜像。
以下这段信息就是一个jar包在TEM上构建成镜像的日志信息，其中不仅包含结果信息，还把每一个环节的耗时展现出来，方便用户整体观察构建性能。
#5 [1/9] FROM ccr.ccs.tencentyun.com/tsf_build/tem-buildkit-war-open-base:8.5-jre8@sha256:d8678501dfba53d81e757df1d60454a93c9f832fc2a4f87d0c1687c07e84c04b#5 resolve ccr.ccs.tencentyun.com/tsf_build/tem-buildkit-war-open-base:8.5-jre8@sha256:d8678501dfba53d81e757df1d60454a93c9f832fc2a4f87d0c1687c07e84c04b done#5 DONE 0.0s#15 importing cache manifest from ccr.ccs.tencentyun.com/tsf_build/tem-buildkit-war-open-base:8.5-jre8#15 DONE 0.8s...#19 [auth] tem-100011913960-dsxh/svc-test-war-firstdeploy-kgqkyiqs:pull,push token for ccr.ccs.tencentyun.com#19 DONE 0.0s#16 exporting to image#16 pushing layers 5.5s done#16 pushing manifest for ccr.ccs.tencentyun.com/tem-100011913960-dsxh/svc-test-war-firstdeploy-kgqkyiqs:20211122110416@sha256:4ab79d50688355f1011444be8719b86e4b557f0a56e90555d872e8e6d293d9bb#16 pushing manifest for ccr.ccs.tencentyun.com/tem-100011913960-dsxh/svc-test-war-firstdeploy-kgqkyiqs:20211122110416@sha256:4ab79d50688355f1011444be8719b86e4b557f0a56e90555d872e8e6d293d9bb 1.4s done#16 DONE 7.1s
TEM提供白屏化面向应用运维 Serverless 平台，帮助用户聚焦业务开发，屏蔽底层基础设施运维细节，在提供 Serverless 价值的同时，我们也希望通过发布可观测性让用户更加了解其中的发布细节。
这些信息包含原生kubernetes运行日志以及TEM控制面调度信息，Kubernetes运行日志能够帮助用户排查各种难以预见的细节问题，比如：镜像不存在、配额不足、参数不合法等。提供发布环节的一些细粒度信息，方便用户自我排查简单问题，也能够增强用户对发布过程的认知。
TEM基于腾讯云EKS平台提供的 Nodeless Kubernetes 集群托管服务，能提供秒级高并发的弹性能力，TEM提供多种发布方式，以应对用户不同场景下的发布需求，比如：
-
-
分批发布：提供分批次先扩后缩语义的滚动发布，批次间可以采用自动或者手动方式触发；
-
原地升级：同样提供分批次先扩后缩语义的滚动发布，但是保证旧实例ID以及IP不变，并且升级效率更高。
TEM能够联接云上各个产品，提供应用维度的可观测性能力，真正做到博取各家所长。
Logs：基于腾讯云CLS提供应用维度的一站式的日志数据解决方案，用户只需要关联已有的CLS实例，无需关注扩缩容等资源问题，即可享受从日志采集、日志存储到日志内容搜索、统计分析等稳定可靠的日志服务。轻松解决业务问题定位，指标监控、安全审计等日志问题。
Metrics：TEM结合云监控以及APM，基于实时的多语言应用探针全量采集技术，提供丰富的指标数据，包括基础监控、应用监控、接口监控以及JVM监控。帮助用户监控系统健康度，或者对接运维告警。
Trace：TEM结合应用性能观测管理平台，通过java-agent方式，无侵入的协助业务接入Trace上报能力，使得整个请求的生命周期完整呈现。帮助用户从请求维度了解整个系统拓扑以及协助排查线上问题。
微服务、容器化、云原生这些技术带给现代系统更加优秀的理念，但伴随而来的复杂度也比以往任何时候更加困难，如何治理数量众多的微服务、如何进一步提高资源利用率等一些问题已经被人们充分讨论并引起足够的重视，但本文聚焦在云原生环境下 Day 2 的可观测性这一部分，不仅仅因为这一部分较少被关注，也因为如果想做好一个产品，Day 2 的工作会是占比更大也是更加重要的一部分。
https://www.infoq.cn/news/2017/11/observability-monitoring/
https://copyconstruct.medium.com/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e
https://www.infoq.com/news/2017/11/observability-monitoring/
https://www.observeinc.com/resources/observability-in-kubernetes/
https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/
https://lumigo.io/blog/understanding-serverless-observability/
扫描下方二维码关注本公众号，
了解更多微服务、消息队列的相关信息！
解锁超多鹅厂周边！
