大模型黑盒、P0 级事故，可观测性如何保住程序员的饭碗
责编|唐小引
很多时候，大模型并不是很听话，业务中的一些故障总是难以被看见，我们需要一双慧眼。
大模型的输入输出充满了不确定性，缺乏可解释性，存在“黑盒”问题。如何进一步观测大模型内部、减少大模型幻觉，对其工作原理进行白盒化处理？可观测性技术与AI大模型的紧密结合，就可一定程度解决这个问题。
在CSDN与Boolan联合主办的SDCon2024全球软件研发技术大会上，我们特设可观测性专题，邀请到来自阿里、小红书、基调听云、Tetrate的可观测性领域的技术专家，展开分享了对于可观测性技术的深入实践与经验。
LLM应用可观测系统的重要性毋庸置疑
“大语言模型缺乏可解释性，用户难以判断其回答的内容是否真实、来源是否可靠，模型的资源消耗也很有可能失控，我们需要密切地对它进行持续关注。”阿里云可观测性领域资深专家蔡健表示，这就是可观测性技术在LLM领域的用武之地。
蔡健在SDCon2024的现场，带来了《LLM应用可观测解决方案探索与实践》，分享了面向LLM应用技术栈的可观测能力解决方案。
在生成式AI创新浪潮下，国内大模型经历了百模大战、降价潮，国内大模型与国外差距越来越少，企业内部数据AI需求催生大模型私有化部署，AI应用生态日渐繁荣，同时催生出丰富的AI应用场景。其应用范式包括以ChatBot、Copilot、Agent为形态代表的对话应用、RAG应用、Agent应用。
在这一背景下，LLM应用可观测性技术的需求日益凸显。蔡健引用统计数据说明了虽然2023年是构建LLM应用程序原型的一年，但实际上投入生产的应用程序相对较少的事实——只有大约10%的公司将超过25%的LLM应用程序投入生产；超过75%的公司根本没有将任何LLM应用程序投入生产。
投入生产的比例较低，意味着从构建原型到生产面临着实际的挑战，这也是为什么LLM需要可观测性解决方案的原因。蔡健归纳出的原因包括大模型依赖的不确定性、LLMApp架构链路长、LLMAPP部署技术栈复杂。
“LLM是复杂的统计模型，容易出现不可预测的行为。如果没有适当的监控，它们可能会损害业务指标、合规性、品牌声誉和客户信任。”他表示。
“从架构角度，当需要可扩展性、弹性和解耦时，我们可以实现微服务架构。应用程序的不同组件被解耦并作为独立的服务运行，例如UI、提示工程系统、RAG系统、LLM调用等，每个服务都可以根据需求独立扩展。”他对比了微服务和AI应用架构：“微服务架构侧重于系统架构的灵活性与韧性建设，LLM应用则致力于模型效率与效果的极致追求。两者的可观测能力诉求从关注焦点、数据复杂度、技术挑战、评估指标上存在差异。”
其中，LLM应用可观测关注点在于性能体验下模型可用性、数据质量、资源效率及成本和领域特点。
基于这样的行业观察，蔡健介绍了阿里云LLM应用可观测方案： “以会话串联用户交互问答过程，以Trace承载应用全链路交互节点，通过定义领域化的操作语义，进行标准化存储以及可视化展示关键内容，给开发者提供问题排查的能力。”
他介绍道，阿里云ARMS可观测提供自研探针（JavaAgent、Python、GO、eBPF等），覆盖RUM、APM、链路追踪、容器监控以及基础设施监控等，全面拥抱OpenTelemetry、Prometheus、Grafana开源标准，为客户提供高可靠、高性能、功能丰富、开箱即用的端到端全栈可观测能力。针对LLM应用的可观测解决方案的实现思路，基于ARMS可观测平台基础能力，聚焦LLM领域洞察，通过高质量的采集加工LLM应用产生的Logs、Metrics、Trace以及Profiling数据进行加工以及提供可视化的分析能力，通过进一步挖掘加工、关联分析上述数据可以最大化释放数据价值。
当前LLM应用的主流开发语言为Python，阿里云推出自研PythonAgent以便更高质量的采集数据。相比开源实现，阿里云Python探针提供更丰富的指标、链路及持续剖析数据，灵活的采样策略，细粒度管控，支持动态配置，提供多种性能诊断和数据，通过全方位自监控提供高可用稳定性保障。同时面向大模型应用进行量身打造，支持最新OpenTelemetryLLMsemanticconvention，支持LLamaIndex/LangChain/通义千问/OpenAI等国内外框架和模型，实现埋点更加精细化，同时支持自定义属性透传能力，以满足多样化监测需求。
简单集成的场景可以单独使用AliyunPythonSDK仅仅上报调用链数据就可以享受到开箱即用的可观测大盘以及调用链分析和可视化能力。同时也支持集成了开源项目OpenInference、OpenllmetrySDK的LLM应用将数据上报并托管到阿里云可观测服务端。针对多语言以及框架埋点等暂时无法覆盖到的场景，可以基于OTSDK参照标准的LLMTrace语义实现自定义埋点并上报。阿里云更加推荐使用AliyunPythonAgent，基于自动化注入能力能够实现无侵入埋点，可以极大地降低LLM应用接入可观测的复杂性以及成本。
另外企业上云的一个痛点问题就是重度依赖云产品服务可用性，端到端链路追踪可以快速定位错慢请求异常节点，提升故障快恢效率，降低业务损失。可观测链路OpenTelemetry版与阿里云近10款云产品深度合作，完成了云产品内部链路插桩与数据上报。对于企业用户来说，只需在相应的云产品控制台一键启用链路追踪开关，就可以直接看到相应的调用链，简化了链路采集成本。这一方案，可针对LLM应用的UI端侧到网关到后端再到组件依赖，打通全链路追踪。
蔡健还分享了SLS-Text2SQL可观测案例，针对系统链路复杂排查问题慢、推理成本超出无法及时感知、RAG上下文查询扩展表现、多轮反馈推理工具调用可观测需求等业务痛点，提供了端到端的全链路追踪进行LLMTrace可视化诊断、基于token消耗阈值告警以及模型标签对比分析、对问答质量进行评估关联上报快速获知优化效果、Agent规划以及工具调用详细记录跟踪分析调优的解决方案。
在演讲的结尾，蔡健表示LLM应用可观测系统的重要性毋庸置疑，同时提出了四个方面对可观测性技术提出更高要求的挑战：
多模态：支持文本、图片、音频、视频等多模态应用全链路的可观测诉求；对于多元化数据存储以及可观测整体能力提出更高要求。
Agent进化：Agent协同、推理过程、记忆能力、连接集成等。
向量&语义化：结合向量语义检索以及语义分类能力，赋予可观测Trace更多内涵，方便快速理解、预警、分析排查定位问题，通过Trace回放对比输出效果提升调优效率。
安全合规：面临数据泄漏、客户隐私、提示词攻击、输出不合规等问题，可观测自身也需要在权限控制、按需脱敏存储、风险事件监控等方面持续投入。
可观测性要解决“未知的未知”问题
“我们发现，90%以上的AIOps项目其实是未达预期的，其中一个核心的原因就是数据质量未达要求所致，大模型对数据语料的要求非常高，而在AIOps项目中缺了一个非常重要的数据质量环节。”基调听云CTO杨金全表示。
今年以来，许多P0级事故发生。数字化业务复杂性急剧增加、IT稳定性受到严峻挑战的情况下，他认为，目前IT团队需要变革性的技术，打破数据孤岛，理清系统运行状态，实现更快的故障响应、更准的根因定位、更少的用户影响，确保系统稳定性，驱动数字化转型。
杨金全带来了《APM下一站：统一可观测性》的主题分享，他认为：“APM应用性能监控可帮助开发者和运维人员诊断和优化系统的瓶颈，提升用户体验，并确保服务的稳定性和高可用性。”
APM（ApplicationPerformanceMonitoring）是指应用性能监控，是一种系统级别的监控技术，用于实时检测并分析应用程序运行时的性能状况。目前行业内APM工具通常会提供可视化的仪表盘和详细的日志，使得问题排查变得更为直观和高效。“最重要的是，我们认为可观测性应该去为用户解决未知的未知问题。”杨金全强调。
他引用了一份来自全球市场的14,013名IT专业人员的调查结果显示，97%的IT从业者迫切需要由监控上升到可观测性，85%的受访者表示可观测性现在是其企业的战略重点。同时，行业内还存在厂商众多数据标准不统一；数据清洗工作量巨大，效果差；数据间关联性差；AI平台输入输出质量不稳定等问题。
对此，杨金全进一步阐释了可观测性解决方案。他将监控、APM与可观测性做了如下对比：
目前来说，建设可观测性平台有四种方法，包括APM+可观测性、以eBPF技术构建、以日志链路构建、以网络流量构建，其中APM+可观测性是业界公认效果最佳的方案，业界在APM构建过程中已经花了大概10年的时间。
杨金全进一步指出“以APM为核心是实现统一可观测性的最佳路径。”具体来说，APM下一站，是以Tracing为核心，全景串联业务、操作、请求、网络、中间件、进程、代码、数据库、日志和资源，构建统一可观测性。他解释道：“要效果好，必须要依赖于的Tracing技术，也就是APM的核心技术。Tracing可以作为一个中间件，来关联用户的操作及整个资源。”
统一可观测性落地方案上，杨金全介绍了基调听云大模型时代的统一可观测性平台全景。
随后他介绍了统一可观测性平台需要落地的几个要素，包括数据治理、拓扑能力等。而其公司产品听云超模态AI™ ，就包括了UniAgent™、数据湖仓、多维探索、DEM、轻应用平台。
杨金全展示了基调听云数据湖仓全景，分为采集、存储、计算、管理和应用层。
在存算分离上，采用三层池化的存算分离架构，包括算子Native、冷热数据自动分级处理；采用交互式OLAP：支持高性能分析，支持资源弹性伸缩。
构建了智能化数据生产线，包括全栈数据AI4Data，实现数据治理全流程智能化；一键实时数据湖集成，实现一站式任务管理，AutoETL自动作业，提升集成效率；智能运维，通过血缘分析，实现数据资产管理与数据安全。
在数智融合，其数据湖仓统一模型与元数据：打通数据和模型，支持数据+AI灵活编排；融合镜像：通过AI平台与大数据平台统一融合镜像，支持统一资源调度。
在数据多维探索上，杨金全介绍了其产品见微™，旨在发现维度之间的差异并做深入分析，并分享了其所在的基调听云超模态AI™之基于因果关系的确定性AI能力模型。
基于因果关系的确定性AI能力模型，以其开放的可观测能力、轻应用平台，提供低代码的可观测性。据介绍，该模型内置几十款经典和全新的可观测性分析轻应用，其低代码开发框架，提供快速开发和上线新的可观测能力，内置多种前端图表和组件，自定义查询能力，开放API支持直接编写NBQL探索需求，提供安全的认证和访问控制，数据加密传输，保障数据安全和隐私性。
当前行业中AIOps解决方案虽然提供了基于机器学习和相关性的能力，但缺乏足够的上下文和解释，仅仅停留在预测层面。随着时间的推移，业务环境和依赖关系的变化，这些结论很快就变得过时。
对此，基调听云通过独特融合UniAgent™、UniSession™（用户会话）、UniTopology™（全局拓扑）、Serviceflow™和OneTrace™，助力人工智能引擎听云AI™为用户的环境提供高度准确的确定性答案，应对最复杂的问题。这些答案具有即时性和可解释性，并在当今充满超动态依赖的环境中提供见解。
在基调听云确定性AI及大模型落地实践部分，杨金全进一步介绍了听云确定性AI™的功能实现，功能包括通过实时横纵向拓扑理解业务系统依赖和调用关系；实时监测疑似问题并自动分析，理解潜在问题；实时捕获全栈数据，从数据中心到终端应用；实时记录并分析用户旅途与分布式链路追踪；深入到代码级，持续深入洞察代码级性能问题；基于全景上下文，提供应用性能问题的确切原因，并可解释；可对业务影响定量分析，并基于业务优先级收敛、抑制告警；自适应业务变化，自动更新全局拓扑，自主分析性能变化。其大模型应用场景包括自然语言访问数据、自然语言数据总结、分布式链路疑似问题推理。
在企业落地场景上，杨金全介绍其大模型可进行全景可观测、自动根因分析、业务影响分析、客户投诉处理、服务治理，以及应用安全及实时业务洞察：
全景可观测：全局拓扑™通过数据全链接、场景深融合，实现服务治理、业务流程治理、变更影响分析和全局根因诊断。
自动根因分析：融合了预测式AI、确定性AI和生成式AI的听云AI™，实现全域数据异常检测、问题收敛和自动根因分析。
业务影响分析：通过对关键业务的优先级和影响程度进行评估，使IT运维能够精准对齐业务目标，实时聚焦并满足业务服务水平管理（SLA）。
客户投诉：以用户为中心，融合全域端到端可观测性数据的UniSession™，像素级还原用户现场，实时疑似问题诊断，快速应对客户投诉。
服务治理：通过ServiceFlow™实现调用依赖梳理，服务治理、问题诊断和定位瓶颈。
应用安全洞察：通过运行时漏洞感知，运行时风险识别，低成本、零摩擦、智能地实现DevSecOps，从而以更低的风险更快的业务创新。
实时业务洞察：通过实时的业务可视化和数据驱动的决策支持，确保企业能够快速调整策略，优化运营效率，提高客户满意度，并保持竞争优势。
机遇与挑战并行，小红书云原生可观测实践
小红书可观测负责人王亚普带来了《小红书云原生可观测演进与AIOps实践》的主题分享。他介绍道，小红书可观测团队成立于2022年，隶属于小红书基础技术部，提供一站式可观测平台，包括监控、分析、查询、告警等基础能力，覆盖小红书所有可观测数据，包括Metrics/Logging/Tracing/Profiling四大支柱，服务于公司稳定性建设，提升故障发现、响应、定位效率。
王亚普老师分享了自己看到的小红书内部推动可观测性技术的痛点和挑战，包括监控工具分散且碎片化、使用成本高；数据规模大，系统稳定性差且性能瓶颈严重；缺少使用规范约束，用户大多照葫芦画瓢；存在技术负债，用户使用习惯难改变，造成技术架构演进难度增加。
机会与挑战并行。在优势与机会上，小红书具备以下几点优势，包括云原生接受和使用程度高、开展云原生可观测建设工作满足业界技术发展趋势的需求、PaaS垂直领域监控覆盖度高并已具备一定的优势基础，以及有机会实现一站式可观测平台目标，包括系统端、服务端、用户端。
针对小红书现状问题，王亚普老师详细介绍了小红书可观测技术架构的演进思路：
All-in-one统一可观测平台用户心智，集成公司内部更多生态
避免造轮子：完成现有监控技术体系的深度整合和架构升级
稳定性：建设标准化、高可用、可伸缩、易运维的可观测技术底座
结合故障处理机制流程，提高问题发现、定位、解决的效率
在Metrics数据规模上，小红书内的时间序列近两年增长200%，最大时间序列基数超过2000万，给数据查询带来极大的难度。历史Prometheus架构，属于单副本，存在诸如稳定性差，存储不定期出现宕机、雪崩等故障等问题，其部署分散，黑屏且管理成本高，且资源成本高、使用体验差。
为此，小红书可观测团队构建了Metrics高可用主备架构，能够做到双采双写，并且每个集群副本的数据只有一份。在故障容忍层面，单节点故障不影响整体稳定性；同时采用VMS全家桶全面替换Prometheus，资源占用可节约70%以上，同时推动下线Thanos，做到资源节省；通过集中式采集管理、配置动态下发，降低运维成本；在弹性可伸缩上做到了服务注册/发现能力，几分钟内能够完成无损扩缩容；通过技术优化解决高密度数据查询性能问题。
在Metrics写入与查询高可用上，做到了主备双活，即双采双写，同一时间窗口相同指标存储去重；负载均衡：禁用reroute机制，按实例名Hash将相同时间序列写入同一个存储节点，同时引入本地持久化队列应对存储节点故障情况；容灾切换：数据积压情况上报metaservice，超过积压阈值自动切换集群副本。
为了提高Metrics查询性能和容量，实现计算下推能力。将sum、avg、max、min、count等聚合操作下推至存储节点执行，只返回聚合后的数据，可以大幅度减少查询节点获取的数据量。avg是比较特殊的聚合函数，例如avg(rate(http_request{code=200}[1m])) ，需要将计算下推过程拆分为avg=sum/count，在存储节点提前完成avg聚合操作会造成计算结果不准确。整体方案落地后有效地解决了查询性能和稳定性问题，在聚合查询场景性能提升10倍以上。
在Metrics高基数管理上，通过接入轻量级、可插拔组件，实现了低开销的高基数检测、乱码识别以及用户差异化阈值管理。
在MetricsSDK增强上，引入缓存机制避免用户每次获取Meter的性能开销、针对低频时间序列加入过期清理机制节省采集资源；支持全链路压测、业务指标类型拆分（工程+算法），实现指标隔离功能；通过禁用异常指标，实现应急止损；通过Metric元数据管理，在产品层做到精细化指标管理，实现产品提效。
Tracing环节，包括方案选型、协议设计、拓扑分析与指标计算、聚合分析、流量放大预估几个方面。
在方案选型上，小红书可观测团队全盘考虑了业务接受度、研发成本与上线周期、接入成本、稳定性因素，认为字节码增强开发成本高，对业务是个黑盒，SDK接入业务更容易接受，且SDK发版上线已经在内部有成熟的规范，得出了这样的结论：CAT当前覆盖率和稳定性要好于其他未知的开源方案，如果可以在CAT基础上升级分布式链路，是接入和推广覆盖成本最低的一种方式。
Tracing-拓扑分析与指标计算上，小红书可观测采用近实时流式计算拓扑骨架，并使用Clickhouse进行存储：CK存储拓扑节点的边关系，起始节点作为主键索引；使用SummaryMergeTree表引擎，用于聚合相同的边。
Tracing-聚合分析上，通过对一批样本数据进行聚合分析，可以得出一份慢响应分析报告，主要提供了几种类型的问题检测：慢请求、端到端耗时、重复调用、RPC未触达服务端，更直观地将问题呈现给用户。
Tracing-流量放大预估上，往往面临关系复杂、流量入口难以梳理的问题。王亚普介绍，小红书可观测团队以流量入口为基准设定预估QPS，可以根据一段时间内Trace的真实流量给出所有下游RPC调用次数相对于流量入口的放大倍率，用于大促时容量预估非常有帮助。
关于日志成本与性能，王亚普分析了其现状与痛点，包括：
成本费用：ELK成本已经高达几百万/月；
资源开销大：因为资源受限，ES高峰期大量日志已经出现常态化写入延迟；
存储周期短：压缩率低、索引膨胀，日志一般只存3天左右；
日志丢失严重：业务使用不规范造成filebeat面对大数据量存在性能瓶颈，无差别限流日志问题严重。
他分享了日志整体架构，图示如下：
Logging存储设计上，小红书可观测团队按业务分区、不同产品线TTL差异化管理，采用云盘SSD+本地盘HDD实现冷热存储，采用分布式表汇聚多个集群日志数据。
日志索引设计，通过主键结构+二级索引，实现检索优化，针对日志内容字段使用了tokenbf_v1索引，对于大日志内容进行分段存储，仅前8K进行索引。在日志分析上，提供提供类SQL的查询分析能力。
在Logging部分，小红书可观测团队还做了日志聚类功能，解决看清日志分布、日志治理等业务问题。在这里，王亚普老师还分享了团队参考的《Drain：一种具有固定深度树的在线日志解析方法》。
论文链接：https://jiemingzhu.github.io/pub/pjhe_icws2017.pdf
在Profiling上，王亚普表示小红书内部对性能防退化比较关注，其可观测团队目标是实现持续Profiling，整体架构具备运维成本低、采集频率可控、熔断策略、支持多语言协议、可灰度的优势。
Profiling针对性能退化问题，可通过对比函数开销历史对比趋势图、性能退化火焰图的分析报告，实现性能退化巡检。Profiling在小红书的应用场景包括：中间件、可观测、大数据、存储、实验平台、GC等基础组件；业务TopK函数CPU核数消耗；正则、String.format、压缩、序列化的通用性能优化；Thread.sleep、业务框架已知的错误用法的bad-case经验库。
除了以上四大支柱外，王亚普老师还分享了其eBPF在流量分析上的用途，如异常流量识别、老服务下线、共享存储集群成本分摊等；以及正在进行的eBPF更多探索，包括具备业务语义的流量分析、跨云带宽可观测、低开销的多言语Profiling。
故障处理提效与AIOps实践部分，王亚普老师分享了故障根因定位技术实现，以及SLO稳定性数字化驱动的建设思路和当前进展。
王亚普表示，单纯使用故障驱动不能代表稳定性真的做得好，SLO是一个更加客观的稳定性度量方式，可以给到用户一个可量化的表现预期。围绕SLO数字化运营的目标来建设整个SLO体系，目前SLO已在上层覆盖了小红书所有的核心业务场景、基础组件和业务中台等。
“在未来的规划上，我们还任重而道远。”王亚普表示，他在演讲的结尾对于其可观测性工作提出了五点未来计划：
一体化、标准化、差异化：平台心智、接入规范、更多公司生态；
更高性能、更长周期的数据存储：全局降采样、冷热存储等；
聚焦业务视角和故障洞察，挖掘AIOps中更多数据关联分析能力，并建设更多业务视角的排障工具；
技术先进性探索：持续挖掘eBPF的落地场景、大模型应用可观测性领域的探索；
稳定性体系：建设面向故障处理、运营的可观测体系，SLO将作为重点建设的一环，辅助稳定性运营和故障定位提效。
BanyanDB开源数据库，实现可观测性数据存储优化
“当然现阶段可观测领域一般来讲会有六大柱石，除了传统意义上的Metrics、Logging、Tracing，还包括Events、Profile，和Exception，但最核心的就是这三类的数据。它们在数据信息密度上、存储量上有明显的不同。”Tetrate创始工程师高洪涛带来了《基于BanyanDB的可观测性最佳实践》技术分享开场，先给大家普及了可观测领域的相关知识，包括观测性数据和实际数据。
他介绍道：“从上到下可以看到Metrics 的数据量是很少的，无论是用Prometheus还是用别的平台去采集，基本都是有一个时间间隔，大概是5秒到15秒去抓取一次，它是一些离散的点，有固定的采集频率，数据量非常小，紧接着在Tracing和Logging的数据量会越来越大。”
他还解释Tracing被放在中间位置的原因：“这涉及了一个比较古早的概念，Tracing当开始出现的时候是有采样的，Tracing不会100%开，会有一定采样频率，1%、1‰才会采一次Tracing这也是为什么在这张图里位于中间的原因。如果你用100%的采样的话，那么Tracing的数据量还是非常巨大的。”
Logging是数据量最大的，被放在了最下面。“除了量巨大以外，Logging格式也有较强的任意性，这个是无法避免的。即使去规范其格式，但最终呈现出来的有价值信息也不是格式化的。因此需要建设数据搜集，钻取和分析平台将这些数据格式化为有价值的信息。故此，Logging数据的处理难度非常大。”
而时序数据就是一些随着时间变化的数据值，包括时间序列（TimeSeries）、键值对（Key-Value）两个核心概念。时间序列由一个名称（通常称为指标，MetricName）和一系列Key=Value标签(Label或Tag）组成，比如7天内的天气预报就属于时间序列。
附加在时间序列上还有键值对，这提供给我们这个数据额外的一些信息作为补充。键值对按照时间戳自然排序，每一个数据点一般称为采样（Sample）。高洪涛表示，观测性数据与实际数据有个天然的连接点，就是时间。
他介绍道：时间序列最早从这种监控领域、观测性领域产生的。2013年以来，时序数据库（TimeSeriesDB）成为数据库行业除了图数据库之外最受关注的数据库类型。时序数据的需求也在随着汽车、能源、IoT、金融等行业的飞速发展而持续上升。与时序数据相关产业的市场规模达5000多亿元，并逐年上升。“目前国内做这种实训类数据库的创业公司起码有5家，在不同行业围绕着时序，比如观测类、分析类行业等。”
在上图所示的两种存储方式中，上方是一个经典的时序数据和观测数据的结合存储方式，下方展示了一种更为简洁的存储方式。“我们会倾向于同样序列的Tracing数据存储在一起。”那么SkyWalking的存储结构是什么样子的？
首先高洪涛介绍了SkyWalking目前支持的数据存储类型，由最早的Traces，到覆盖了前面提到的可观测性数据的六大柱石，包括Traces、Logs、Events、Error/Execption、Profiles、Metrics。
SkyWalking产生的数据符合Rum假说。这是数据库设计领域的重要假说，由读性能、更新性能、内存性能优化的三个点构成。其原理是，如果优化其两个方向，那第三个方向上必然会出现负面影响。“目前市面上大部分的数据库都会采用读优化，”高洪涛分享了Database的词源来自古希腊记录谷仓信息的石板，并表示“目前大部分数据库都对读的性能要求比较高，从而在另两个方向上做一些取舍。”
他分享了这样的一个观点：“但我们有一个反直觉，对于观测性数据来讲，读的重要性并没有那么高。观测性的数据库设计，我们大胆抛弃了传统方式，把重点放在了内存和写入。这是SkyWalking的明显特点也是BanyanDB设计的方向。”对此，他解释道Metrics数据只做小规模热数据查询，同样Tracing和Logging数据在系统不出问题的情况下也不需经常查询。
随后，高洪涛介绍了BanyanDB，即为ApacheSkyWalking构建的开源、高性能、可扩展的时间序列数据库。BanyanDB已经发布了六个版本，在2023年的V0.3.0中集成了WebUI、在V0.5.0加入了集群功能，在其今年发布的V0.6.0把之前的KV内核换成了列式。
高洪涛分享了其数据模型的模式图如下，包括存储节点、分片、段、块几个部分。在存储节点中，他表示目前采用并行的处理模式。
其分布式模式如下图。其中，Liaison状态节点作为路由入口节点，会独立地计算出数据的拓扑情况，数据会被分散到特定的写入节点上。其写入模式与查询模式存在非常大的区别，在写入阶段数据会被写入特定的分片，在查询时，查询执行器会访问所有节点，而不会去访问数据分片信息。这样的设计可以防止数据节点的故障时系统不可用。这也是BanyanDB数据库与其他数据库相比的独特之处。所以BanyanDB是一个面向高可用的数据库。
他表示，其团队目前正在开发中的热数据、温数据和冷数据架构，会采用不同的介质，不同平衡策略来降低数据存储成本。
在数据的有效存储上，分成时间序列后，在同一序列内部存在高度相似性。对高度相似的数据做压缩，会得到一个比较高的压缩率，从而提高数据的存储效率。高洪涛表示，经测算，对Metrics的效率可达95%以上，Logging数据也能达到80%。
对于高基数问题的解决和优化，BanyanDB对于Metrics、Logging、Tracing数据的存储，会选定Tags作为序列标志，可在schema阶段进行一个特定选择，而不会选择所有的Tags来做序列，从而有效地降低这部分存储。
在介绍BanyanDB测试设置时，高洪涛建议数据存储上鼓励大家使用云盘，而不是用数据复制，因为应用级的数据复制代价远远大于云供应商提供的云盘的可靠性的代价。在测试时，他表示给Elastic测试的内存会多一点，ES很耗内存；给 BanyanDB的CPU会多。在磁盘的使用方面，他介绍了其数据库具备的优势在于其整体对磁盘的吞吐量需求较小，对磁盘占用可减少1/3，并且对磁盘的写入保护较好的。
最后，高洪涛呼吁更多人参与到BanyanDB和SkyWalking的开源项目贡献，包括参与试用、加入社区，并给予反馈，并把产品介绍给更多的开发者。
阿里云Prometheus分布式采集探针，突破开源版本采存一体
阿里云基础事业部可观测研发专家隋吉智带来了《阿里云Prometheus分布式采集探针在ASI超大规模集群场景实践》的技术分享。
隋吉智介绍道，开源PrometheusServer模式采用的一体化采集与存储模式，带来了部署便捷的好处，同时也存在数据单点存储不好聚合、采集与查询性能有限的问题。相比之下，这两年很火的开源VictoriaMetrics模式，采集与存储分离模式，使得数据聚合灵活性提升、采集和查询性能较高，但在多副本和自适应集群采集的时候，也存在劣势。
阿里云Prometheus采用采集与存储分离模式，使得数据聚合灵活性提升、采集和查询性能较高、数据处理链路高可用。
阿里云Prometheus分布式采集架构设计部分，他先介绍了其开源PrometheusAgentMode模式。这个模式禁止本地的查询、告警、存储，原理为TSDBWAL+RemoteWrite，本质上仍就为通过RemoteWrite远程投递数据，并不具备多副本采集能力。
针对上述问题，隋吉智介绍了阿里云Prometheus分布式采集探针的两代设计。
阿里云Prometheus分布式采集探针第一代设计，将控制面与数据面融合在一起，控制面可承担一定数据采集任务，在小规模集群中一个副本即可实现服务发现和数据采集，从而节省资源开销。
在阿里云Prometheus分布式采集探针第二代的设计，进一步优化，控制面与数据面拆分，即控制面仅做服务发现，数据面承担全部的数据采集任务。
“在面对大规模集群的时候，往往一个Master是完全不够用的，那我们就把Master单独拆出来，只需要做服务发现和预抓取。其好处是仅有一个Master跟K8SAPI做交互，对Master的访问的压力就会下降，就没有从Master到Worker角色的一个切换。”隋吉智在解释迭代思路时表示，“第二代开始那就没有这个情况了，Master就只是做服务发现和预抓取，然后和Targets的分配，然后计算需要多少个采集副本，采副本做横向的扩缩容即可，可以减少了故障率并提升稳定性。”
在阿里云Prometheus分布式采集探针第二代部署上，Master与Worker拆分为两个Deployment部署模式以及scrape_configs&Targets订阅模式，HPA采集扩容机制。其核心模块由原先的Prometheus核心模块改为基于Opentelemetryoperator+TargetAllocator。
在功能模块中，Master中都包含服务发现的模块和预抓取模块。具体来说，服务发现模块与采集模块的拆分，预抓取机制评估采集副本数量，Targets调度机制实现采集负载均衡，HPA机制实现采集副本扩容。
第二代的探针设计，基于pentelemetryOperator+TargetAllocator实现scrape_configs和Targets订阅，依托K8S滚动机制实现无损升级能力。
此外，阿里云Prometheus自研Master-Slave调度，可实现自适应采集负载波动。具体来讲，Master加载采集配置，进行服务发现，预抓取后依据Targets和Series计算所需采集副本数，依据阈值切片和调度Targets。Worker启动后向Master注册并获取唯一ID身份标识，通过TA向Master获取采集配置，再依据采集配置按照Job颗粒度组装URL向Master获取分配的Targets，最后启动Targets采集。Master中的Rebalance模块依据Worker资源消耗和采集负载的同步结果，进行动态Targets调度，调度时会计算下次采集时间间隔，做到不掉点动态负载均衡。
同时，阿里云Prometheus自研HPA实现采集副本扩容，具体过程如下：Master与Worker间通过SyncResource模块进行资源消耗（Cpu&Memory）同步，实时获取Worker资源消耗，达到70%时触发Rebalance模块进行负载均衡调度；Master与Worker间通过SyncSeries模块同步Worker实时采集量级，当有单Target出现时间线发散或波动时，超过Worker预定采集负载后，触发Rebalance模块进行负载均衡调度；Master中的HPA模块，依据SyncResource和SyncSeries同步的结果，经过计算后进行扩容，通过设定ReplicaSet来改变采集副本数。
总结来说，阿里云Prometheus采用采存拆分架构，打造了轻量化采集探针，可在K8S集群做安装。
其轻量化的Agent支持分布式的采集，配合其自研的HPA和VPA的能力，可支持超大规模集群，其负载在上下波动时可自适应，自适应后可以做横向和纵向的扩容，不会出现在集群指标突然发散时形成探针故障。从后端可观测上发现数据有发散，可以做告警再去处理，从而保证监控数据的连续。
阿里云Prometheus在存储上采用高可用存储链路设计，支持远端指标投递，可构建统一的存储体系和告警体系。隋吉智表示：“我们是把存储和采集拆分之后，把存储上的链路又增加了Kafka缓存，让你的数据即使规模很大也不会延迟很久。然后在查询阶段做优化，让查询变快、变稳定，使得可观测大盘和告警会更高效。”
阿里云ASI超大规模集群采集量级和部署上，初始化部署单副本，即Master，采集方式有全局服务发现Kubernetes-pods、ServiceMonitor、PodMonitor三种方式。他表示，三种类型采集配置，服务发现范围均为全集群，使用建议上其实是最不推荐的方式，但是测试性能时可以这么使用。
阿里云ASI超大规模集群采集配置合并上，Master中进行采集配置的合并和服务发现，并根据自定义的采集开关启停Job，Worker中过滤废弃指标。
他解释了把废弃指标从Metricsrelabel中提取出来的原因：“我们在实际过程中发现，在Metricsrelabel做指标废弃的时候，是非常消耗性能的，会让性能变得很差很差。如果用户配了一些很多的正则，那做匹配的时候性能就下降得非常明显。”
最后，隋吉智总结了阿里云Prometheus第二代探针在ASI超大规模集群场景落地实践的效果：
在ASI超大规模集群场景约10wPods时，服务发现产生约4.5wTargets，单轮采集约7000万时间线，分布式采集探针2c2gLimit资源下实测所需约23个采集副本，实际资源开销约50%。
在ASI超大规模集群场景Pods从10w至30w波动变化时，服务发现产生Targets由4.5wTargets至12wTargets，探针自适应波动并进行HPA扩容，分布式采集探针2c2gLimit资源下实测所需约50个采集副本，实际资源开销约50%。
单Master服务发现设计，有效降低对集群内APIServer的压力，同时增加APIServerList动作频率限制，一定程度上保证不会因Master故障导致APIServer压力骤增。
可观测性技术，正在将黑盒问题白盒化。数据存储、LLM应用、对外客户服务提供、企业内部故障排查、由开源版本进一步提升的产品迭代能力等，大厂们在可观测性技术领域上各显神通，为开发者提供技术觉察的慧眼。
大模型刷新一切，让我们有着诸多的迷茫，AI这股热潮究竟会推着我们走向何方？面对时不时一夜变天，焦虑感油然而生，开发者怎么能够更快、更系统地拥抱大模型？《新程序员007》以「大模型时代，开发者的成长指南」为核心，希望拨开层层迷雾，让开发者定下心地看到及拥抱未来。
读过本书的开发者这样感慨道：“让我惊喜的是，中国还有这种高质量、贴近开发者的杂志，我感到非常激动。最吸引我的是里面有很多人对AI的看法和经验和一些采访的内容，这些内容既真实又有价值。”