做大数据服务的人最怕的就是半夜被电话叫醒。尤其是你负责的那条数据服务链路白天还好好的晚上流量一上来TP99直接飙到几秒开外紧接着就是超时告警刷屏。我干过几年大数据平台和数据服务的开发运维这类问题遇到过太多次了。所谓数据服务往大了说包括实时数仓的OLAP查询接口、离线数仓的调度任务、特征服务的RPC接口往小了说可能就是某个给前端提供聚合数据的HTTP服务。不管哪种性能监控和调优都是绕不开的核心命题。这篇内容我想认真聊一聊大数据领域数据服务的性能监控与调优。不写那种泛泛的原理而是把我实际踩过的坑、验证过有效的排查手段、以及真正能落地的优化动作整理出来。适合那些正在做数据服务开发、数据平台运维或者刚接手一个性能不达标的服务的同学参考。里面涉及的内容不限定某一种技术栈但会以常见的Java服务、OLAP查询引擎、分布式调度任务作为主要场景来展开。1. 数据服务的监控体系怎么搭才有用先说结论监控不是把指标丢进看板就完事了而是要让监控体系在故障发生前给出信号在故障发生后帮你快速定位。很多团队搭监控图省事采集一堆指标大盘做得花里胡哨结果CPU都飙到80%了还没有任何告警等用户反馈了才被动去查。这不行。1.1 先分清你到底需要监控哪些指标数据服务的性能监控指标五花八门但不能眉毛胡子一把抓。我的习惯是先把指标分成四层。第一层是基础设施层就是机器层面的指标。CPU使用率、内存使用率、磁盘IO、网络带宽、文件句柄数。这些指标是基础出了问题所有上层指标都会异常所以要最先盯住。比如磁盘IO饱和你去看应用日志全是卡在写日志上业务线程全部阻塞这时候你再怎么调JVM都没用。第二层是应用层指标。对于Java服务来说包括JVM堆内存使用、GC频率和耗时、线程池活跃线程数、Tomcat/Netty等容器的连接数。对于OLAP引擎来说包括查询并发数、查询排队数、每个查询执行耗时。这层指标直接反映服务本身的健康状况。第三层是业务层指标。QPS、TPS、TP99、TP999、错误率、超时率、重试率。这层指标是用户能感知到的也是和外部SLA挂钩的。第四层是资源层指标主要指数据服务依赖的下游资源。比如查询的HDFS文件数、表的分区数、数据量增长趋势、数据倾斜程度。这些指标看着和性能不直接相关但往往是性能问题的根因。四层指标不是每层都配一套系统而是一个指标体系的四个维度。做监控方案的时候要确保每一层至少有几个核心指标进入了告警体系而不是只做展示。采集完指标还得考虑成本。全量采集所有指标的细粒度数据对监控系统本身也是一种压力。我的做法是按1分钟粒度采集指标用于实时监控和告警按5分钟粒度聚合用于天级别的趋势分析原始全量数据保留7天就够了超过7天的直接丢弃或降采样。1.2 监控链路最容易踩的三个坑监控链路看着简单就是采集、传输、存储、展示、告警。但实际跑起来坑一个接一个。第一个坑是采集端漏数据。有些JMX指标比如GC耗时如果你用的是定时拉取两次拉取间隔内发生的多次GC你只能看到最后一次的状态中间的GC次数和耗时全部丢失。解决方法是尽量用计数器差值配合时间窗口来计算或者直接依赖GC日志去解析而不是只盯JMX里的瞬时值。第二个坑是时间戳不一致。多个采集Agent上报的数据如果客户端和服务端时钟没有同步数据进了监控系统之后时间线是错乱的对排查问题会造成误导。这个事不复杂部署一套NTP时钟同步所有采集Agent强制对齐能省很多麻烦。第三个坑是告警阈值拍脑袋。很多人设置CPU告警阈值喜欢定90%但不同服务的CPU特征是截然不同的。一个IO密集型的服务CPU 50%可能就说明磁盘有问题导致CPU忙等一个纯计算型的服务CPU 85%持续跑可能是正常状态。阈值一定要基于基线和历史数据去定我后面会专门展开讲怎么定。监控系统的存储选型也要提前想好。指标数据是典型的时序数据普通关系型数据库存储成本和查询性能都不行。建议直接用现成的时序数据库比如Prometheus搭配VictoriaMetrics或者InfluxDB数据量大一点也不会把存储打爆。展示端用Grafana就够了社区模板很多不用从零开始画图。1.3 指标该设置多少阈值才合理阈值设置是监控建设里最细碎的活但也是最能看出经验差距的地方。我给一个我自己反复用过的参考值。CPU使用率常规告警阈值85%持续5分钟触发严重告警阈值95%持续1分钟触发。但如果是纯计算型服务可以放宽看是否为预期内的持续计算。堆内存使用率85%告警90%严重告警。但要注意如果服务本身是缓存型应用堆内存长期高位运行是正常的这时候应该区分的是触发Full GC的频率和耗时而不是单纯看内存水位。GC耗时Young GC单次超过200毫秒需要关注超过500毫秒要告警Full GC单次超过1秒必须告警超过3秒就必须介入处理。TP99这个没有统一阈值跟业务场景强相关。我的经验是先采集两周的TP99基线然后以基线乘以1.5作为告警阈值连续超过10分钟触发。比直接拍脑袋定一个800毫秒要靠谱得多。错误率错误率超过0.1%告警超过1%严重告警。这里要区分错误类型比如业务侧主动返回的错误码和系统级的异常权重完全不同。阈值不是静态的每个季度应该重新校准一次。业务在变化数据量在增长年初定的阈值到年中可能已经完全失去参考意义。2. 从监控告警到定位瓶颈排查思路比工具重要监控告警只是告诉你服务出问题了真正难的是快速定位瓶颈在哪里。很多新手一看到CPU飙高下意识就去加机器、加参数结果问题没解决资源倒是浪费了不少。我下面按典型的资源瓶颈场景拆解一下排查思路。2.1 CPU飙高先分清是计算密集还是GC捣乱CPU飙高是最常见的故障但根因千差万别。接到CPU告警第一步不是去看代码而是先看CPU是被谁吃掉的。在Linux上我最常用的三连命令是top -Hp pid # 查看进程内的线程CPU占用 jstack pid /tmp/thread_dump.txt # 抓取线程堆栈 jstat -gcutil pid 1000 10 # 看GC情况和各代内存使用具体节奏是这样top -Hp先找出CPU占用最高的几个线程ID把线程ID从十进制转成十六进制然后去jstack的输出里搜这个十六进制线程号就能看到这个线程到底在跑什么代码。如果是GC线程占用CPU高那就是内存分配压力大这时候jstat的结果可以告诉你是老年代一直在增长触发了频繁Full GC还是Young GC本身很频繁但每次都很短。这两种情况的解法完全不同。频繁Full GC往往指向内存泄漏或大对象分配频繁Young GC则更可能是业务代码里有循环里大量创建对象的坏习惯。如果是业务线程本身占用CPU高那就需要看线程堆栈里卡在什么方法上。我遇到过的几类典型问题正则表达式处理大文本导致的回溯爆炸、JSON序列化大对象、加解密操作、以及某些数据聚合逻辑里使用了嵌套循环而没做剪枝。判断GC有问题最直接的手段是看GC日志而不是只看监控上聚合后的曲线。-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.logGC日志是诊断JVM内存问题的第一手资料里面能直接看到每次GC的耗时、各代内存的变化曲线和晋升情况。完全可以根据这些数据反推是哪块内存出了问题再结合代码定位具体对象来源。2.2 内存问题堆内泄漏和堆外内存要分开查内存问题的排查比CPU更棘手因为内存泄漏往往是慢性的不会立刻触发告警而是累积到某一天突然OOM。堆内内存泄漏我通常分三步来查。第一步看监控里堆内存的曲线是不是呈锯齿状但整体趋势向上如果老年代使用率持续走高且每次GC后降不下来基本可以确定有对象泄漏。第二步抓堆转储文件用MAT或者其他内存分析工具看对象的支配树找大对象和可疑的集合对象。第三步就是反查代码重点看缓存、静态集合、事件监听器这类的对象有没有被无限添加。堆外内存问题更隐蔽。Netty和某些RPC框架会使用堆外内存做零拷贝如果你在监控里看到进程的RSS内存持续增长但JVM堆内存很平稳大概率是堆外内存泄漏。这类问题常规手段查不到需要借助JNA或者Native Memory Tracking去跟踪内存申请和释放。Java 8的JVM可以用Native Memory Tracking来辅助排查-XX:NativeMemoryTrackingsummary开启之后通过jcmd命令查看堆外内存的分布情况。不过NMT本身有性能损耗生产环境建议只在排查期间临时开启排完就关掉。线程数异常膨胀也是一种内存问题尤其容易被忽略。每个线程默认栈空间1MB如果线程数从200涨到2000光线程栈就多了1.8GB。出现这种情况优先怀疑线程池使用不当用了无界队列、拒绝策略配置错误或者创建线程后没有正确关闭。2.3 磁盘与网络的隐形瓶颈大数据服务里磁盘和网络问题经常被忽略因为CPU和内存告警会先响起来。但服务性能掉链子根子可能就是磁盘IO和网络带宽。磁盘IO饱和的判断方法iostat里看await指标如果持续超过100毫秒说明磁盘响应已经问题了严重。另外看util指标如果长期接近100%基本就是磁盘瓶颈。大数据场景下日志写盘、临时文件写盘、合并小文件、或者底层HDFS读写都可能导致IO飙升。网络问题的排查重点看两方面一个是网卡流量是否接近带宽上限另一个是TCP重传率。TCP重传率高意味着网络链路不稳定这时候应用层就会出现偶发的高延迟表现出来就是TP99偶尔出现尖刺但平均延迟并不高。重传问题要从交换机、网卡驱动、网络拓扑去查应用层调优解决不了根因。我曾经遇到过一类很隐蔽的情况数据服务跑在虚拟化环境里宿主机上其他虚拟机IO抢占厉害导致这台机器的磁盘延迟规律性地周期性飙升。从应用层看就是每隔一段时间出现一次查询变慢查了自己的机器一切正常。最后是通过对比宿主机监控数据才定位到的。所以在云环境或者虚拟化环境下做监控不能只用单机视角还要关注宿主机的争用情况。2.4 慢调用链的追踪思路大数据数据服务往往是链路很长的客户端调用API网关网关转发给数据服务数据服务去查询OLAP引擎OLAP引擎去扫描HDFS或者读取缓存每一层都可能成为瓶颈。这时候只看单个服务的监控很难定位问题到底在哪一层。我建议数据服务必须接入全链路追踪体系用TraceID把整条调用链串联起来。没有链路追踪遇到一次查询慢你要手工去翻三个系统的日志比对时间戳效率太低了。引入链路追踪后排查思路就清晰了。先看Trace里每一段的耗时分布如果大部分时间耗在OLAP引擎执行查询上那就是SQL和引擎的问题如果耗在数据服务到OLAP引擎的网络传输上那要查网络和序列化方式如果耗在数据服务本身的业务逻辑上那要查代码。链路追踪的采样率不用设太高全量采样会对服务本身造成明显的性能损耗。对于数据查询类服务我建议采用动态采样策略正常请求按1%采样错误请求和慢请求按100%采样。这样既保证了正常流量的性能也能确保问题请求的现场细节不会丢。3. 调优动作按层次动手不要一上来就改参数配置调优是最容易上手也是最容易翻车的环节。我在生产环境调过太多次参数最大的心得是调优一定要分层按顺序来不要一上来就动JVM和框架参数。正确的顺序应该是业务逻辑和SQL层的优化优先其次是数据结构和存储层的优化最后才是JVM参数和系统参数。因为业务层的优化效果往往是数量级的JVM参数调了半天可能也就提升几个百分点。3.1 JVM参数调优的真实经验聊JVM调优很多人喜欢堆一堆参数显得自己很专业。但实际上大部分服务用一套合理的基线参数就够了重要的是理解每个参数为什么这么设。对于大数据数据服务我常用的JVM基线参数是-Xms4g -Xmx4g # 堆大小初始和最大值保持一致避免运行时动态扩容引发性能抖动 -Xmn1g # 新生代大小一般建议是堆的1/4到1/3 -XX:MaxMetaspaceSize512m # 元空间限制防止类加载器泄漏导致元空间无限膨胀 -XX:UseG1GC # G1收集器是JDK 8上的默认选择适合大堆和多核场景 -XX:MaxGCPauseMillis200 # 设置目标停顿时间但不要设太激进设太小反而会导致GC频繁 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/dump.hprof # OOM时自动生成堆转储文件这个一定要加排查OOM的第一手资料 -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.log # GC日志保留至少7天有些服务用了CMS在JDK 8下还能跑但没必要建议尽早切到G1。CMS在JDK 9之后就被移除了长期来看必须切换。切G1之后要注意观察两个指标Mixed GC的触发频率和RSet的占用如果RSet过大说明引用关系复杂需要适当调整G1的Region大小。实际生产里我遇到最多的是两类JVM问题。一类是堆设置过大但机器内存不够导致操作系统把部分堆内存swap到磁盘上性能断崖式下跌。这类问题可以通过关闭swap解决或者进一步检查机器的内存分配。另一类是动态年龄判定导致对象提前进入老年代频繁引发Mixed GC。这类问题要看GC日志里的晋升情况必要时通过-XX:MaxTenuringThreshold参数限制晋升年龄。注意一点JVM调优是性能压测和线上监控共同驱动的不要凭感觉调。每次调整参数后必须用压测验证效果并且保留调整前后的监控曲线对比否则你根本不知道这次调整是变好了还是变差了。3.2 SQL与查询层的优化点在大数据场景下数据服务性能瓶颈很大比例出在查询层。我见过太多案例应用层调优做了半天最后发现是一条SQL没走对执行计划。SQL调优第一个要查的是谓词下推。无论是Hive、ClickHouse还是Doris这类OLAP引擎对谓词下推的支持程度直接影响查询速度。如果过滤条件没有被下推到数据扫描层引擎会把大量无关数据读上来再做过滤性能差距可能是几十倍。怎么看通过各引擎的EXPLAIN语句看执行计划确认过滤条件出现在扫描阶段还是更靠后的阶段。第二个要查的是分区裁剪。数仓表按时间分区是基本操作但如果查询条件里的时间字段没有正确使用分区列或者函数包装导致分区裁剪失效scan的数据量就会成倍增加。比如你在WHERE条件里写了to_date(partition_col) 2024-01-01某些引擎就做不了分区裁剪应该直接写partition_col 2024-01-01。第三个要查的是Join策略。数据量小的维度表应该使用广播Join避免大表和小表的Shuffle开销大表Join大表要考虑分桶策略让相同Join key的数据分布在同一个节点上。很多OLAP引擎提供了Join hint的语法比如Doris的[BROADCAST]要善于利用。第四个是预聚合策略。对于数据服务接口如果查询模式相对固定建议把明细数据的聚合结果通过物化视图或者定时任务提前计算好查询时直接读聚合结果而不是实时聚合。用空间换时间是大数据服务最常见的性能优化手段。重要的一点是SQL调优要基于引擎的执行计划和Profile信息不能靠猜。像Doris和StarRocks都有Query Profile功能可以看到每个查询的各个执行阶段耗时、扫描的数据量、内存占用。每次慢查询都应该抓一份Profile分析而不是盲目改写SQL。3.3 数据倾斜的实战解法数据倾斜是分布式计算里的老大难问题典型表现是某个Reduce或某个分片要处理的数据量是其他节点的几十倍导致整个作业被拖垮。具体到数据服务场景就是某个查询任务的完成时间被少数几个热点Key卡死。解决数据倾斜第一步是定位。看执行引擎的指标确认是哪个阶段出现了长尾。通常倾斜发生在聚合和Join阶段根源是某个Key值的分布极不均衡。第二步是对症下药。我处理过的倾斜场景和方案如下对于聚合倾斜可以分两步聚合。先把数据进行加盐处理给Key加随机前缀打散到多个并行节点完成第一轮局部聚合再去掉前缀做第二轮全局聚合。这个思路在大数据聚合场景中是通用方案。// 第一阶段加盐聚合 select concat(salt_prefix, group_key) as salted_key, count(*) as partial_cnt from detail_table group by salt_prefix, group_key // 第二阶段去盐汇总 select group_key, sum(partial_cnt) as total_cnt from ( select substr(salted_key, 2) as group_key, partial_cnt from first_stage_result ) group by group_key对于Join倾斜优先考虑广播小表如果不能广播可以对倾斜Key做拆分处理把倾斜数据单独拎出来用MapJoin处理其他数据用正常Join最后合并结果。还有一种情况是数据服务读取外部存储时某个分片所在节点负载过高。这往往是分片键设计不合理热点数据都落在同一个分片上。解决办法是重新设计分片策略或者对热点数据加缓存层来吸收查询压力。数据倾斜排查中最容易被忽略的是空值倾斜。业务数据里如果某个字段大量为NULLJoin时这些NULL会全部落到同一个分片上。处理方式是给NULL值赋一个随机值让它们均匀分布到不同分片。3.4 流量治理限流降级排队数据服务的性能优化不只是把服务调快还要管好流量防止异常流量把服务打死。限流和降级不是高并发互联网才需要大数据服务同样需要甚至更需要因为数据服务的下游往往更脆弱。限流的实现方式有很多种单机限流可以用令牌桶或者漏桶算法分布式限流要用Redis或者网关层的集中式限流组件。具体用哪个要看你的架构没必要为了追求分布式限流而额外引入一套复杂的系统。我的建议是数据服务至少要做两层限流。第一层在网关按接口维度限流保护整个服务第二层在服务内部按下游资源维度限流。比如某个查询接口依赖的OLAP引擎最多支持20个并发查询那客户端连接数到了就要排队或者拒绝不然引擎一被打满所有的查询都变慢。降级策略要提前设计好。数据服务常见的降级方案包括查询超时直接返回缓存结果核心指标查询降级为离线预计算结果非核心功能直接关闭。我在线上就吃过亏有一次OLAP引擎在做元数据更新查询全部变慢我们服务的超时时间设置太长导致请求大量堆积线程池全部被占满其他接口也被拖死。后来加了快速失败的降级策略引擎异常时直接返回降级结果问题就好多了。排队策略也值得一说。有些高价值查询本身耗时较长与其限流拒绝不如让它们进入队列排队执行控制最大排队长度和等待时间。团队内部把这种模式叫“有损服务”在一定范围内用延迟换取可用性和成功率。关于超时时间我的经验是连接超时、读超时和写超时要分别设置不要一个timeout走天下。而且内网服务之间的超时时间不要设太长建议读超时控制在3秒以内。太长的超时只会让故障影响面扩大不会让请求成功。4. 容量规划与长尾问题治理调优不是一锤子买卖服务上线之后还会面临数据增长和流量增长带来的新压力。容量规划做得好能让你在业务增长时减少很多突发事故。长尾问题则是数据服务性能上最难缠的部分值得单独拿出来聊。4.1 容量怎么估算才不浪费很多团队的容量规划靠拍脑袋高峰期不够了就临时加机器。这种模式在流量小的时候没问题数据量和QPS涨上来之后会频繁出问题。容量估算的核心逻辑是以峰值QPS和单查询的资源消耗为基础推算出所需的总资源再留出一定冗余。而不是看平均QPS来规划。举个例子假设你的数据服务日查询量是1000万平均QPS在120左右但晚高峰会有10分钟冲到800QPS。如果你按平均QPS规划高峰期必挂按峰值QPS规划成本又太高。我的处理方式是分三层来算。第一层确定峰值的合理估计值建议参考近一个月的峰值而不是近一周因为要留出业务增长的空间。第二层评估单请求的资源消耗这个数据可以从压测里拿比如单请求耗时100毫秒、消耗JVM内存50MB。第三层计算出满足峰值QPS所需的并发线程数再推导出实例数。单实例能满足的QPS粗略估算公式是1000 / 单请求RT毫秒 × 单实例并行线程数 × 利用率系数。比如单请求RT是100毫秒线程池核心线程数是50利用率系数按0.7算那么单实例大约可以支撑350QPS。如果峰值QPS是800至少需要3个实例再加一个缓冲实例4个实例是合理的。容量规划不是一次性工作需要配合定期压测来校准。建议每季度做一次全链路压测验证容量模型和真实能力的匹配度。压测结果和容量模型有偏差时以实测为准修正模型。4.2 长尾请求的治理手段长尾问题是数据服务性能优化中最耗精力的部分。平均延迟看着不高但总有一小部分请求慢得离谱拖累TP99和TP999直接影响SLA。治理长尾问题我建议从三个角度入手。第一识别长尾来源。长尾请求往往不是随机产生的而是有特征的。可能是某个大Key的查询可能是某个磁盘慢的节点上的请求可能是冷数据首次加载。通过链路追踪和查询日志把TP99以上的慢请求筛选出来按特征分组找到占比最高的那几类逐个击破。第二对于已知的长尾场景设置兜底策略。比如OLAP查询如果单次查询超过设定阈值直接终止改走异步任务或者返回预计算结果。这个策略看似简单但对SLA的提升非常明显。第三减少长尾的触发概率。比如给服务加缓存把热点数据和不那么热的数据分别缓存减少冷查询的比例。比如给数据服务加连接池预热避免冷启动时大量请求因为建连超时而变慢。针对OLAP引擎的长尾有一个常见原因是查询层面的资源争抢。大查询把CPU和IO吃满了小查询也跟着遭殃。给引擎配置查询资源组大查询和小查询走不同的资源路径可以有效地做隔离。4.3 小文件问题的治理大数据数据服务调优里有个很容易被忽略但又很致命的问题小文件。HDFS上的小文件过多会导致NameNode内存压力大、任务启动慢、查询扫描效率低。数据服务查询慢很多时候不是SQL写得差而是底层存储的小文件太多了。判断小文件是否严重可以看文件数量和数据量的比例。一般来说一个数据表如果单文件平均大小低于128MB就要考虑做合并了。比如一张表一天的数据量是200GB但文件数有5000个平均每个文件40MB这种表的查询性能一定好不了。小文件治理的手段核心是小文件合并。具体到不同引擎做法略有不同。Hive表可以通过Insert Overwrite的方式重写表附带合并文件的操作HDFS层面也可以写一个合并任务把小文件读出来合并成大文件再写回去。但更根本的是控制小文件的产生源头。写入端如果能做批量提交尽量增大每个批次的数据量分区策略要合理不要产生大量数据量很小的分区如果使用了Flink实时入仓要控制好checkpoint间隔和写入并行度避免每个checkpoint产生的大量小文件。小文件治理不是一次性工作要形成定期巡检的机制。建议每周统计一次主要表的文件数和平均文件大小对超过阈值的表自动触发合并任务长期坚持下来效果非常明显。5. 常见问题排查速查表把这些年在大数据数据服务上踩过的坑整理成一张速查表碰到类似问题可以对照着排查。现象可能原因首选排查手段常用解法CPU高但业务线程占用低GC线程频繁、JIT编译压力大jstat看GC频率jstack看线程状态调整JVM堆和GC参数排查内存分配热点接口RT突增周期性出现宿主机IO争抢、其他任务资源竞争对比宿主机层监控查调度时间窗口错峰调度迁移实例资源隔离查询偶发超时但平均RT正常TCP重传、链路抖动、GC停顿查TCP重传率看GC日志停顿网络链路排查调整GC参数客户端重试堆内存持续上涨不下降内存泄漏缓存无过期策略MAT分析堆转储查大对象修复泄漏点给缓存加过期和容量上限线程数不断增长线程池配置错误、连接泄漏jstack统计线程池状态改用有界队列正确设置拒绝策略SQL扫描数据量远超预期分区裁剪失效、谓词不下推执行计划分析修正SQL写法补充分区条件聚合任务极慢且分布不均数据倾斜查看执行引擎长尾分片加盐两阶段聚合广播小表重启后第一次查询特别慢冷启动元数据和缓存未预热看首次查询耗时分布服务启动时做缓存预热连接池预热磁盘IO长期高位日志过多、临时文件写盘、合并任务冲突iostat确认IO类型日志异步化临时文件放到单独的磁盘服务负载不高但TP99高连接池大小不足、线程排队查线程等待时间扩大连接池或线程池优化连接获取逻辑这张表值的不是背下来而是排查的时候有一个参考框架。实际的问题往往比表格里写的更复杂可能是多个原因叠加。排查时要有耐心一次锁定一个可疑点验证完再往下走。最后再分享一个我个人的实操习惯每次处理完一次性能问题我会把根因、排查过程、解决手段和最终的监控对比数据整理成一篇简短的复盘记录。这不仅仅是给团队留资料更是逼迫自己把整个排查的推理链理顺。时间久了你会发现自己对服务的理解越来越深很多问题看一眼告警就能猜个大概。性能监控和调优这件事就是在这样一次次的复盘中从被动救火逐渐变成主动预防的。