为什么云原生可观测性非常重要?

云杉 世纪

2023年3月3日

产品资讯

云原生可观测性 对于云原生软件系统以及软件工程领域都是一个比较新的概念。为什么在传统的单体软件系统中这个概念没有引起大家的注意呢?这主要是由于系统规模、复杂性以及生态化等多个方面的差异造成的。

首先,传统的单体软件系统规模和复杂度没那么高,开发人员可以通过IDE一次性加载全部或部分代码,并使用断点设置、单步调试等方法定位缺陷的根因和位置。云原生软件系统包含大量分布式的服务,难以一次性加载并进行调试,而且大量的服务间跨进程调用也使得单步调试无法进行。

其次,传统的单体软件系统运行环境的复杂性和不确定性没那么高,故障或问题一般都与代码自身或数据相关,较容易在开发环境下重现问题并进行调试。云原生软件系统往往涉及复杂的大规模分布式运行环境而且其中的服务实例可以动态创建和
销毁,因此运行时故障或问题可能与非常复杂的环境因素相关,难以在开发环境中重现。

再次,传统的单体软件系统运行时监控和观测手段较为单一,依赖于代码插桩的动态分析手段开销较大因此在生产环境中使用较少,与此同时软件的模块和组件结构不清晰、隐式交互难以捕捉等问题也限制了可观测性手段的作用。云原生可观测性
软件系统中各个服务实现了物理隔离,服务间通过跨进程通信进行交互,因此服务间边界清晰、服务间交互以一种显式和外化的方式实现。此外,云原生软件系统持续在线运行,同时有着完善的基础设施支持,因此较容易实现分布式链路追踪、指
标和日志监控体系等云原生可观测性手段。

最后,传统的单体软件系统可以以一种自顶向下的方式掌握整体体系结构设计并通过静态分析和演化分析实现架构看护,从而确保软件实现与高层架构设计保持一致。作为一种复杂的生态系统,云原生软件系统的持续演化难以通过一种自顶向下的方式进行掌控,各个局部的应用及相关服务以一种相对独立和自主的方式演化。例如,一些大规模微服务系统中出现长达四五百跳的服务调用链路以及依赖环路,这并不是因为开发人员技术能力和经验不足,而是由于“只见树木、不见森林”的局
部视野带来的问题。此外,各个服务独立开发、部署和运行,因此传统的静态分析和演化分析手段无法有效捕捉到服务之间的依赖和交互关系。

工业界对于云原生可观测性数据的分析和利用能力在不断提高。四年多前,我们针对工业界微服务系统故障分析与调试开展经验研究时发现[3]大部分企业的分析手段还如下图所示那样,停留在基于命令行工具的日志分析、日志事件统计等基本分析层面上,少数企业开始使用Zipkin等工具进行链路轨迹的可视化分析。

当前,很多企业都在深入探索云原生可观测性数据分析方法,其中的一个基本出发点是如何更好地融合指标、日志和链路轨迹三类不同的数据。例如,可以通过在日志中注入Trace ID将链路轨迹与日志关联起来。在分析方法方面,比较常见的一种做法是开发一个融合数据分析平台,通过不同类型数据之间的时空关联以及各种可视化分析手段进行故障分析和根因定位

Related Posts

金融银行业可观测性方案

金融信创是金融机构重点投入以及技术迭代的方向,经过多年阶段迭代,进入难度更大的核心系统、关键业务系统的更替阶段。DeepFlow解决行业中普遍存在的分布式交易系统保障难、平台双轨多芯调优难、云上资源把控难、分布式数据库追踪难等挑战。

Read More

根因分析假 running 真故障 记一次电力行业的 SRE 实践

