从一次慢请求到一条 SQLPinpoint 全链路追踪快速入门指南【免费下载链接】pinpointAPM, (Application Performance Management) tool for large-scale distributed systems.项目地址: https://gitcode.com/gh_mirrors/pi/pinpoint凌晨两点用户群弹出一句下单特别卡。你手里只有一台机器和几份滚动日志却分不清瓶颈在网关、服务编排还是最后那条 SQL。Pinpoint 这类分布式 APM 工具的价值就是在不改业务代码的前提下做全链路追踪给每个请求一个 TraceID贯穿整条调用链路的唯一追踪编号把散落在各服务里的耗时串成一张可查询的链路。下面用一个最小 Demo 走一遍接入与排障流程。一次请求在 Pinpoint 里怎么被串起来整条链路只回答一个问题一个请求从进到出经过了谁、各自花了多久。入口拦截Agent 以 Java Agent 形式随 JVM 启动对 Web 容器如 Tomcat的入口方法做字节码增强无需改代码。生成编号新请求到达时生成 TraceID 与 SpanID标识链路中单个处理环节的编号并压入线程上下文。跨服务透传调用下游时把编号写进 HTTP 头或 RPC 元数据下游服务还原出同一 TraceID链路便跨进程延续。记录与上报各节点把 Span一次调用的耗时片段打包发给 Collector。落库与展示Collector 把数据写进 HBaseWeb 端按 TraceID 重组出完整调用链。上图是一张服务拓扑从 USER 到 ApiGateway再到各个服务与 MySQL边上的数字就是调用量。看到请求走向只是第一步接下来要让它真正跑起来。从零跑通第一个被追踪的应用整条链路分三段把仓库构建出来、把存储和采集端拉起来、把应用挂上 Agent。构建、初始化与启动先克隆并构建仓库再用仓库自带的 HBase 脚本建表。Collector 与 Web 的启动命令统一形如java -jar -Dpinpoint.zookeeper.addresslocalhost pinpoint-collector-boot.jarWeb 同理换成对应 jar这里不展开。git clone https://gitcode.com/gh_mirrors/pi/pinpoint pinpoint cd pinpoint ./mvnw install -DskipTeststrue $HBASE_HOME/bin/hbase shell hbase/scripts/hbase-create.hbase cd quickstart/testapp ./mvnw clean package用 Agent 挂载 TestApp仓库里带了个quickstart/testapp示例。启动时只加三个参数Agent 路径、agentId和应用名应用本身不动一行代码。cd ../.. java -jar -javaagent:agent/target/pinpoint-agent-*/pinpoint-bootstrap.jar \ -Dpinpoint.agentIdtest-agent -Dpinpoint.applicationNameTESTAPP \ quickstart/testapp/target/pinpoint-quickstart-testapp-*.jar访问http://localhost:8082触发几次请求回到 Web 端就能看到 TESTAPP 出现链路数据开始累积。追踪 ID 如何从请求头落到日志行跨服务靠的是 TraceID 透传跨系统排障靠的是把它写进日志行。两处源码各看几行就够。在 log4j2 里注入 TraceIDlog4j2 插件在每次记录日志前把当前上下文里的编号写进ThreadContext之后用 MDC 占位符即可带出Trace trace traceContext.currentTraceObject(); if (trace ! null) { ThreadContext.put(TRANSACTION_ID, trace.getTraceId().getTransactionId()); ThreadContext.put(SPAN_ID, String.valueOf(trace.getTraceId().getSpanId())); }见 LogEventFactoryInterceptor.java常量PtxId/PspanId即日志里的两个占位符。在 log4j2 布局中加上%X{PtxId}每一行日志就自带追踪编号用它在 ELK 里一搜就能对上链路。让 TraceID 跟着 HTTP 头走出站 HTTP 客户端插件会基于当前 TraceID 推导出下一跳编号连同主机名一起写进请求头final TraceId nextId trace.getTraceId().getNextTraceId(); recorder.recordNextSpanId(nextId.getSpanId()); String host getHost(httpRequest); this.requestTraceWriter.write(httpRequest, nextId, host);见 ExecuteInterceptor.java。write这一步是跨服务不断链的关键——编号进了头下游就能续上。定位一次慢请求的四个动作数据攒起来后排障基本是固定动作锁定异常时段在 URL/URI 统计里按响应时间分档找峰值先缩小到具体接口和时间窗。展开调用栈点开慢请求从 Tomcat 入口一路看到 Service、HTTP 客户端直到 SQL横向对齐每段的 Self 耗时最长的那段通常就是瓶颈。核对错误来源若伴随失败切到错误分析按错误类名/堆栈分组确认是业务异常还是底层连接问题。回源验证拿到那条慢 SQL 或慢调用后回到代码/数据侧确认是索引、序列化还是下游问题改完用同一链路复测对比。上生产前该调的几个旋钮默认配置开箱即用但流量上去后建议按需收紧。以下键名均来自仓库默认配置pinpoint-root.config关注点参数说明采样开关profiler.sampling.enable关闭则完全不上报仅作兜底采样方式profiler.sampling.type默认COUNTINGn 取 1可切PERCENT采样密度profiler.sampling.counting.sampling-rate值为 n 时约 1/n 被采样如 50 约 2%限流保护profiler.sampling.new.throughput新事务每秒上限0 表示不限组件覆盖各profiler.plugin.*按插件开关细粒度采集未命中即跳过两点提醒采样率别一上来调到 1%先保 P99 可查再降中间件版本不匹配时插件会静默跳过上线前核对所用框架与插件版本是否对齐完整覆盖清单可看 doc/modules.md。整体开销通常在个位数百分比内瓶颈更多在 HBase 写入与存储而非 Agent 本身。接入只需给应用加一个-javaagent参数先把 Demo 跑通、用调用栈定位一次真实慢请求再逐步把生产服务纳入采样。链路串起来之后用户说卡就从一个玄学问题变成一条可点开、可对比的具体调用链。【免费下载链接】pinpointAPM, (Application Performance Management) tool for large-scale distributed systems.项目地址: https://gitcode.com/gh_mirrors/pi/pinpoint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考