服务调用链的主要因素有哪些?

云杉 世纪

2023年3月10日

产品资讯

服务调用链主要因素如下

1、数据收集部分

主要用于多样化的数据收集,为数据分析做准备。要求易用好用侵入尽量小(开发工作量),并且在极端情况下(如收集组件不可用)不能对业务有任何影响。可以看到此部分的开发量是巨大的,尤其是需要集成Nginx上下游、基础组件多样、技术栈多样的情况下。

2、数据分析部分

主要有实时分析与线下分析。一般,实时分析的价值更大一些,主要产出如秒级别的调用量、平均响应时间、TP值等。另外,服务调用链(Trace)需要存储全量数据,一些高并发大埋点的请求,会有性能问题。

3、监控报警

此部分利用数据分析的产出,通过短信邮件等形式,通知订阅人关注。监控报警平台应尽量向devops平台靠拢,包括自主化服务平台。

4、实现方式分析

服务调用链根据收集方式可分为日志收集方式和程序实现方式

5、日志收集方式

日志收集方式与传统的ELK链路差不多。主要通过日志组件,打印出符合规范的日志格式。Flume守护进程会读取、过滤这些日志,将数据Sink到kafka集群中。会接收一份全量数据(服务调用链需要)到ES中供查询分析;同时接收一份日志使用Spark或Strom方式分析出需要的数据,存结果。

主要开发量集中在日志组件和各个模块的组合调试中。另外,由于需要在每台宿主机上安装配置flume-agent,此模式依赖完善的运维体系,可使用jenkens或者ansible集成支持。

6、手动埋点方式

服务调用链的这种方式采用业务端直推的方法,将数据直接汇集到kafka中。客户端一般会开一个堆上的缓冲区,将有单独的线程定时上报缓冲区数据。数据落地到kafka后,后续的处理类似。

为了支持易用性,需要较多的开发工作和可用性设计不会因为Trace组件或者Kafka的不可用造成服务的不可用。此种方式的主要坏处是,功能是以jar包方式提供的,如有重大bug或者改动,所有服务都必须重新发布。

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