用户:某省级电网企业 挑战 定界困难:当发生故障,业务部门和网络部门互相推诿,而不是解决问题; 监控颗粒度不足:运维难以深入到POD维度,大量微服务的业务交互在虚拟机内已经完成业务交互; 全栈链路追踪难:电网要求运维能力覆盖整个业务链条,在微服务架构下,难以看到完整跨容器节点的全链条追踪数据; 定位方法单一:大部分运维工具功能单一,比如日志只可以查询日志,没办法进行指标,追踪、日志等联动定位。 用户期望 期望1分钟发现问题、15分钟研判问题、1小时内解决问题; 监控体系完成业务全覆盖、系统全覆盖; 全业务链条可追踪、可溯源。 这里交代了背景 经济发展,电力先行。作为国家电网旗下最年轻的某省级电网企业,链接东北和华北电网,承担着京津冀北区域电力供应的重要使命。于2012年2月9日正式成立,2017年实施了全业务数据中心的建设,并陆续完成四大数据中心的建设,实现了统一的数据共享与业务融合。 随着信息技术在电力行业经营管理中的广泛应用,越来越多的业务系统从传统的物理环境迁移上云,导致诸多电力业务系统如:营销系统、BPM、PMS2.0、各类6000系统,成分布式微服务化部署,系统环境也多为异构场景,混合云和云上云下的场景尤为凸显。网络分层导致电力行业的业务系统很难用传统的运维手段探测到全局的网络,网络故障发生时很难快速做到端到端的定位等等。 事件起因从这里开始 我(作为现场支撑人员也是小编本身)和电网企业的故事要从一次联合故障定位开始,在往常巡检的过程发现其中一个业务系统,内部微服务(POD)间有大量的建连失败,在 DeepFlow 中输入更多关于建连失败的指标量,如建连客户端 SYN 结束、建连服务端 SYN 结束、建连服务端直接重置等,下钻到流日志后发现了主要建连失败的原因:即客户端 SYN 结束表现形式为客户端多次尝试建连,但是服务端无回应,于是服务端口未放行或者服务端口失效。 为了验证是否下沉到业务侧,与南瑞 I6000 运维同事进行联合定位,在交流过程中用户并没有发现有任何问题,用户随即手动输入 POD 健康检查的命令发现没有响应,与我判断一致,表面上看所有业务都在正常 running,但是 POD 实际没有启动好,监控端口已经失联。为了缓解尴尬的场景用户调侃道“假 running,真故障”。 接着与用户进一步讨论时,发现使用的是 Livceness,可以制定检测规则,如果检测失败就会重启 POD ,全部是以 K8s 被动触发,手动检测会变的很复杂,甚至会出现一种假活现象。根据这次联合定位,我和用户运维部门做了一次深入的沟通,同时也从内心深刻的体会到:一个运维人员面对微服务场景下缺失可观测性能力的无力感。 首先 K8s 的产生是面向业务的,最大限度的保证服务的高可用,但是很多流量都是瞬发的,微服务(POD)在不停的自动化运转,根据工作负载,随时可能发生业务 POD 剔除或者重建的情况,导致微服务场景的监控变得非常复杂。 还有就是以目前的运维手段用户更在乎业务的可读性,也就是电力行业常说的小绿泡,绿色代表正常,红色代表异常,但这远远不能达到实际的运维要求。在和用户深入沟通的同时,我也根据产品能力,建立较为完善的应对措施,帮助用户提升整体运维能力。 首先需要站在用户实际的业务角度出发,完成个性化的运维场景定制。 通过 DeepFlow 丰富的监控指标,可以全面覆盖网络和应用层的R(吞吐)E(异常)D(时延)的场景况,结合目前较为先进的 SRE 方法论,优化故障发现到故障解决的时间,使得整体业务水平在一个良好的 slo(服务等级目标);并针对重要业务中发现过的故障进行重点监控和故障场景复现进行针对性优化,改变过去发现业务问题再做问题定位的被动情景,转变为主动检测、主动监控、主动告警的监控闭环。 接下来为了解用户实际的业务场景和容忍度,和运维部门针对运维指标开设了讨论会,建立丰富、贴合用户使用要求和习惯的 SLI 指标和基线,通过主动监测和建立健康度管理模型的方式,帮助用户发现潜在故障。并且当发现了某些指标不合格,快速进行告警推送到指定责任人手里,再联合 DeepFlow […]

Read More