导读 01用户:G行、金融行业 02用户挑战:1)云网故障定位技术要求高:在云网中对每一个微小故障的定位均需要对SDN、云技术架构、容器技术架构等技术领域经验丰富的中高级工程师参与。2)云网故障定位过程繁琐:云网工程师在故障定位过程中需要从源端开始抓包、查找路由表,再到下一跳节点抓包、查找路由……3)云网故障定位工作量大:每一个微小故障的定位均需要海量的Pcap包读包分析,给运维团队带来大量的工作量。 03用户期望:1)实现在云网内任意访问的全链路追踪,消除运维工程师的逐段查找路由表、逐段抓包的工作;2)对云网流量实现全面的L3-L7层性能指标分析,能够代替人工对绝大部分的故障场景的流量性能指标进行自动化分析。 03实现价值:1)消除人工的路由追踪工作,消除人工的Pcap读包工作;2)将云原生应用故障的定界周期由数小时缩短到1分钟以内;3)将云原生基础设施的定位周期缩短到5分钟以内。 近几年,在金融同业谋求差异化、互联网平台跨界竞争的格局下,G行积极拥抱趋势并直面挑战,在数字化转型战略中一直稳步推进,是国内金融行业内数字化步伐较领先的一家企业。在2019年建设了全栈云平台,并成立了专门的云技术团队负责全栈云的选型、建设、运维。在智能运维的建设中,G行更注重于平台能力建设和科技运营数据的全面、实时和准确的治理,实现对数据中心运行情况的可观测性与运维管理的辅助决策。 01运维的日常 G行的全栈云方案选型和建设中,使用了SR-IOV、智能网卡 VxLAN Offloading、DVR 分布式路由等诸多新技术,同时使得云网络、容器网络异常复杂,但目前云管平台缺乏可观测性手段,云运维团队面临着巨大的运维压力。 这些压力体现在了日常的工作中,例如遇到云网络问题时,需要精通SDN网络的运维人员逐段查询路由,逐段抓包,逐段定位丢包、业务失败等问题,这样操作复杂,且问题定位周期长,难以发现隐性问题。 某日 zdns-business 系统在生产测试环境部署上线后,在业务同步时频繁出现响应慢、业务连接中断等问题,而且中断无规律。 运维人员立即对业务系统抓包进行分析,遇到了2个难点,一是数据包数量太大,1分钟内即抓取了5372条数据包,读包分析工作量巨大,短时间内无法快速找到故障包;二是读包分析需要懂网络协议的中级以上工程师处理,技术要求高。 业务开发、业务运维、网络运维等多位工程师进行了联合定位和读包分析,经过了6小时奋战,还是未能确定故障原因。 02云原生可观测性能做什么? “业务响应慢、不规律中断”等问题表面看起来简单,实际上能够产生此类故障的背后原因却复杂多样,业务访问链条上的每一个物理交换机、OVS、虚拟网桥、操作系统、容器、应用等等均是潜在的怀疑对象,故障定位需要逐跳、逐段、逐次会话从不同维度进行分析,逐个排除。总体上可以梳理出以下三个大类、七个可能原因: 网络丢包问题——网络中如果存在严重丢包,将导致数据包反复的重传,影响应用交互速度,在严重情况下甚至可能造成应用交互的完全中断; 时延类问题——这里所说的时延问题也分为网络传输时延高、操作系统响应慢、应用软件响应慢三种不同的原因,其中每一种原因都可能让应用交互速度慢,甚至业务使用人员感知到中断; 异常类问题——TCP 连接建立过程、TCP数据传输过程中的异常中断、应用协议的响应异常也有可能造成业务使用人员感知到的慢和中断; 不规律中断问题的故障定位,首先需要在数千个数据包、数百个会话中精确锁定故障会话,这已经是一个非常具有挑战的工作了,更不用说对每一个会话的丢包分析、各类时延分析、各类异常行为分析,更是一个非常纷繁庞杂的事情。因此不难看出,此类问题通过人工的读包、解读、分析,需要故障定位人员具备丰富的问题定位经验,还需要投入大量的运维人力,也无法在分钟级定位问题解决问题。 DeepFlow 可观测性平台的云虚拟网络的流量指标可视化分析能力,可以完全将故障定位人员从操作复杂的逐段查找路由、逐段抓包,和枯燥无趣的海量读包中解脱出来,通过自动化的虚拟网络流量性能指标采集、自动化的流量可视化分析,运维人员可以一键绘制业务访问的全局拓扑,可以分钟内观测流量各个层次(网络层、传输层、应用层)的丰富指标(吞吐、异常、时延) 针对此类问题的三个大类、七个可能原因,G行运维人员通过 DeepFlow 在1分钟内快速勾选、调阅观测了全路径的7个指标的变化曲线,并有如下发现: 通过以上7个指标的快速观测,运维人员得出初步结论:TCP 传输过程的重置是导致此次异常的原因。 再次通过 TCP 客户端重置、TCP 服务端重置这两个指标对重置原因进行观测分析,发现所有的 TCP 传输过程的重置行为都是由服务端发起的,从而得出最终结论:服务端系统主动重置 TCP 连接,导致了业务的偶发性中断。 经业务开发人员对服务端系统的分析发现,服务端的 rabbitmq 消息队列没有及时处理,持续积压导致操作系统队列打满,触发了 TCP 连接的异常,引起了业务中断。 通过此次故障的定位过程,运维人员也意识到流量指标分析对云上应用运行可靠性运维保障的重要作用,因此通过 DeepFlow 的运维监控视图灵活定制能力,针对重要系统将如下十个关键指标(在上边七个指标的基础上增加三个负载类指标)纳入到日常监控运维的视图中并进行7*24小时主动监控,从而实现面向应用的更主动的监测、保障能力: 03价值 在此次的问题定位过程中 DeepFlow 可观测性平台可以完全不需要在对云网络进行逐段的查找路由、抓包、读包分析;DeepFlow 采集器自动对云网流量进行了自动化的全链路性能数据采集;DeepFlow 的分析端能够自动的将业务请求在客户端、服务端、中间关键位置进行了自动化的关联分析、拓扑绘制,运维人员无需很高的云网技术背景即可实现对云网故障的快速定位。 通过 DeepFlow […]
Read More当然,出于数据呈现角度以及各个团队使用习惯的考虑,DeepFlow Server 端也能够以简单易用的 SQL API 方式,对外提供统一的数据服务。 案例一 比如在已有落地客户处,就有这样的使用场景。DeepFlow 可观测平台建设完成后,网络、SRE 团队习惯性地使用 DeepFlow 的 GUI 进行运维排障,而有些业务团队更习惯使用 Grafana,那么 DeepFlow 也可以作为 Grafana 的 DataSource,以及为 Grafana 增加了一些 Panel,不用修改业务代码即可展示各业务团队关注的重点业务的全景调用关系,能够准确地回答谁在访问我、以及我在访问谁的问题,同时提供非常精细的全栈指标,帮助各业务团队实现数据自服务能力。 案例二 同样,也可以在 Skywalking 中集成并展示 DeepFlow 海量的观测数据,只需要在点击 Span 的那一刻改改代码,加个页面,即可展示应用调用的全链路以及每一跳的时延,通过调用 DeepFlow SQL API 把路径逐跳虚拟网元相对应的网络 Metrics 给自动关联上,比如重传、零窗、建连失败等等,实现观测数据的共享与协作。这也是客户侧落地的一个比较轻量的方案,为业务开发团队提供无盲点的分布式追踪服务。 DeepFlow 是一个高度开放的网络性能监控、观测数据协作平台,目前底层数据平台的内核已经开源,是 CNCF Cloud Native Landscape 以及 eBPF Project Landscape 官方认证和推荐。 基于 AutoTracing、AutoMetrics 技术能够实现自动的全链路追踪,以及自动的全栈性能指标,基于 AutoTagging、SmartEncoding 技术实现多云资源池业务的自动打标,解决数据高基数场景下的性能、存储问题,以及能够集成并自动关联各团队已使用的可观测工具,如 Skywalking、Prometheus、Telegraf、oTel 等,丰富整体观测指标,有效拉通应用、中间件、容器、网络等团队的观测数据。 […]
Read More目前,在整体数字化转型过程中,证券行业的业务系统全面云原生化已是必然趋势,我们和很多证券行业的客户沟通交流,发现每个证券行业客户的云基础架构都是由三个或者三个以上的资源池组成,比较常见的有 EasyStack、VMware、K8s 以及超融合资源池 SmartX、Nutanix 等等。 在这样的混合云、异构环境下,DeepFlow 基于自主研发的高性能流量采集器软件,能够实现云上分布式应用、微服务的全流量采集。 比如在 EasyStack、华为云、超融合资源池中,采集器以用户态进程的方式运行在资源池计算节点上,负责采集该计算节点内所有业务虚拟机的流量;再比如在 VMware 资源池中,通过在 ESXi 宿主机上各运行一台专属流量采集器虚拟机,接收 ESXi 宿主机内所有虚拟机的流量;另外在 K8s 资源池中,采集器是以 DaemonSet POD 的方式运行在 K8s Node 节点上,负责采集该 Node 节点内所有业务 POD 的流量。 通过上述的流量采集器部署方式,可以构建面向证券行业混合云业务系统可观测性能力图谱的基座——数据采集层,并经过流量采集器强大的本地计算与预处理能力,向 DeepFlow Server 端输出丰富的 Metrics、Logging、Tracing 指标,包括覆盖网络、系统、应用排障的海量 Metrics 性能指标;网络流量日志、应用流量日志;以及网络流量拓扑、全栈链路追踪、应用调用追踪等 Tracing 数据。 这样能够大大降低监控数据的传输带宽消耗,实测仅为业务传输带宽的万分之一,也就是流量采集器采集到 10Gbps 的业务流量,经过本地预处理后,发送的监控数据带宽消耗仅为 1Mbps,实现对业务网络传输的零侵扰。 基于采集端上送的海量可观测性数据,DeepFlow 提供丰富的应用展示能力,包括业务网络全链路诊断、分布式应用性能分析、全网全流量回溯取证等,并从业务层面针对部署在异构资源池上的分布式业务进行全局的性能保障,这里的业务主要包含核心交易类,如集中交易、集中清算系统等等;还有互联网类、综合支撑类等等,通过 DeepFlow 提供一站式的可观测分析诊断能力,支撑证券行业混合云上业务的长期稳定运行。 另外,DeepFlow 也提供数据开放与协作共享能力,使得 IT 服务管理系统、运维大数据平台能够通过 SQL API 的方式,简单、快速地获取混合云上分布式应用的全栈性能指标;同时也可以和云管平台进行一系列的联动,可以按照租户的维度将租户内的资源和业务的监控视图赋能到租户所在的云管平台上进行使用等等。 此外,流量采集器除了能够采集流量、本地计算可观测数据之外,还具备业务流量数据包分发的能力,通过精细化的策略控制,来补齐云上其他工具对于虚拟网络流量消费的需求,避免流量采集探针的重复建设。 DeepFlow 可观测性协作的价值与使命 […]
Read More海通证券主要业务已经基本实现了云化迁移工作,大型分布式业务部署于OpenStack、VMware、容器等混合云架构之上,在业务扩展性、动态性、便捷性上得到更加有力的基础资源支撑,但是对于云网运维及云上业务保障给海通证券运维人员提出了新的挑战,主要体现在: 1.缺少云资源池网络流量可视化能力 缺乏多云资源池内网络流量数据包的采集手段,使得云内资源、业务运行处在黑盒状态,缺少云资源池网络流量可视化能力。 2.不能满足复杂网络环境中的运维排障需求 云网络环境复杂度高,网络架构中的物理网络、虚拟网络以及容器网络、租户内的各类逻辑网络缺乏统一监控及运维视角,不能满足实际的运维要求。 依靠传统网络NPM监控方法,可以针对主要网络链路或节点进行流量分析,但涉及云内复杂的通信场景,甚至包含多层云内的NAT、LB规则情况下则不能进行详细的问题分析诊断。 3.缺乏面向业务网络的监控分析能力 在云内业务动态性高,覆盖范围广,业务覆盖的资源范围可能实时动态伸缩,无法动态获知复杂的业务流量拓扑访问调用关系。 无法针对于关键业务进行例如访问时延、丢包、异常等网络及应用指标分析,使得精准的业务保障成为难题。 4.缺乏故障问题取证/举证能力 关键业务系统访问出现故障,无法明确区分是物理网络原因,还是虚拟网络原因或是应用本身所造成,不能快速定位故障源,也不能对历史虚拟网络故障提供责任举证。 解决方案 DeepFlow 面向混合云、容器、微服务的全栈虚拟化环境,解决云原生应用诊断难的核心痛点。基于自主研发的零侵扰采集和高性能实时数仓等创新技术,实现对网络、系统、应用的全栈指标采集和全链路追踪,并结合云资源知识图谱实现100+维度指标数据的动态标注,构建多维度、一体化的可观测性平台。 在海通证券建设的混合云网络流量分析平台的主要技术方案要素包含如下六大方面: 一、先进的流量采集手段 提供面向多元异构混合云资源池零侵扰、高性能的流量采集手段; 采集端具备本地处理分析和指标计算和发送能力; 具备多资源池 agent 统一管理控制能力。 具备一处采集,多处分发能力。 二、贴合云网络的多维度网络性能指标可视化 平台支持通过与云平台进行对接,同步云资源池内资源及网络信息后既可按照云资源池维度(包括:资源池、可用区、宿主机、虚拟机;容器节点、命名空间、工作负载、POD;VPC、子网、IP地址)展示各类资源维度网络及应用链路流量拓扑及详细性能指标视图。 三、全栈全链路网络诊断及指标分析 能够发现并追踪网络交互流的流向,自动化梳理全链路访问关系,在统一的监控视图上分析物理-虚拟-容器网络路径,直观拆解网络路径内性能指标,判断复杂环境中故障问题点。 通过云及容器网络中交互数据包采集计算的网络及应用监控指标包括:网络吞吐、并发、TCP 建连时延、系统时延、应用时延、丢包、重传、零窗、建连失败等70余种。 四、全自动业务网络性能分析 基于业务视角,动态获知复杂的业务流量拓扑访问调用关系,针对关键业务进行例如访问时延、丢包、异常等网络及应用指标分析。 五、云资源池及分布式业务网络 SLI/SLO 评估 以全量网络性能指标为数据基础,以实际业务表现及基线指标作为 SLO 目标,打造云资源池网络及云内业务的可用性服务体系。 六、全局网络及业务性能预警感知 能够动态感知业务网络变化,资源变更情况,结合多资源池一体化的网络性能指标分析,提供各类性能指标阈值告警、基线告警能力,在业务报障之前进行异常指标和状态告警。 实现价值与效果 DeepFlow 可观测性平台帮助海通证券在云网络精细化运维、云上业务全方位保障、资源池及业务量化评估、资源管理辅助决策等方面实现了重要的阶段性建设成果,大幅提升了云团队的运维及运营效率。 (1)补全云网络及业务层监控空白 在已有云资源层面的监控基础上,实现多云异构混合云资源池云上业务交互、上层数据包分析的监控,提供从底层资源到上层业务网络的全方位定界定位与性能保障。大幅提升排障效率,节约运维成本,减少故障损失。 (2)打造云资源池网络 SLI/SLO 体系 在制定云资源池业务网络性能 SLI 体系过程中,以 DeepFlow 的全量网络性能指标为数据基础,以实际业务表现及基线指标作为 SLO 目标,逐步打造成熟的云资源池网络及云内业务的可用性服务体系。 (3)全链路端到端能力建设 针对海通证券大型分布式业务场景面临的全周期支撑需求提供横、纵多维度交叉运维能力,打破传统的专业节点运维信息孤岛,形成可视化、跨层级、多视角的业务链运维管理能力。 […]
Read MoreQ1|如何集成 Prometheus、Telegraf、OpenTelemetry 等数据?有什么好处? A:DeepFlow Agent 支持配置数据集成服务。打开该服务后,Agent 就可以接收 Prometheus、Telegraf、OpenTelemetry 的数据,并通过 Server 保存到 DeepFlow 的数据库中,从而可以通过 SQL 进行查询。 至于好处,那就是 DeepFlow 实现了 Tag without Limit,可以让开发者尽情的注入丰富的标签,进行 Tracing、Metric 和 Logging 数据的关联、切换和下钻,充分挖掘数据的价值。 Q2|注入大量标签后是否仍旧需要使用者明确数据内的标签列表,才能做到精准匹配自己想要的数据? A:DeepFlow 的 SQL 支持 show tags 可以帮助您选择具体的标签,同时也支持 show tag values 帮助你进行具体标签数值的筛选和匹配。我们的标签匹配也支持字符串匹配和正则匹配,相信可以你很容易精准匹配到自己想要的数据。 Q3|这种在查询侧来补充和关联标签数据,会对 DeepFlow Server 有很大的压力吗? A:DeepFlow Server 的查询时编解码,很好地利用了 ClickHouse 的字典能力,所以并不会给 Server 造成压力,整个查询过程是在数据库侧完成的。 Q4|除了 ClickHouse 以外的存储,DeepFlow 团队后续的三方存储插件有相关计划吗? A:目前已经有一部分观测数据支持了阿里云的 SLS,还在继续迭代支持中。如果你有其他插件的具体使用场景和需求,也欢迎和我们一起探讨,谢谢! Q5| […]
Read More本次分享主要介绍了蚂蚁集团统一可观测性平台的工程技术体系。通过对技术架构的分享,透视为何蚂蚁能将自基础设施到业务,乃至客户端的可观测能力融合到统一平台,为公司运维与稳定行保障提供基础底盘。分享中将会着重介绍两大核心技术点:大规模实时采集与预计算系统、自研并已开源的时序数据库 CeresDB。本次分享会逐步揭秘蚂蚁在可观测领域的技术选型与技术演进方面的思考。 为了探究云原生应用系统的内部状态,我们希望向观测数据中注入尽量丰富的标签,这些标签以往通过开发人员手动在代码中注入,或通过配置 Promtheus、OpenTelemetry 实现,一方面造成了很大的工作量和资源开销,另一方面也导致不同信号源的数据标签不一致形成数据孤岛。 DeepFlow 依靠 AutoTagging 机制可以为所有观测信号统一注入标准的、丰富的标签,很好的解决了这些问题。本次直播将会为大家解密支撑 AutoTagging 高性能的关键机制 SmartEncoding。通过对标签数据的分离编码和查询时关联,我们将存储开销降低了 10~50 倍,并且能支持无限量的 K8s label/annotation 等信息作为业务自定义标签。通过 deepflow-server 提供的 SQL API,这些编码和关联机制对使用者完全透明,就像在一张大宽表上直接查询。 Q1|多集群场景下,时序数据库要如何 hold 住海量数据? A:a)如果多个集群分布在地理上隔离很远的几个区域,比如上海到深圳甚至大西北,那么这个时序数据库不同集群的资源和节点数量需要对读写的区域分布进行匹配,这样可以获得最好的性能,数据就近存储。 b)另外 hold 海量数据其实和单集群的内部比较有关系,主要通过内部的分 shard 和表迁移的机制,提供水平扩缩容的能力。这些能力主要是由 ceresmeta 组件提供的。 c)实际在生产环境中,除了以上的时序数据库本身的功能需要提供支持外,还需要有对应的运维平台配套,保证生产环境的长周期稳定性。 Q2|trace 相关蚂蚁内部仍然使用的 SOFAStack 吗,有考虑过新的迭代吗? A:目前蚂蚁内部仍然在使用 sofa tracer。暂时 sofa tracer 对蚂蚁的系统可观测性来说是沟通的,因此短期内没有大的更新迭代。 Q3|如何参与到 CeresDB 社区的贡献? A:a)参与到 CeresDB 社区可以通过任何形式,我们在 github 代码仓库的 Issue 板块中分解了很多细粒度的工作任务,大家可以从里面选择感兴趣的 issue 进行提问或者贡献代码。有任何不清楚的内容也可以在 […]
Read More随着 DeepFlow 云原生可观测性平台的深入应用,在光大银行的全栈云及云原生应用运维中,通过大量的运维实战案例,充分说明了可观测性对于企业 IT 开发、运维、运营的巨大价值,真正实现了云原生业务的洞察能力和稳定性保障能力的,在实际运维中云原生可观测性平台发挥了直接有效的作用: 1、在某应用从传统分布式环境向容器平台迁移工作中,开发测试环节发现该应用遇到性能压测明显受限的问题,通过传统的测试工具、APM 工具在数周的定位过程中均无法找到问题根因,导致该应用的云原生迁移进度严重受阻,因此 DeepFlow 云原生可观测性平台紧急增加对该环境的采集覆盖和分析,在1分钟后完成了对该应用访问关系的绘制和应用调用追踪,在5分钟内通过指标分析发现了微服务中的性能瓶颈点和性能瓶颈根因。 2、在云上某次***业务异常的故障定位中,需要消耗2名中级运维工程师数十个小时的工作量,进行 Pcap 抓包、读包定位,改用 DeepFlow 可观测平台提供的手段,通过1步绘制拓扑,8个指标观测,3端日志的关联分析,在30分钟内确定服务端软件异常,进而指导业务运维人员定位发现 3、RabbitMQ 消息队列未及时处理,队列积压导致的应用同步状态异常问题。 4、在某次云上数据库偶发性故障定位中,通过1步绘制拓扑,5个指标观测,3分钟内的日志分析,快速界定出故障源为数据库应用异常。 5、在某次云上虚拟机访问不通的故障定位中,通过1步绘制拓扑,3个指标观测,1分钟内的日志分析,确定是由于虚拟机路由配置缺失导致。 实现价值 通过 DeepFlow 云原生可观测性平台的构建,在光大银行的运维实践中,产生了巨大的实战价值,包括: 打开云、网、应用“黑盒” 通过 DeepFlow 云原生可观测性平台,打开了云网黑盒,打开了云原生平台的系统黑盒,打开了云原生微服务调用的黑盒。 闪速故障定责定界定位 DeepFlow 云原生可观测性平台的数据关联分析、极简高效的数据呈现,实现了分钟级时延故障定界,分钟级丢包故障定位,分钟级业务异常故障定界,疑难杂症的定位周期由数天缩短至30分钟内。 加速云原生迁移 在实践中,我们还发现通过可观测性不仅仅能加速光大银行线上生产故障定位,提升在线业务可靠性,还能够助力光大银行开发、测试阶段的异常发现、异常定位,缩短开发周期,提高上线代码质量。 而且通过 DeepFlow 可观测性的快速定界能力,能够厘清故障界面,提升光大银行内部对云、容器平台的可靠性认可,提升应用向云原生重构、迁移的信心。 打破组织边界,构建融合统一运维能力 随着云原生的发展,IT 开发组织、运维组织的形态也正在快速变革中,通过DeepFlow 可观测性构建光大银行跨云、容器、网络、应用的统一可观测能力,打通了光大网络团队、云技术团队、应用运维团队三个组织的运维边界,通过统一、客观的可观测数据,为跨组织协作提供客观依据,提升沟通效率,减少运维矛盾。 思考与总结 在可观测性平台的建设过程中,我们也遇到很多挑战和困难,比如可观测性概念推广普及难,可观测性建设缺乏指导方法论和建设标准,用户组织架构与观测数据融合的矛盾。首先,对于可观测性概念用户普及难的问题,我们发现真实的原因是可观测性概念抽象、对象宽泛、与监控区分不清、缺乏衡量标准。如果要高效率的推广可观测性,首先要站在用户的角度,结合场景,合理阐述和布道可观测性。通过大量的技术通过与交流,我们总结了简单易接受的可观测性定义: 可观测性定义1:源于监控,又不止于监控;源于运维,又不局限于运维。 可观测性定义2:通过海量、多源、异构数据(指标、追踪、日志)的获取、关联、分析,最大化发掘IT系统数据资产的价值(IT系统大数据分析、数据挖掘)。 其次,对于可观测性建设缺乏指导方法论和建设标准的问题,经过在可观测性平台建设的过程中,我们认识到可观测性的建设不是一朝一夕、一蹴而就的,可观性平台的建设更要关注持续性、成长性,更要关注平台的如下几点能力: 持续提升,不断增加新数据源的能力 持续提升,不断扩充新标签关联的能力 持续提升,不断发掘新的数据价值的能力 最后,对于用户组织架构与观测数据融合的矛盾,核心在于可观测性对于组织中各个团队的价值和收益,我们在 DeepFlow 可观测性平台的建设中,以价值为锚点,不断地推广、宣传运维数据打通、运维数据关联、运维数据融合的巨大潜力和价值,从而不断争取更多的团队和角色对可观测性的建设提供支持,构筑数据更加丰富,使用功能更加强大,数据价值更大的可观测性。
Read More应用云化、云原生化是企业全面数字化转型的必要技术基础,光大银行2019年开始建设新一代全栈金融混合云平台,在引入了多种云计算核心技术的同时,也开始采用云原生集群架构为应用架构服务化改造提供平台支撑,随着全行应用系统的逐步上云,全栈云的可观测性成为信息科技部关注的重点。 随着云原生技术的应用,网络、系统、应用运维均发生了革命性的变化,应用软件向微服务架构发展,微服务调用关系复杂,开发迭代速度加快,系统资源实时动态变化,云网黑盒化严重,应用迁移上云之后的系统稳定性、业务可靠性保障面临巨大挑战。 同时云原生基础设施与云原生应用的监控运维手段,也面临很多如下新问题: 微服务架构下多语言、多网络协议带来应用的埋点成本高; 微服务化导致业务调用链过程复杂,全链路追踪难; 应用交互跨容器、虚拟机、宿主机多层,故障定界难; 网络路径交织复杂、动态多变,逐段抓包难,故障定位难; 应用、系统、云网的指标数据、日志数据、追踪数据、标签数据存在高基多维的特点,数据关联、分析、呈现处理技术复杂; 云原生应用与云原生基础设施之间的数据存在鸿沟,缺乏统一的运维能力,导致应用监控运维与基础设施运维协同难度高,故障处理效率低; 应用从分布式架构向云原生迁移过程中,缺乏有效的工具支撑云原生应用的开发、测试、迁移。 这些变化和挑战给光大银行的 IT 运维、业务保障带来巨大的困难,传统监控运维手段难以满足云技术变革背景下的运维需求,构建云原生统一可观测性平台就成为解决这类问题的必然技术选择。 DeepFlow 可观测性平台 在光大银行新一代全栈金融混合云平台的规划初期,技术团队即结合此前工作中的经验总结,将全栈云和云原生业务的全面可观测性列入到云平台的重要能力中,同步规划、同步验证、同步建设 DeepFlow 云原生可观测性平台。 整体方案中包括了 DeepFlow 云原生轻量级采集探针和 DeepFlow 云原生可观测性分析平台。 DeepFlow 轻量级采集探针实现了对云原生可观测性数据的低成本、全面采集,具体包括: 通过 BPF 技术对 IAAS 层、PAAS 层及 NFV 网元(LB、NAT Gateway、分布式路由等)的虚拟网络的全链路全流量采集能力,实现业务端到端的网络指标数据、追踪数据、日志数据的统一采集; 通过 eBPF 技术构建对云原生应用无开发语言依赖、无开发框架依赖、无计算平台依赖的无侵入采集能力,实现云原生应用指标数据、追踪数据、日志数据统一采集; 通过采集探针的开放接口,无缝汇聚 Skywalking Agent 的 OpenTelemetry 数据,实现云原生应用进程级的指标数据、追踪数据、日志数据的统一采集; 通过容器平台的 API 能力,实时感知容器资源的动态变化,实现云原生资源、业务标签数据的统一采集。 DeepFlow 云原生可观测性平台的核心技术和实现包括: 通过 Autotag 技术自动为所有观测数据注入统一的属性标签,消除数据孤岛问题,以释放数据的下钻切分能力; 通过 SmartEncoding 技术将属性标签编码为整型值,在标签注入阶段直接注入整型标签,以10倍的效率提升可观测性数据的存储、处理性能; 通过高性能数据分析引擎,对海量、高基、多维、异构的可观测性数据进行统一的标记、关联、分析; […]
Read More十二年前 Dapper 在 Google 的成功定义了分布式追踪的规范,而随着云基础设施及云原生架构的规模化采用,经典的追踪机制逐渐遇到了瓶颈:一方面微服务的简化为开发者带来了自由,但随之而来的是插码工作量的显著增大;另一方面服务网格、K8s、云基础设施等组件带来的复杂度超越了业务本身,让开发者捉摸不透,成为了追踪路径上的主要盲点。本次分享介绍 DeepFlow 使用 eBPF 为分布式追踪带来的革命性创新。借助 eBPF 的零侵扰机制,开发者无需修改代码、无需重新发布、无需重启服务,即可实现全景、全栈的分布式追踪能力,覆盖各类语言的微服务及基础设施。以此为起点,开发者可以灵活选择符合 OpenTelemetry 规范的经典追踪方式生成代码粒度的追踪数据,进一步细化追踪粒度。 Q1|eBPF的落地成本和效益之间如何权衡? A:成本很低:无需修改代码、无需业务进程重新发版、无需重启业务进程。收益显著:零侵扰获取全栈性能指标、全景应用拓扑、分布式追踪数据。 Q2|是否支持了 Java 异步线程的链路追踪?另外 Java 函数级的耗时能否追踪到? A:某个调用的请求和响应分别位于两个线程中,这种场景可支持;两个调用完全在两个不同的线程,这种场景目前尚不支持。Java 函数级的耗时追踪预计在 v6.3 中支持。 Q3|eBPF 是否支持获取服务器节点算力信息,例如 CPU 利用率、核数,memory,gpu 等信息? A:这些基本指标无需使用 eBPF 获取,Prometheus Node Exporter、Telegraf 都能实现。 Q4|如何无侵入做 Go 和 PHP 的方法调用维度(服务内)的链路监控, 理论上应该是可行的? A:对于协程语言,DeepFlow 通过协程染色机制实现分布式追踪,详细逻辑可看直播回放了解。 Q5| 是否支持K3s? A:eBPF 不涉及到容器编排系统的兼容性,支持。但 DeepFlow 没在 K3s 上实际跑过,社区小伙伴感兴趣可跑一跑并反馈遇到的问题。 Q6|每台机器上的性能开销如何? A:eBPF 的插桩开销可参考 Brendan,Gregg […]
Read More用户:某省级电网企业 挑战 定界困难:当发生故障,业务部门和网络部门互相推诿,而不是解决问题; 监控颗粒度不足:运维难以深入到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
云杉 世纪
2024年3月29日
云杉动态, 最新内容