企业官网建设流程全解析

新乡网站开发的公司电话,网站服务公司特点,wordpress号码,宁德网站开发摘要#xff1a;作为一款优秀的开源分布式数据库软件#xff0c;TiDB 得到越来越多的用户关注和应用#xff0c;但在运维保障过程中同样面临着运维孤岛、定界定位难、获取可观测性数据开销大等挑战#xff0c;本文总结了 TiDB 用户如何基于 DeepFlow 构建全栈可观测性的最佳…摘要作为一款优秀的开源分布式数据库软件TiDB 得到越来越多的用户关注和应用但在运维保障过程中同样面临着运维孤岛、定界定位难、获取可观测性数据开销大等挑战本文总结了 TiDB 用户如何基于 DeepFlow 构建全栈可观测性的最佳实践包括如何用 DeepFlow 高性能、零侵扰的可观测技术消除全链路追踪在 TiDB 侧的盲区如何在 DeepFlow 中统一观测业务全景、SQL 事务全过程、网络性能、系统资源性能、文件读写性能、应用函数性能从而为 TiDB 及其上应用构建出统一、立体、全方位的可观测性能力。关键词TiDBDeepFloweBPF零侵扰全栈可观测性全链路追踪分布式数据库运维挑战性能监控可观测性实践一、分布式数据库的运维挑战在日常运维中分布式数据库的 DBA 通常面临着三个方面的挑战观测数据实时性由于传统插桩方法会带来明显的性能损耗DBA 仅在出现业务异常后才会启用 TiDB 内置的分布式追踪能力故障处置时只能事后分析、反复复现、被动定位。观测数据全面性传统数据库运维主要依赖数据库自身数据缺乏客户端应用、系统资源、数据库文件读写、服务器网络性能等维度的实时数据周遭环境处于诊断盲区。观测诊断连续性传统监控工具相互之间数据割裂故障诊断经常需要在不同运维团队之间流转分析过程经常需要在多个监控工具之间切换诊断连续性经常中断。以上问题导致数据库运维与其他运维的脱节形成运维孤岛业务运行风险难发现、故障难定界、恢复周期长、沟通协作多、运维矛盾多。DeepFlow 通过零侵扰、高性能的观测数据采集、开放的观测数据接入、统一的观测数据关联分析等多项核心能力为 TiDB 提供了全栈、全链路、可生产落地的观测能力帮助 DBA 构建全链路监控、故障快速定界、根因分析等能力有效提升分布式数据库运维效率解决上述运维痛点。二、TiDB 可观测性部署方案TiDB 可观测性整体部署架构TiDB 可观测性实践方案中我们在业务集群和 TiDB 分布式数据库集群的 Node 内自动化部署了 DeepFlow Agent采集、收集多维度的观测数据结构化之后的观测数据经过网络传输通过统一处理统一标记数据标签统一关联数据统一分析数据集中存储于 DeepFlow Server 端通过紧贴运维场景的功能设计基于这些数据提供从宏观到微观、灵活、多维度的全栈观测分析能力。DeepFlow Agent 采集、收集丰富的观测数据具体包括eBPF 零侵扰数据调用链追踪、SQL 性能指标、SQL 调用日志、网络性能指标、网络流日志、文件读写事件、CPU Perf 等观测数据OpenTelemetry 插桩数据TiDB 各组件内部的调用链追踪数据Prometheus Exporter 数据K8s 系统指标、TiDB 性能指标DeepFlow 可观测性数据采集、收集示意三、调用链追踪在 DeepFlow 对 TiDB 的全栈观测实践中我们通过 eBPF 技术实现了包括前端应用、中间网络、TiDB-Proxy、TiDB 的全链路调用链追踪能力与传统 APM 技术相比DeepFlow 实现的调用链追踪具有如下优势特性无盲区消除了 TiDB、网关中间件、中间网络的追踪盲区高性能通过 eBPF 技术实现的高性能、零侵扰追踪对 TiDB 构建生产可落地的无采样追踪观测能力热加载通过 eBPF 技术的代码热插拔特性在应用和 TiDB 集群中随时上线追踪能力即使对微小的性能抖动也能持续进行细粒度观测快速发现并消除系统隐患。跨技术栈通过全栈的追踪能力实现 DBA、数据库开发、系统运维、应用运维等多个运维技术栈的统一追踪、统一协作快速确定故障边界提升技术协同效率。3.1 无盲区的调用链追踪我们可以通过一张简单的示意图来回答这样一个问题为什么说与传统插桩方案相比DeepFlow eBPF 零侵扰采集才真正实现了无盲区的调用链追踪三种不同调用链追踪方案的覆盖范围对比应用插桩传统 APM 技术通过应用代码插桩对应用调用链进行追踪观测范围局限在可插桩的应用范围内追踪能力在 TiDB 侧形成了观测盲区当业务访问出现慢响应时无法快速判断 TiDB 是否是问题的根源。应用插桩 TiDB 插桩为了将应用调用链追踪能力延伸到 TiDB我们在 TiDB 社区提交PR[1]进行代码修复实现了在 TiDB 侧的追踪能力但随之我们发现在 TiDB 中的插桩仍然存在三方面的问题TiDB 运行环境中的网络处于追踪盲区无法诊断网络对 SQL 性能的影响TiDB 前置的 TiDB-Proxy 处于追踪盲区无法诊断 TiDB-Proxy 对 SQL 性能的影响TiDB 插桩后的响应性能明显下降具体数据见下文无法在生产系统中持续使用。DeepFlow eBPF 零侵扰采集通过 DeepFlow 的 eBPF 技术构建的零侵扰调用链追踪能力消除了 TiDB 的追踪盲区具备了对任意一次应用调用过程如下位置的完整追踪能力1前端应用2TiDB-Proxy3TiDB4K8s 网络。至此我们便可以在 DeepFlow 调用链追踪火焰图中对某次慢响应进行追踪直观观测各个位置对响应时延的贡献比例从而快速确定某一次慢响应的根源位置DeepFlow 调用链追踪火焰图以下图为例我们可以在一张 DeepFlow 调用链追踪火焰图的局部清晰的确定某次业务过程中的 MySQLCOM_QUERY COMMIT调用在 tidb-proxy 进程内的处理引入了 480ms 时延DeepFlow 调用链追踪火焰图局部3.2 高性能的调用链追踪在实际生产系统中阻碍 TiDB 可观测性落地的最关键问题是观测数据采集的性能。我们发现应用内插桩、Java Agent 字节码增强等技术实现调用链采集时可能会带来显著的、难以定界的额外资源消耗并可能引入显著的业务性能损失导致此类技术方案在高并发、高性能、高可靠要求的系统中均无法落地。很多企业仅能在测试系统或非重要的生产系统中开启此类追踪能力而较为重要的生产系统只能采用高比例采样追踪来降低对业务的负面影响特别是金融行业核心生产系统会完全放弃追踪能力以确保不影响业务性能但这就导致了运行保障能力薄弱、运维风险失控。而 DeepFlow 采用 eBPF 技术实现的零侵扰Zero Code可观测性很好的解决了这些问题业务时延Response Time通常仅有亚毫秒级别的影响且 Agent 的资源消耗可预期、可设限。得益于 Just-in-Time (JIT) 技术DeepFlow Agent 的 eBPF 代码运行效率可以与内核原生代码的性能媲美且在采集过程中不会影响应用程序的处理过程做到对应用调用处理过程的零侵扰。在 DeepFlow 对 TiDB 的全栈观测实践中我们测试验证了 TiDB 集群在使用 Jaeger 插桩与使用 DeepFlow 的 eBPF 零侵扰技术进行可观测性实践时业务性能的不同表现。Jaeger 插桩采集与 DeepFlow eBPF 采集时的 SQL 性能对比Jaeger 插桩采集时TiDB SQL 响应时延我们开启TiDB 的 OpenTracing[2]功能并观察应用实例位置svc-order访问 tiproxy 的响应性能可以看到 SQL 响应的平均时延均值稳定在300~400ms之间最大时延均值在部分情况下超过了1.5s。Jaeger 插桩采集svc-order -gt; tidb-proxy 的 SQL 性能指标DeepFlow eBPF 采集时TiDB SQL 响应时延我们使用 DeepFlow Agent 对 TiDB 分布式集群进行无采样的观测数据采集并观察应用实例位置svc-order访问 tiproxy 的响应性能可以看到 SQL 响应的平均时延均值降低到3~5ms最大时延均值不超过38ms。eBPF 采集svc-order -gt; tidb-proxy 的 SQL 性能指标从以上性能对比数据中我们发现DeepFlow 通过 eBPF 技术实现的零侵扰可观测性解决了插桩方案带来的业务性能问题从而能够面向核心 IT 生产系统的 TiDB 分布式数据库构建生产可落地的无采样追踪观测能力。3.3 随时热加载的调用链追踪由于应用内插桩、Java Agent 字节码增强等技术手段带来的业务性能损失重要的核心生产系统在日常运行中基本会关闭追踪能力但当遇到故障或异常需要进行细粒度追踪时却发现插桩和 Java Agent 的启动过程需要对核心生产系统的应用实例和 TiDB 组件实例进行重启这时候追踪功能要不要开启就成为一个艰难和痛苦的抉择最终形成了这样的运维现状微小故障不了了之系统带着隐患运行。中级故障大量投入测试环境反复测试靠运气复现定位根因。重大故障全力灭火全团队 7x24 不计成本全力投入直至业务恢复。海恩法则告诉我们在任何一起严重事故背后都有 29 起轻微事故和 300 起潜在的隐患在 IT 系统的运维保障中存在同样的规律。正是由于插桩和 Java Agent 开启所需的重启动作导致生产环境中大量的潜在隐患和微小故障难以诊断定位而不了了之中级故障的复测定位消耗大量人力而重大故障还是在不断出现。DeepFlow 零侵扰可观测性完美的解决了这个难题。对应用系统或 TiDB 需要开启调用链追踪能力时随时可一键部署 DeepFlow Agent 以启动追踪数据采集Agent 部署时不需要侵入应用 POD 和 TiDB 组件 POD也不需要重启应用程序、TiDB 或操作系统Agent 仅通过 Linux 操作系统 eBPF 技术便可将追踪数据的采集代码瞬时热加载到操作系统的内核中并开启各个位置的追踪数据采集。而即便是对于负载非常高的业务系统当希望卸载追踪能力时也可在线关闭 Agent 的 eBPF 采集开关或卸载 Agent追踪数据采集代码便可从操作系统内核中瞬时卸载。在这整个过程中上层应用程序和 TiDB 组件程序无任何感知。DeepFlow Agent 在操作系统内核中随时热加载的调用链追踪能力使得我们可以在应用系统和 TiDB 集群中随时上、下线追踪观测能力而无需担忧对应用的扰动随时对微小故障和中级故障进行细粒度观测快速发现并消除系统隐患避免重大故障的发生。DeepFlow Agent 零侵扰部署3.4 跨技术栈统一协作的调用链追踪传统插桩技术的 APM 追踪适用于应用开发人员和 TiDB 开发人员调用链更多体现的是进程内部的函数调用关系没有开发背景很难看懂因此在故障定界过程中对 DBA 及其他运维角色的实际帮助不大。而 DeepFlow 可观测性平台则实现了任意一次应用调用从应用程序到操作系统、底层网络的全栈追踪能力因而可以构建面向 TiDB 运维、TiDB 开发、应用开发、K8s 运维、中间件运维等各个技术栈的全栈运维协作能力对任意一次应用调用全过程在各个处理环节的性能洞察清楚快速确定故障边界。多运维技术栈统一协作、统一观测以上图为例在 DeepFlow 可观测平台中业务应用开发和运维通过业务应用微服务的调用时延快速诊断发现业务应用的隐患或故障K8s 运维通过各微服务实例之间网卡的调用时延快速诊断发现 K8s 平台的隐患或故障中间件运维通过 TiDB-Proxy 位置的调用时延快速诊断发现中间件的隐患或故障DBA通过 eBPF 采集的 TiDB 调用时延快速诊断 TiDB 一侧的隐患或故障数据库开发在按需开启 TiDB 的 OpenTelemetry 插桩数据后数据库开发人员可以快速诊断 TiDB 内部关键函数的隐患或故障。四、全方位观测除了调用链追踪之外日常对 TiDB 运维保障时业务全景、网络性能、系统资源性能、操作系统文件读写性能、应用程序函数性能均是需要全面观测分析的维度以快速找到问题的根源可观测性实践必须要打通多类观测数据的孤岛建立观测数据之间的联系设计流畅的观测操作流使得全栈运维人员在观测运维过程中能够高效、丝滑的观测全方位数据更快更简单地在数据中找到结论。在 TiDB 可观测性实践中我们在 DeepFlow 平台中实现了多类数据的统一采集分析并通过丝滑的操作流得以高效地调阅各类数据实现全方位的观测能力具体包括业务全景观测网络性能观测SQL 语句回溯系统资源性能观测文件读写性能观测函数性能观测CPU 剖析4.1 业务全景观测DeepFlow 通过与云原生 API 接口的实时对接动态获取资源标签、业务标签并对实时采集的应用调用数据标记标签从而实现自动化、随业务动态更新的业务全景构建能力。在基于 DeepFlow 的 TiDB 可观测性实践中我们构建了从云原生应用集群到 TiDB 分布式数据库集群的端到端业务全景如下图业务全景通过构建云原生应用集群与 TiDB 数据库集群的业务全景拓扑从宏观出发观测 IT 业务系统的全貌当在业务全貌中发现局部业务性能异常时即可向微观逐步探索快速找到未知的未知。4.2 网络性能观测网络丢包、网络时延是 TiDB 数据库集群故障诊断过程中经常怀疑的问题方向DeepFlow 通过网络性能观测可以快速确定某次分布式数据库业务故障是否根源自网络故障。在网络性能观测中我们可以通过如下 6 个指标观测外部访问 TiDB 集群、TiDB 集群内部组件互访的网络交互性能诊断、确定不同类型的网络传输问题字节吞吐率——观测网络吞吐压力TCP 重传比例——观测网络丢包情况TCP 零窗比例——观测 TCP 拥塞情况建连-失败比例——观测 TCP 建连异常情况平均 TCP 建连时延——观测网络 RTT平均 TCP/ICMP 系统时延——观测操作系统的响应速度示例1快速观测客户端访问 TiDB 入口的网络交互性能svc-user -gt; tidb-proxy 的网络性能指标观测示例2快速观测 TiDB 内部组件之间的网络交互性能tidb -gt; pd 的网络性能指标观测4.3 SQL 语句回溯不合理的 SQL 语句会占用大量的 CPU 和内存资源导致 TiDB 响应延迟增加同时降低 TiDB 的整体性能因此快速回溯效率低下的 SQL 语句是数据库运维中的重要一环。未使用索引的查询、全表扫描、过度复杂的查询、使用不合适的函数或数据类型均是需要通过回溯 SQL 语句并重点关注的「烂 SQL」类型。在 TiDB 可观测性实践中DeepFlow 通过零侵扰的旁路采集能力完整记录了每一次 SQL 的详情信息包括 SQL 语句、响应时延、发生时间、源端节点等在调用日志检索中可实时检索、回溯烂 SQL 的出现频次并确定 SQL 的源头。SQL 调用日志回溯4.4 系统资源性能观测操作系统的 CPU、内存利用率过高或同时段的网络接口吞吐拥塞均可能导致慢 SQL 的出现因此为了更快更准确的找到慢 SQL 的问题根源在故障诊断过程中快速分析 TiDB 组件实例的 CPU、内存、网络接口指标是提升分布式数据库观测能力、运维能力、排障效率的关键一环。在 TiDB 可观测性实践中我们通过 Grafana Agent 采集系统指标并将数据统一汇入 DeepFlow 可观测平台对数据统一打标、统一关联、统一呈现实现了对 TiDB 组件 POD 指标数据的观测能力在调用链追踪中发现慢 SQL 的根源 POD 后便可一键调阅 POD 的 CPU 使用率变化曲线、内存使用率变化曲线、网络吞吐变化曲线通过问题时段的指标值轻松确定慢 SQL 事件与系统 CPU、内存、网络接口资源性能的关联关系。TiDB 数据库实例系统资源性能观测4.5 文件读写性能观测文件读写的性能会对 TiDB 的 SQL 响应性能产生显著影响虽然采用高性能存储资源可以尽可能的避免文件慢读写可能性但在 TiDB 运维过程中仍需要频繁回答两个问题当偶发性的慢 SQL 出现后如何确定偶发性的文件慢读写是问题的根源当系统中出现一些未知的大文件读写或频繁文件读写如何找出文件读写的源进程DeepFlow 通过 Linux 内核的 eBPF 能力实现了对操作系统文件读写事件的完整采集和观测并且支持全采集、部分采集等多种采集模式。操作系统 IO 事件 eBPF 采集原理示意图当应用出现慢响应时在 DeepFlow 中可以一键检索问题时间段客户端、服务端的全部文件读写事件在列表中快速锁定文件操作事件和源进程。当慢 SQL 响应出现时DBA 可以在数秒内确定是否有伴生的慢 IO 事件当有未知文件读写行为时系统运维可以在数秒内锁定文件 IO 源文件 IO 事件检索4.6 函数性能观测CPU 剖析对慢 SQL 的故障诊断过程中当发现 CPU 成为业务性能瓶颈点后接下来要做的便是对 TiDB 组件 POD 的 CPU 调度情况进行剖析找出 TiDB 组件程序中的热点函数从而找到程序优化的切入点。DeepFlow 通过 Linux 内核的 eBPF 技术实现了应用进程的 CPU Perf 数据采集和观测能力通过对 TiDB 组件应用进程的 CPU 性能剖析开发人员可以轻松锁定 TiDB 各组件程序中内核函数、库函数、应用函数的 CPU 热点。TiDB 可观测性实践中我们通过 DeepFlow 对 TiDB、PD、TiKV 组件进行了 CPU 性能剖析。其中在下面的 TiDB 进程 CPU 性能剖析火焰图中我们可以清晰观测到Jaeger 插桩为 TiDB 进程带来了显著的 CPU 资源开销TiDB 进程 CPU 性能剖析结果五、价值总结良好的运维保障能力是 TiDB 分布式数据库稳定运行的前提条件在此次可观测性实践中DeepFlow 通过领先的高性能 eBPF 零侵扰数据采集技术、零插桩的调用链追踪技术、多源数据的统一观测技术构建了面向 TiDB 全栈、全链路、随时热加载、可生产落地的可观测性方案显著提升 TiDB 的全方位运维能力高效助力 TiDB 数据库稳定运行帮助用户打造更加可靠、稳定的数据库服务。