《云上产品》

**SLS：**是阿里云的日志服务，能采集分析日志，还能处理监控指标和链路追踪数据。你在客户现场可用 ELK 替代

**ARMS：**阿里云应用实时监控服务，约等于“Prometheus+SkyWalking + 前端监控” 的整合工具。

分几个模块：APM 模块做全链路追踪，对应开源 SkyWalking；

基础设施监控模块监控服务器、K8s，对应开源 Prometheus；

前端监控模块监控页面加载速度，你客户现场如果有前端系统，可用开源 Sentry 替代。

---

SLS 和 ARMS 常搭配用，比如 ARMS 的 APM 追踪到慢接口，再用 SLS 查该接口的详细日志。你在客户现场可类似用 “SkyWalking+ELK+Prometheus” 组合，形成 “链路 - 日志 - 指标” 的可观测闭环，比如用 SkyWalking 找到慢接口 TraceID，再去 ELK 搜这个 TraceID 的日志，结合 Prometheus 的 DB 指标，定位根因。

---

**APM：**中文是应用性能监控，主要监控应用程序的响应时间、错误率、调用链等性能指标

• 无云环境的开源apm工具：SkyWalking、Pinpoint、Jaeger、Zipkin

《应知关键词》

Trace（追踪）：一个完整的业务请求链路，比如客户 “提交订单” 从前端点击到后端处理完的全过程，就是一个 Trace。

Span（跨度）：Trace 拆分成的最小单元，记录一个服务调用另一个服务的耗时，比如 “订单服务调用支付服务”“支付服务调用 MySQL”，每个步骤都是一个 Span。

TraceID：整个 Trace 的唯一标识，像 “abc123”，通过它能把所有 Span 串起来，比如客户说 “某个订单提交失败”，你用 TraceID 在 SkyWalking 里一搜，就能看到从前端到数据库的所有调用步骤。

SpanID：每个 Span 的唯一标识，父子 Span 有依赖关系，比如 “订单服务→支付服务” 的 SpanID 是 “span-001”，“支付服务→MySQL” 的 SpanID 是 “span-002”，能看出调用层级。

**OpenTelemetry：**不是监控工具，它是当下可观测领域的国际统一标准。

专门统一三件事：链路追踪 (Trace)、性能指标 (Metric)、日志 (Log) 的数据格式、传输协议、采集规范。

简单类比：

• 以前：SkyWalking、Jaeger、ARMS、Prometheus 各自一套数据格式，互不通用，切换工具就要重写埋点；
• 现在：OTel 定统一标准，所有组件按同一格式产出数据，采集层和展示层可以随意拆分组合。

OTel = 采集规范 + 通用 SDK + 采集器（Collector）

只管 “怎么统一采集数据”，不负责存储、展示、告警；

APISIX：和nginx很想，它更适合云原生和微服务场景。比如在客户现场的 K8s 环境里，APISIX 能动态配置路由，不用重启服务，而 Nginx 改配置后通常要 reload；APISIX 还支持更丰富的插件，像限流、熔断，这些对多客户现场的服务稳定性更有用。

总结

做了链路追踪，当客户反馈“下单接口超时”，你远程打开链路UI就能看到请求从网关到订单服务、再到MySQL的完整路径，直接定位到MySQL慢查询这个根因，10分钟内就能给一线解决方案；没做的话，你只能让一线逐个登录服务器查日志，从网关日志看到请求到了订单服务，再去订单服务日志找调用MySQL的记录，可能花1小时还定位不准，甚至需要客户配合抓包，严重影响排障效率和客户体验。对ToB项目来说，链路追踪就是把“盲人摸象”的排查过程变成“透明化追踪”，这是二线运维远程解决复杂故障的核心能力体现。