挂上 Agent，拓扑图自己长出来
SkyWalking 的接入体验在同类产品里是最顺的：javaagent 挂载、不写一行代码，服务间的调用关系自动长成拓扑图，慢接口的每一跳耗时摊开在 Trace 树上。DB、MQ、Redis 客户端这些组件的埋点插件开箱即用——对存量系统最友好的观测方案，没有之一。
Agent 接入五步
// Dockerfile 里的接入三行
COPY skywalking-agent /skywalking-agent
ENV JAVA_TOOL_OPTIONS=-javaagent:/skywalking-agent/skywalking-agent.jar
ENV SW_AGENT_NAME=order-service
ENV SW_AGENT_COLLECTOR_BACKEND_SERVICES=oap:11800
// 接入清单：
// 1. agent 版本与后端版本大版本匹配
// 2. 服务名全局唯一，作为拓扑与告警的标识
// 3. 灰度验证一台，看 Trace 是否正常上报
// 4. 全量滚动，观察 CPU/内存开销（通常 3% 以内）
// 5. 插件按需启用，不用的一律关掉两个接入后的常见问题：日志里 TraceId 没打通——确认日志框架的 traceId 参数已开启（SW_AGENT_LOG 相关配置），日志与 Trace 关联是排障效率翻倍的一步；某些组件没生成 Span——多半是插件没启用或版本不兼容，去 agent/plugins 目录核对。
慢接口定位的姿势
拿到一条慢 Trace，从树根往下看：节点自身的耗时等于"总耗时减去子节点耗时"——子节点都不慢而父节点慢，慢在节点自己的代码里；子节点慢，顺着最慢的枝继续往下钻。常见结论集中三类：串行调用本可并行（几个下游逐个调，耗时直接相加）、循环里调 RPC（N 次网络往返，批量接口一次搞定）、慢 SQL 或大结果集（DB Span 特别长）。配合"按 P99 排序的接口列表"按周对比，劣化的接口自己会浮出来。
采样与存储治理
采样率按流量定：低峰期可以全采，高峰期按 1%～10% 采，错误与慢请求强制保留。存储侧三件事：TTL——Trace 与指标数据设保留期（如 Trace 7 天、指标 90 天）；容量——ES 存储估算按峰值 QPS × 采样率 × Span 大小，留 50% 冗余；索引——按天滚动索引，配合定期清理，观测数据的成本失控，通常都是 TTL 忘了配。
别让观测压垮系统
观测系统自己是系统的一部分，也会挂：OAP 单点时 Trace 全丢但业务还在跑——所以 OAP 要集群部署；Agent 升级要灰度——坏 Agent 比没有 Agent 更糟；采样与告警规则进配置中心——观测的开关本身也要可治理。下一篇转向日志：Trace 之外的另一半排障证据，散落在二十个容器里的报错。
评论 (0)