一、企业对如何"用好云"仍面临诸多困境
上云已经成为很多客户的共识，上云带来的价值得到了客户的认可。但是企业对于如何合理的使用和管理云资源仍然面临很多的挑战。富莱瑞2023年的一项调研，表示79%的企业在如何使用云上面临缺乏经验的挑战。内部的调研也表明，应用部署的治理和应用的智能运维是客户最重要的上云的考量项，它是直接影响客户决策。Gartner将采用可观测性的技术作为十大战略技术趋势,并表明成功采用可观测性技术,70%的企业将实现更短的决策路径，给他们的业务和整体的IT业务流程带来竞争优势。云服务作为企业重要的IT支撑，云产品的可观测帮助企业实现应用的运维和掌握云产品运行状况的重要的手段。
越来越多的企业通过建设和完善云产品的可观测能力，从而提升自身用云和管云的效率和质量。也发现很多企业建设云产品可观测的人员面临四个比较大的挑战，第一个挑战是数据孤岛的问题，云产品的可观数据分散在不同的产品中，不同类型的可观数据接入分析和告警都需要在不同的产品中切换配置，底层数据也没有打通，数据没有打通会带来第二个大挑战,就是关联分析，在异常定位的场景下，对多种可观的数据进行关联分析，是做定义定位非常重要的手段,云产品的日志指标和调用链,现在是属于一个分散存储的状态，而且观测模型不统一，导致无法快速进行观点的分析。第三个挑战是实质性和灵活性不够，数据延迟。无法获取到原始的数据，也无法基于底层的数据进行字符的灵活的分析，它也会直接影响企业的MTDR和MTD，最后是缺乏专业经验。
二、从“监控”走向“统一可观测”云监控2.0蜕变升级
为帮助企业应对这些挑战，今年阿里云可观测团队对云产品可观测做了比较多的升级，这个设计主要有六大方面，第一个核心升级，是统一接入，即将在云监控2.0中上线统一的接入中心，通过统一的接入中心，可以一站式的支持云产品的日志、指标、事件和链路的接入。第二是关联分析的能力，在统一云资源模型语义的基础上，基于统一的可观测数据存储平台快速实现云产品的关联分析。第三是数据探索，在云监控2.0中，除了内置的一些开箱的、急用的分析能力和异常检测能力以外，将原始的可观测数据交给用户，直接写到用户的名下的日志存储中，基于原始数据，用户可以进行自定义的分析和处理，满足自定义观测的需求。第四是CloudLens，去年面向云产品的可观测，推出CloudLens服务针对特定的云产品推出深入的能力，今年CloudLens能力也进一步升级，推出更多的云产品的垂直的洞察能力，今年多云统一监控做了比较多的升级，能够帮助用户基于阿里云托管的Prometheus服务实现多云和混合云的统一监控。最后结合大模型的能力，推出可观测的Copilot，基于AI的能力帮助用户快速实现云产品的可观测，更好的用好云。
接下来针对升级能力做解读，第一统一接入，做可观测的第一步是数据接入，过往云产品的可观数据是分散在不同的产品中，数据接入、分析和告警需要不同的产品中进行切换的配置，底层的存储没有打通，云监控2.0即将推出一个统一的接入中心，在接入中心一键支持云产品的日志、指标、事件和链路的接入，会大大提升云产品可观的数据、接入的效率和体验，并且针对云上弹性伸缩出来的核心的工作负载，也无需进行二次的手动的配置或者介入，可以基于统一接入中心的自动的服务发现能力，能够实现分钟级的新生产的实例的可观的数据接入，达到生产及可观测效果。数据接入从来都不只是简单的把数据采好，并且放到存储里面，在数据的基础上内置面向不同可观测场景的应用和分析能力，云监控2.0会内置大概1000多张面向于不同产品的大盘，还有多款可观测的应用帮助用户快速实现对零到一的云产品的可观测。
另外在数据采集的探针有比较大的升级，即将推出一个集性能和灵活性如一体的可观测数据的统一采集Loong Collector,在日常运维中对可观数据进行关联分析是异常分析场景下进行更新定位的一个重要手段，但是经常也会遇到一些客户反馈整个可观测数据没有放到一起。观测对象的语义模型也不统一，观测对象的关系也没有自动建立，这是影响进行高效管理分析的最大阻碍,在云监控2.0中，针对云证明会在数据接入以后，它会统一存储在阿里云的可观测数据平台SLS中,基于定义好的观测图谱统一观测的语音模型，同时基于云服务的部署和调用的纵横的关系自动构建云产品之间实施拓扑,帮助用户更方便的进行关联分析，从而快速的做问题的定因定位，case是一个典型的基于云原生架构的业务应用，它分为用户端、应用层和基础设施层，每一层都会产生可观测数据，在云监控2.0中，通过统一接入能力,这些数据都将统一采集并存储到SLS中，并且提供开箱即用的分析大本和告警规则，当业务出现故障的时候，比如在案例里面，运维人员可能某一天收到某个页面的接口耗时突增的告警。
同时他可能也会收到Pod内存使用率的告警，基于页面突增的告警，可以快速的跳转到对应的页面性能分析的大盘,能帮助确定异常出现的时间以及异常指标，再结合端到端的调链，从用户端到微服务可以快就在定位出接口是属于哪个微服务提供的服务，这个接口就是慢调用的典型的调链，再结合部署的应用产生的日志，根据和调链做一个关联分析，可以快速分析出造成问题的具体的代码，结合代码的分析和日志，可以看到因为在某一个查询业务的代码里面存在慢查询，这个调链和日志里面会关联一些观测对象相关的属性信息。比如调RDS数据库，存在RDS数据库的IP和端口。
结合信息，根据观测图谱自动关联出RDS实例自身的监控，结合RDS实例自身的监控，可以看到统计慢查询的次数出现陡增，基本上初步确认因为慢调用造成的，再结合本身的CICD系统部署的日志，可以发现因为在上次的变更中,在某一项业务代码中新增的类似于snake的慢查询语句，而且变更的时间与异常发生的时间也是基本吻合的，基本上确定整体业务异常的原因。
在整个排查的过程中，从用户端的接口慢调用到关联到相关的微服务和后端的调量，再基于调链关联业务应用日志，以及对应的提供服务的RDS实例，整个分析过程在云监控2.0都可以实现快速的关联下载，也可以节省整个的根因定位的时间。对开箱即用的可观测能力，虽然能够帮助用户实现快速的云产品洞察，但是它本身也有一定的局限性，就是它缺乏一定的灵活性，无法满足用户自定义场景的分析需求。希望拿到原始数据进行自定的探索，结合本身的业务特点做监测的大盘，或巡检能力的建设，云监控2.0有比较统一的特点，将所有的可观的数据交给客户，云监控2.0中数据接入，它会统一存储在用户名下的SLS中，会按照不同的数据类型，比如日志 Log Explorer，有指标 Metic Store以及事件Event Store，还有观测对象的Entity Store。
基于这些数据，所有的云监控2.0内置的大盘告警规则,甚至观测应用都是基于用户拥有完全读写权限的SLS中查询实现的，用户也可以基于数据进行进一步的加工和分析，满足自定义的可观测需求。进一步挖掘可观测数据的价值。去年阿里云推出面向云产品的更深入的可观测能力，CloudLens品牌会结合阿里云的专家经验，从可用性、性能、容量和成本异常等多种场景来提供开箱即用的云产品洞察和异常检测能力。
CloudLens会做进一步的升级，首先是CloudLens云产品从7款扩展到11款，尤其是弹性计算团队合作即将发布CloudLens for ECS CloudLens for AI Infra还有clearance for ACK,满足云上客户对于核心的工作负载的更深入的可观测分析，其次除了推出更多的云产品可观测以外，在CloudLens本身结合更多的、更实时的可观测数据来帮助用户从可用性、性能、成本和安全等多个维度对云产品进行深入的洞察，帮助用户更好的应用云产品。
接下来播放demo视频，从demo视频可以看到在云监控2.0的技术中心找到容器服务ACK版,选择接入容器集群，在容器在接入的时候，可以选择不同的可观的数据，现在可以支持指标 日志。比如集群相关的审计日志，选择需要接入的数据，可以点击接入部署采集Lonngcollector。也可以在接入完成以后对采集的配置进行管理,另外在2.0里面也可以进入CloudLens for ACK Demo的应用里面融入集群的性能，ingress监控以及容器集群的审计，还有事件等多个维度，对于ACK容器的可观测进行多方面分析，CloudLens for ACK Demo应用也会随着云监控2.0在10月30号开放邀测，这个是成本分析和资源的优化。
除了有一部分客户，可能会把整个业务都基于云上构建，还有很多企业采用多云或者混合云的架构，针对于多云和混合云的架构，一直以来比较推荐用户的最佳实践是基于开源的Prometheus标准，在阿里云的托管的Prometheus服务上实现多云、混合云的统一监控，基于云上提供的Prometheus服务，可以帮助用户构建一个开放和更加稳定的多云统一监控的系统。阿里云托管的Prometheus服务也做了很多的升级，比如发布托管的Prometheus Agent，托管的Prometheus Agent，它在不占用用户资源的情况下，可以对容器服务、主云服务ECS和云监控的指标数据实现更稳定的采集。
第二是容器服务的团队合作。在基于SKY的链内的能力，可以快速纳管其他第三方云厂商，或者自己IDC中的KPS集群，并且基于托管的Prometheus服务，提供统一的容器监控的能力，目前多云容器监控的能力,很多客户已经落地，也受到很多客户的欢迎，今年和云网管cm团队也做了一个合作，基于CMN能力将线下物理设备和网络设备的可观测，将数据统一写入到Prometheus和SLS中，实现云上和云下的统一。为了满足用户更长周期的指标存储的需求，托管的Prometheus服务也上线一个自动归档的能力，一个Prometheus实例开启自动归档。它在超出热数据存储周期以后，它会自动把超出数据自动放到归档存储中，并且归档存储也支持标准的Prometheus 查询的语法。同时在不改变用户使用习惯的前提下，能够低成本的满足客户长周期的指标存储的需求。
最后一个核心的升级是基于AI大模型，阿里云可观测团队结合大模型能力也做了一些探索和实践。专家经验的趋势是企业对云产品进行深入可观测的重要的挑战。随着大模型应用的进一步发展，结合大模型能力，帮助用户解决专家经验的趋势挑战一些新的解法。
云计构2.0进一步升级Copilot的能力，通过多层次的Agent的能力，结合实时可观的数据、统一的观测图谱以及工单和文档的知识库，对提示词进行增强，再利用阿里云通用大模型的能力，辅助用户进行根因定位、智能巡检和数据分析等多种观测场景，帮助用户提升任务的效率和减少根因定位的时间。以上就是阿里云云产品可观测能力的核心升级。
三、云产品可观测客户最佳实践
接下来结合两个客户案例，即云产品可观测能力的建设的最佳实践。第一个是天财商龙，天财商龙是一家专为餐饮行业提供SARS化服务的厂商，业务系统的稳定性是非常重要的，因为可能会直接关系吃饭的体验,天财商龙团队对于业务的稳定性建设一直十分重视，希望通过可观测能力提升整体业务系统的稳定性。天财商农本身服务几千家餐饮企业，业务具有明显的潮系特点，因为吃饭的时间基本上都是固定的，为保证系统弹性，基于云原生进行的架构升级，随着升级完成也带来一些新的运维方面的挑战。
第一个挑战是整个技术站和架构比较复杂，之前的可观的数据都是分散进行接入和存储的，进行统一的难度比较大。第二个是随着微服的增加，整个系统的调量越来越复杂，进行问题排查也很困难。第三个基于成本的考虑，希望整体提升云上资源的利用率。基于和阿里云可观测的交流和沟通后，最终客户决定采用基于SLS做整个可观测的数据统一的存储底座，实现云上云下多个数据源的可观测数据的存储。
同时通过Prometheus提供的容器监控能力实现对于容器更细腻的资源使用率的监控，结合实时的监控数据和容器的弹性伸缩能力，能够实现精细化的容器资源的管理，提升整体容器资源的利用率。最后结合阿里云的统一告警能力，建立对线上故障快速分级响应体系，提升整体异常处理的效率。通过统一可观测能力的建设，现在任务人员不需要在原来多个监控系统之间来回进行频繁的切换，显著的提升整体的运维效率和准确性，通过可观测数据的关联分析能力，整体的故障排查时间降低30%，结合精细化的资源管理能力，整体运营成本也降低20%。
第二个客户是一家新零售的茶饮客户，这个客户是除了国内市场以外，也在积极的拓展海外的市场，海外采用的是另外云厂商的云服务，客户整体的业务处于一个比较快速的发展实践，随着业务的扩展，系统的复杂度，管理的资源的规模和本身业务的用户大幅的提升，整个可观测系统的稳定性都面临着比较大的挑战，客户希望通过建设可观测能力，保障用户端的体验的同时，能够提升整体业务的稳定性。经过与客户的交流以后,客户决定采用以阿里云的可观测产品落地，统一的可观测建设的方案，首先是基于阿里云的容器服务的ACK ONE的能力纳管的第三方云服厂商的容器服务，基于阿里云Prometheus实现多云集群的统一监控，这样可以避免运维在多个系统之间来回切换，同时也解决监控数据对齐的问题。另外结合日志调量和指标，围绕自己业务的稳定性，建设自上而下的稳定性大盘，通过SAO的统计实时掌握每个业务系统的可用性，围绕可用性的目标进行日常的系统性能的优化和巡检。最后通过针对不同的技术栈的告警指标规则配置，结合统一告警能力实现分级和分层的应急响应的机制,提升整体故障响应和处理的效率。
