面向已经使用 OpenTelemetry 的团队
保留所有 exporter，再加版本检测。
Collector 已经具备相连链路、运行时指标、服务身份和 fan-out。保留全部目的地，把 Sixty 作为一个 OTLP/HTTP exporter 加入，同一份遥测就能变成逐版本问题检测器。
它测量什么
- 相连的 HTTP、RPC 和数据库 span
- 生成操作、依赖、延迟分布、自身耗时、错误、数据库调用；有语义属性时也包含行数。
- 有用的语义 histogram
- 没有链路时，HTTP 和 RPC 时长 histogram 可作为保真度较低的操作 baseline。
- 运行时和连接池压力
- CPU、内存、event loop、GC 暂停和连接池压力成为发现的有界上下文。
- 服务、环境和版本身份
- service.name 选择服务，deployment.environment.name 区分环境，deployment.revision 或 service.version 锚定比较。
它能找到什么
这里的每一项都会和上一个版本作比较，所以发现指向的是那次改动，而不是某一天。
版本后变慢的 endpoint
按操作和版本比较分布，不把共同流量峰值误报为代码回归。
数据库路径开始做更多工作
相连 DB span 会显示调用次数、round trip、延迟和行数变化。
多个慢操作背后的运行时饱和
CPU、内存、event loop、GC 和连接池压力共同支持资源原因。
开始失败或变慢的依赖
出站 span 保持为依赖，不会混入自己的 self time。
无法支持比较的遥测
缺少 service.name 会 partial reject；缺少或固定 release 会显示为摄取状态。
你的动态里会出现什么
不是一块需要你去读的仪表盘。每条发现一张卡片，上面有数字、有改变了它们的那个版本，还有你的编码助手写出修复所需要的证据。
由 apps/otel-demo-app 生成：没有原生 agent，只通过公开 receiver 发送六个 OTEL 版本。
GET /checkoutserver span 变慢，同时运行时饱和度和连接池压力在同一版本窗口上升。
OTEL demo 的六个版本中
GET /checkout相连 DB span 显示更多下游工作，并保持与 endpoint 的归属关系。
OTEL demo 的六个版本中
如何安装
在现有目的地旁新增一个 exporter。不要替换 receiver、processor、sampling、redaction 或现有 exporter，也不要为 Sixty 增加日志 pipeline。
exporters:
otlphttp/sixty:
endpoint: https://ingest.sixty.sh
headers:
Authorization: "Bearer ${env:SIXTY_OTEL_KEY}"
compression: gzip
retry_on_failure:
enabled: true
service:
pipelines:
traces:
exporters: [your_existing_exporter, otlphttp/sixty]
metrics:
exporters: [your_existing_exporter, otlphttp/sixty]验证配置并只重启 Collector，再用两个不同 release 发送流量；check_service 确认数据和版本身份。
它不做什么
- OTEL 不等于原生 agent：自动函数 span、驱动专属查询细节和源码归因无法从通用链路重建。优先级为原生 agent、OTEL 链路、OTEL 指标。
- Sixty 不是链路仓库，只保留有界 sketch 和 exemplar，不提供链路搜索或 dashboard。
- 日志和任意自定义指标通过 partial success 拒绝；原始数据库语句不会保留。
- 多服务 gateway 不应设置统一 service.name；应按应用设置身份和 release。
如果你是因为下面某一条来的
看看你的上一次改动做了什么。
试试看！在做别的东西？可以看看 Node 服务、Python 服务、Go 服务 —— 那些页面不一样，我们能看到的东西也不一样。