IT系统为什么需要可观测性
时间：2023-02-20 20:30:00
大家好，我叫齐亚轩，云杉网络创始人和CEO，我很荣幸能参加云杉的第一次直播，与大家分享我对可观测性的认知。
可观测性是监控领域非常流行的技术，特别是面对云原生场景，可观测性几乎已经成为IT系统的必要能力。当然，我的许多朋友、客户、合作伙伴和投资者，包括你有人，都对可观的发展充满了好奇和期望。
今晚，我分享的主题是IT为什么系统需要可观察性？我希望我能从价值、技术等方面回答这个问题，并澄清我的独立思考。当然，我希望与观众互动，讨论可观察性的发展趋势。
我分享的话题包括可观测性的五个方面。我将直接进入主题，首先告诉你结论。
首先，为什么需要可观察性？答案是赋能。可观测性的基本价值是给予IT赋能人员。让工程师、架构师甚至CTO、CIO能够随着技术的进步而进步。
关于如何理解可观测性，我总结了几位业内大神的定义，他们的观点很有参考价值。同时，我也根据自己的分析和理解提出了独立的观点，即白盒监控。
如果你不能评估他，你就不能改善他。对可观测性的评常重要，基于对白盒监控的理解，我给出了三种可观测性评估判断，以帮助您选择合理的可观测性技术。
关于如何构建可观测性，只有三种方式：SaaS这三种方式对大多数企业来说都非常重要，包括服务、开源开发和集成产品SaaS满足快速体验，开源满足业务需求，集成满足行业合规。
最后，关于如何使用可观测性，我将分享多个行业的十多个实际用例。重点关注智能汽车和股份制银行的两个用例，并简要分享其他行业的十个案例，以提高每个人对可观察性的认识。
01｜ 为什么需要可观察性？
May the force be with you. 云杉内部的研发团队经常引用the force，即原力来描述可观测性的作用。可观测性是工程师、架构师和技术总监的赋能。
对于工程师来说，可观察性可以让每个人都掌握技术趋势，深入了解云本地技术和分布式系统。让开发工程师了解基础设施，让系统和网络工程师了解应用程序。在云本地时代，整个堆栈能力是工程师自我修养的重要组成部分，当然也是未来晋升和加薪的保证。
对于架构师来说，通常面临的挑战是如何让IT该系统可以支持业务量以十倍的速度增长。这种增长速度不能在没有云本地和其他新技术的情况下实现。然而，技术创新的背后是巨大的风险，可观察性为新技术的应用奠定了坚实的基础。一方面，通过监控自助服务，大大加快了新业务的发展和测试速度，另一方面，通过全堆栈链路跟踪，确保了业务生产后的稳定运行。
对于CTO对于技术领袖来说，组织能力的提高是极其重要的。虽然公司的数字化业务增长迅速，但IT然而，团队组织结构和人力资源很难发生重大变化。因此，有必要建立数据即事实的团队合作原则，消除部门之间的合作障碍，有效提高组织的合作能力。
说到这里，解释为什么可观测性可以比作原力。
可观测数据已经存在，只分布在各个部门。可观测平台的建立是数据的收集，可以认为是从各个部门收集的。
可观测服务是通过收集数据反馈各部门，即形成可控的原力yoda像老师这样的绝地武士。
02｜如何理解可观测性？
可观测性有很多不同的定义，最流行的是三大支柱。三大支柱即metrics、tracing、logging。三大支柱之所以广为流传，是因为它们最容易被工程师理解和接受。然而，三大支柱的提出者，Peter Bourgon恐怕不是每个人都真正理解原意。
Peter Bourgon非常务实地指出，讨论可观性需要明确讨论对象，并对不同的数据类型进行不同的优化。请注意，Peter Bourgon原意不是说可观测性是三大支柱，而是让大家分析具体问题。Metrics，不同的场景也有不同的含义和处理方法。
Google Dapper作者(谷歌分布式跟踪系统)Ben Sigelman更是直言，metrics、tracing、logging只有三种数据类型。言下之意，还是具体问题要具体分析。Google Dapper大家应该多少了解一下论文。看看google如何通过零侵扰和轻量级跟踪技术帮助团队调试和诊断分布式应用。
因此，对这三个支柱的合理解释应该是，可观测性需要多种数据类型，每种数据也应该在不同的场景中选择不同的处理方法。我希望你能记住这一点。如果你将来看到一个兄弟把可观测性等同于三种数据结构，最好建议他读Peter Bourgon的Blog原文。
Charity Majors她是我非常尊重的创始人。她是一个持续的企业家，也是一个Facebook工作过，近年来成立了Honeycomb该公司专注于可观察性。她提出了一个非常独特的观点，即可观察性用于解释unknown-unknown问题是，这句话听起来有点神秘。
我跟大家解读下：unknown-unknown探索未知问题可以简单理解。
在软件工程中，有一套完整的debug帮助开发人员在软件中发现未知问题的工具。在分布式系统监控中，可观测性扮演类似的角色debug通过交互式跟踪，将工具的角色定位为未知问题。请注意，探索未知的说法实际上是Charity Majors借用了软件工程的理论来做可观测性。这样的想法，跟着Google SRE思路完全一致。
在Google SRE book第十二章明确表示，可观测性的目的是快速排除障碍物。由此可见，软件工程是可观测性无法绕过的门槛。如果你想唤醒大家对软件工程的记忆，不妨重读《人月神话》，必然会有新的体验。
与这位哥哥(鲁道夫卡尔曼)相比，Peter、Ben、Charity再牛，也只能算是三体文明，这才是真正的神级文明，因为他发明了定律。现代控制理论之父鲁道夫卡尔曼提出了系统的可观测理论，并在此基础上将人类送到了月球上。
那么，在神级文明的定义下，可观测性是什么呢？以下定义来自维基百科全书。首先，控制理论中的可观测性是指系统可以通过其外部输出来推断其内部状态的程度。其次，一个系统是可观测的，只是：对于所有的状态向量和控制向量，只能在有限的时间内根据输出信号来识别当前的状态。
这个定义非常抽象，但我可以帮助你关注：首先是外部输出，其次是内部状态，最后是有限的时间。
例如，新冠肺炎核酸检测：外部输出被棉签刺伤，内部状态是肺部是否被冠状病毒感染，有限时间为3~8小时。如果不是外部输出，就意味着需要抽血或手术；如果不是内部状态，就不能分诊治疗；如果时间不限，要么疫情泛滥，要么不能出行。
理解了这三个重点在防疫中的含义，下面就可以讲讲他们在IT解读系统。
现代控制理论利用状态空间描述系统，通过可观测性和可控性解决复杂系统的控制问题。借用控制理论中的可观测理论，引出我IT系统可观测性认知。
首先，状态空间代表白盒监控，即清楚了解系统的内部状态，否则很难实现复杂应用的诊断。其次，外部输出意味着系统应该是零侵入，特别是业务，否则会干扰系统的运行，无法实现控制的目的。第三，内部状态必须是多维的IT就系统而言，它是我们常说的全栈，包括应用、系统、网络和各种中间件。
最后，有限的时间意味着实时性。从开发测试的角度来看，调试速度应为分钟级，从生产保证的角度来看，故障响应速度至少为分钟级。因此，为了支持分钟工作流，可观察平台的响应速度必须为秒。
基于以上分析，我也提出了自己对可观测性的理解。简单地说，可观测性是复杂的IT系统寻求白盒监控能力。IT系统的可观测性应具有零侵扰、多维度、实时性等关键特征。以上是我对可观测性的理解。如果有不准确的地方，我希望能和你讨论和学习。
要进行真正的技术创新，我们必须有一个独立的观点。虽然进口产品很好，但它的真正意义却很少。我希望在中国做可观察性的朋友能够进行更多的交流，并产生更深入的理解。稍后，我将根据上述理解进一步阐明可观察性的技术和价值。
03｜如何评估可观测性？
去年12月，我和一家保险公司合作IT架构部门交流，谈到传统APM腾讯会议对面的一个小女孩突然跳出来说:你怎么打桩？。当时我很惊讶插码的工作已经上升到了打桩的难度。但是为什么小女孩要打桩呢？
另一个真实的case，去年10月，一家股份制银行被用作股份制银行POC报告显示，对方普罗米修斯服务响应时间超过30次s，顾客说，这很正常。
让985年毕业的小女孩打桩？每次检索数据都要花时间写一行新代码？这不是新一代IT残酷的现状需要改变。
必须解决以下问题：
在数百项服务中发现瓶颈：提供非采样、秒精度、HTTP/DNS/GRPC等性能指标数据
跟踪应用程序数千次访问：提供应用层Trace跟踪数据，网络层Flow追踪数据
在数万个容器中定位根因：提供全栈（API、主机、基础设施)端到端指标数据、日志数据
还需要零侵扰和实时性来解决上述问题。
零侵扰判断：
传统APM/NPM等待工具，要么在应用程序中打桩插码，要么在基础设施中需要分光镜像IT侵扰系统。
可观察性要求使用外部数据进行分析，因此需要通过零侵入来获取监控数据。监控数据不需要打桩、插码、分光镜像，而是通过开放系统架构直接获取。另一方面，零侵入需要低功耗，不能影响应用程序或基础设施性能，例如，通常采集点功耗不能超过业务功耗的1%。
关于多维度判据：
要保障云原生应用稳定运行，可观测性必须包含多维度数据分析能力。具体来说，要将应用的API、容器、主机、网络等监控数据进行全栈关联分析。传统的APM工具，可以定位代码层问题，却无法追踪容器或主机网络服务引起的故障。而传统的NPM工具，又不能关联应用的TraceID从而追踪穿越NAT、LB等网元的流量。因此，多维度的全栈数据分析，是可观测性的第二个需求。
关于实时性判据：
自动控制中，过大的传感器反馈时延，会导致系统震荡而不可控。与之类似，云原生应用的动态性要求可观测性平台必须具备实时性。如果应用的升级/扩容在分钟级完成，那么监控系统就必须提供秒级的反馈能力。注意，这里的反馈需要对海量指标/追踪/日志数据进行查找分析，因此对可观测性平台的海量数据实时处理能力提出了极高要求。
再回到原力的类比，如果没有零侵扰，可观测性平台，也就是原力收集平台，无法被大家接受。如果没有多维度，原力无法关联，自然失去了其意义。如果没有实时性，原力无法有效释放，被大家掌控。人的感知时间是秒级别的，因此实时性必须做到秒级。
有了上述判据，就可以定量评估可观测性技术了。
为了说明可观测性的技术评估，我这里依据自家产品，聚焦到两个核心技术趋势之上：eBPF和OLAP。eBPF解决了零侵扰，以及部分多维度问题。
如上图所示，左图中是一个接近全栈的多维度监控对象，其实就是一台服务器。可以看出，自下而上有，主机HOST系统，HOST的网络协议栈，虚机VM系统，虚机网络协议栈，容器POD，进程容器、Sidecar容器、应用进程等等。
传统APM，通过“打桩”，也就是插码，或者java agent的方式，能够对应用进程进行监控，即使扩展，也只能监控到部分sidecar。传统NPM，通过对设备的分光镜像流量，可以监控主机出入的流量，扩展后可以监控主机上虚拟交换机流量。
云杉DeepFlow v5.0 产品，在NPM基础上，利用classic BPF技术，通过host的用户态（零侵扰）监控到主机及虚机的系统和网卡流量。DeepFlow v6.0 产品，利用eBPF技术，进一步在零侵扰的前提下获取了应用和sidecar的信息，扩展了多维度的能力。
做分析，离不开OLAP。可观测性的工程师，自然就是数据分析的工程师，OLAP能力不可缺失。过去三年时间，云杉DeepFlow产品中的关键数据组件，经历了两次重要的升级。
2018年使用ES作为主要引擎，读写速度无法满足实时性要求，只能为数百台规模的业务集群实施可观测性。2020年初，DeepFlow v5.5发布，融入了深度优化的InfluxDB作为Metrics引擎，使平台性能提升10倍，可以解决数千台服务器集群的可观测性。
2021年12月，DeepFlow v6.0的第一个版本发布，进一步融入了深度优化的ClickHouse作为观测数据的OLAP，读写性能再提升10倍，满足金融及互联网客户的数万规模的集群部署。
如果说摩尔定律是芯片演进的金科玉律，每18个月芯片效能增长2x。那么云时代的可观测性也不难预测：即每18个月观测数据读写速率增长10x。关于可观测性的概念和技术，讨论到此为止。
然而，纸上得来终觉浅。可观测性实战要真正落地，大家又面临哪些问题呢？
既然可观测性是一种原力，而原力的掌控能力是一种增长的过程，那么我这里就借亚马逊的飞轮模型，来说明如何增长可观测性。
增长的第一步是理解和体验，体验可观测性的最佳方式当属各类SaaS服务，这些可观测性的SaaS服务可以让大家快速理解可观测性的价值。
增长的第二步是加速业务创新，也就是要满足业务部门的快速发展需求。开源是技术团队应对快速创新的最佳路径。因此，如何用开源技术构建可观测性平台是增长飞轮的第二步。
增长的第三步是满足生产需求，创新一旦完成，就要面临合规性、稳定性、安全性等一系列挑战，集成能力之于可观测性，就是赋能本身，让业务团队、基础设施团队、安全团队都能有效运转起来。
由于技术的不断进步，可观测性的飞轮将往复运行。K8S的体验之后，是Serverless，Prometheus之后是Skywalking，APM的作战半径不到20%，全链路成为永远的梦想？可观测性的增长飞轮，将引领大家解决上述问题。
04 ｜ 如何构建可观测性？
构建可观测性的第一种方法，也是最快捷高效的方法，就是使用SaaS服务。目前，云厂商独立第三方企业均提供可观测性的SaaS服务。云厂商，比如阿里云，提供了ARMS应用实时监控服务，近期推出的K8S监控服务大家可以去体验一下，代表了可观测性的发展趋势。阿里云上还有一个更基础的可观测性服务，就是SLS日志服务，用户可以将自己采集的观测数据存入SLS服务中，并按需使用。
相比而言，ARMS提供的是一站式服务，而SLS则给予了更多的自由度。国内的腾讯云、华为云等，也都提供了可观测性服务。如果是AWS、Azure的客户，那么可以直接使用Datadog，这个500亿美金市值的公司，可以看做是可观测性的领军企业，而且主要以提供SaaS服务为主。
国内的第三方提供商，目前看到的有观测云、乘云等，云杉也提供名为DeepFlow Cloud的SaaS产品，方便大家体验。
SaaS服务的主要问题，是用户的应用大概率需要跑在公有云上，并且观测数据要由第三方管理。此外，SaaS的计费模式相当复杂，有按主机规模计算的部分，也有按数据量计算的部分，总之很难准确规划这方面的预算。
因此，对于中小企业SaaS是首选，但对于中大型客户，尤其是采用混合云架构，合规性要求高，项目预算制的大型行业客户来说，很难仅仅依赖SaaS提供可观测性服务。
因此，才有了飞轮中的另外两种构建模式，开源和集成。
这个时代，整个IT系统都是构建在开源之上的，可观测性也不例外。依托开源技术构建可观测性平台，是快速技术创新的必由之路。
如图所示，自底向上构建基于开源的可观测性平台，可供选择的开源组件非常丰富。采集层，要实现零侵扰采集，可以采用K8S的daemonset采集器，java agent，普罗米修斯的部分exporter等等。
采集层要注意的是，云原生体系下，监控数据要遵循开放标准，这样整套系统框架才能不断演进，扩展。采集层的开放标准主要是statsd和opentelemetry，尤其是opentelemetry，大有一统江湖的趋势。
采集层之上是数据层，之所以是数据而不是存储层，是因为要满足实时性要求，读存写必须分离。本质上数据层就是一个实时数仓，要针对应用场景，进行深度的读存写优化。实时数仓方面对技术要求较高，可以跟有经验的团队或厂商一起开发。
数据层之上，是展示层。指标、追踪、日志、告警，分别由grafana、skywalking、kibana、prometheus等常用组件支持。让这些开源项目支持更多种类的数据展示，同时为不同部门提供不同场景的APP、WEB、CLI、API，是可观测性平台团队的主要工作。
下面我们来看一个我们的客户，是如何改造Grafana，为微服务提供可观测性的。
客户的开发团队，要求对每一个微服务提供精细的指标监控，包括HTTP、DNS的RED指标，即用量、错误、时延指标，也同时要求TCP和网络层的各类指标，形成全栈链路监控能力。客户的业务团队还要求把每个微服务的全局调用关系实时展示出来，这些工作都是客户的平台团队基于Grafana二次开发完成的。
如图所示，虽然每一个展示的子视图，大多是Grafana自带的，但视图中的数据，都不是开源的telegraph可以直接获取到的。
事实上，客户在数据层与采集层与云杉团队合作，解决了上述数据的零侵扰采集和实时读存写问题，客户团队更多专注于Grafana的二次开发，快速满足业务需求。由此可见，开源项目并不是拿来就能用的，而是需要依据业务需求进行快速开发。如果把时间花在改进开源项目的性能上，那应该由专业团队来做，并依据开源协议为社区做出贡献。
第三种构建可观测性的方式就是集成，integration。集成听起来没有SaaS和开源性感，但我认为，集成的难度最大，因为集成的约束条件太多。这些约束条件包括，理解业务需求，提出合理预算，满足行业合规，推动部门合作等等。
每一个地方出现问题，都会造成集成项目无法落地，或者无法创造价值，最终导致项目失败或难以持续发展。集成的问题非常复杂，我这里提出两种解决思路。
第一个思路是”数据即事实“，部门之间的协作应该建立在数据事实的基础之上，而不是个人主观的描述，避免责任推诿，促进团队协作。
第二个思路是”业务为中心“，无论开发、测试、系统、网络、安全等团队，均需要深入理解业务，从对代码、系统、设备的负责，变为对业务上线速度、交易量、健康度的负责。
思路好理解，但落地仍然不明确，下面我们举一个栗子来进一步说明集成的复杂性。
这是某大行网络工程师给我们的发展规划。诸位听众中如果有网络工程师，可以对比下是否有这样的先进思路？
首先，集成的第一步是全栈流量采集能力，而这里考虑最多的是零侵扰特性。零侵扰被进一步划分为：稳定性、可用性、资源耗损、通用性、存储消耗、网络消耗等问题。每一个问题都需要严格的长期测试才能验证。
第二步是建立分布式系统的诊断能力。这里面考虑最多的是多维度分析能力。协议栈设计到了物理机、虚拟机、容器、业务码等，并且要求提供全栈链路追踪。另外要求能够被大数据平台和其他监控平台通过API集成。
第三步是对外服务能力。也就是之前所说的原力释放阶段。这里考虑最多的是场景和自服务。场景包括了全网监控、应用监控、客户监控、安全监控等，自服务则要求主要功能均通过用户自行完成。由于不同场景需要不同的数据支持，背后技术涉及到了实时数仓的建立和集成。
新一代的网络工程师，借助可观测性，实现了自我价值，并提升了团队间的协作能力。与之类似，系统团队、开发团队、SRE团队等，均可以通过集成方法构建可观测性平台，以提升团队的自身价值和协作能力。
05 ｜ 如何使用可观测性？
前面分享了可观测性的三种构建方式，下面我们来看看可观测性如何在实战中发挥价值。这里我会较详细讲述两个典型用例，同时也会快速介绍其他10个用例，以此打开大家的思路，体会可观测性的不同用途。
第一个用例来自某智能车企，其业务变化非常快，公司采用公有云+容器化部署核心业务，并通过整合各类开源监控软件，构建“统一业务监控平台”。公司业务迭代速度非常快，但微服务观测不全一直是困扰着业务快速上线的一大问题。业务上线后遇到故障只能靠猜、靠逐段抓包诊断故障原因，费时费力。
近期在生产环境中，nginx-control上线过程中出现了某API（xxx-api）调用某服务（xxx-service.prod.k8s.xxx.com）超时的情况。虽然现有系统能定位到工作负载和服务域名（即源和目的），但其间经过多个微服务和网络服务，到底是谁引发了访问中断却不得而知。
由于客户端、服务端均没有（或无法）部署Skywalking监控、没有采集日志，开发人员不知道超时原因。这个问题经过一整天排查未有结论，严重影响业务上线进度。借助可观测性的全栈能力，SRE团队在15分钟内定位到了根因，即问题出自一个特定的Ingress Control的容器POD。反馈到开发人员后通过修复Nginx快速恢复了故障。
第二个用例来自某股份制银行，该行在国内外的100多个城市设立了服务网点。很多业务部署在云平台的容器上。该行私有云平台上运行着10万多个微服务，数十万个POD支撑业务，每分钟业务产生的访问数亿次。
该行业务运维人员经常遇到关键资源访问量徒增问题，尤其是云上云下互访时，“谁动了我的数据库！”是常见抱怨。要追查出到底是谁动了关键资源，难点重重。
难点之一是可疑分子太多，可疑分子隐藏在8万多个POD，8千多个Node、1千多VM、1千多Host之中。难点之二是每个可疑分子到关键资源之间，至少经过两次地址转换，且POD、Node、VM、Host、PIP、GW的访问路径非常复杂。难点之三是业务POD上不允许抓包，网关GW上也难以抓包（网关抓包丢包率高达40%)。
上述问题通过可观测性就得到了良好解决。首先，可观测性平台提供POD、Node、VM、Host、GW资源上全量网络流量采集，解决了POD、MUX上流量采集难的问题其次，可观测性平台同步了云平台NAT、LB等转换规则，通过服务端源IP地址、目的IP地址，分钟级在海量数据中，找到对应的POD、Node、VM、Host；最后，可观测性平台为业务部门梳理出来常见的全栈链路观测模板，助力业务部门分钟级定位业务性能峰值问题。
如图所示，根据业务场景，访问路径非常复杂，需要层层梳理。否则不可能解决”谁动了我的数据库！“问题。
第一个用例，是某银行在开发测试中遇到业务周期性抖动，持续一周无法上线。最终通过可观测性发现了底层路由器环路导致。
第二个用例，某地产商的电子流应用，上云后每周都出现问题。最终通过可观测性发现了服务商DNS不稳定、开发团队违规升级代码、依赖第三方服务异常等一系列问题。
第三个用例，某大型金融企业，电商业务运行的容器平台，每扩展一个POD竞耗时超过1小时，而且要反复不停重试。后根据可观测性分析，逐步定位到某物理网卡对ARP请求产生了内部回路，更换机器后恢复正常。
第四个用例，某运营商省公司在集团对应用的可用性考核中，年年全省垫底。最终通过可观测性，发现了LVS、nginx和某物理交换机之间的链路有丢包，彻底排除了困扰已久的问题。
第五个用例，某大型私有云客户，发现其关键业务中的SQL集群频繁主备切换，虽然业务没有中断，但风险极高。后经可观测性平台分析，发现是SQL切换仲裁在并发并不高的情况下就停止了服务，最终导致了不必要的切换。
第六个用例，某银行个人贷款业务突然访问变慢，在大家都怀疑是网关丢包的情况下，通过可观测性平台，定位到了DNS服务异常。而且，进一步发现不仅仅是该业务的可用区DNS异常，其他区域也有普遍现象，根本原因是DNS配置错误。
第七个用例，某BI业务，运行过程中出现性能抖动。业务侧看到的只是客户端到BI的访问路径，而可观测性平台看到的是业务端-NGINX-BI-RPC-MongoDB的整体依赖。后定位为RPC服务中有一个容器出现问题，排除此容器后业务恢复正常。
第八个用例，某省消防队，经常被省里通报，尤其是护网期间通报，必须排除通报的安全问题。由于全省消防内网复杂，而通报又只针对不到10个对外服务的IP，如何追查内部攻击源变得非常困难。通过可观测性平台，该省消防队实现了10分钟内应答通报的能力。
第九个用例，某大型容器云平台，按传统pcap分析方式运维，一次简单故障平均查找数千个数据包，耗费专家数小时的宝贵时间。通过可观测性平台，业务排障由抓包分析变为微服务RED指标监控和全栈链路追踪，排障效率从小时级变为分钟级。
第十个用例，某农商行，视频业务上云后访问量增长近10倍，经常出现业务访问慢问题，几次扩容都不能解决问题。后根据可观测性平台分析，发现是某个隐藏服务异常发送RST包导致，优化服务的队列和超时设置之后，业务恢复正常。
我这里先简单介绍10个用例，更多更精彩的用例分享，会由我们的同事、客户和合作伙伴在后面的直播中跟大家继续分享。
好了，总结一下今天介绍。
为什么需要可观测性，就是给大家”赋能“。让工程师、架构师、以及技术管理人员能够提升自我的认知能力、创新能力和组织能力。
如何理解可观测性，介绍了三种不同的视角：
三大支柱说，也就是three pillars，来自Peter Bourgon，背后是数据结构理论。
探索未知说，也就是unknown-unknown，来自Charity Majors，背后是软件工程理论。
白盒监控说，也就是white-box monitoring，是我根据控制理论中可观测性的定义推导出来的。
如何评估可观测性，主要三个方面，零侵扰、多维度、实时性。之前的介绍中也给出了详细的判据和背后的技术趋势。
至于如何构建可观测性，介绍了三种方法，SaaS用于体验、开源用于创新、集成用于合规。
你可能还喜欢
点击下方图片即可阅读
云原生是一种信仰 🤘
关注公众号
后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具，只需一条命令，连 ssh 都不需要！
点击 "阅读原文" 获取更好的阅读体验！
发现朋友圈变“安静”了吗？
