trace相关杂谈

opentracing-trace规范，childOf+followsFrom(异步，如mq)
opencensus-trace+metric规范，agent+collector
opentelemetry- trace+metric+log, opentracing+opencensus, api+sdk+工具+集成，collector(collect,transform,export，注意collect可支持OTLP和多种协议/方式接收数据，如zipkin数据配置zipkinReceiver来进行收集并转化为otel形式)
注意agent-collector-backend逻辑， otel有agent+collector，因此它不是一套完整的解决方案(skywalking,p8s就是完整方案)，可考虑otel-collector 将 log、metric、trace 分别推送到ELK、Prometheus和相关APM产商，如 Jaeger

标准规范：概念定义，如什么是trace/span，span有哪些属性 api：某语言的类型和接口定义 sdk：某语言客户端实现，即api+api的实现，注意sdk广义概念上包括agent
规范-具体语言api+sdk-各框架集成sdk(改造框架sdk的集成方式侵入太强，agent友好，agent增强jar也认为是sdk)

skywalking：自己的规范(trace,segment,span)，完整的实现，可appender获取日志
arms应用监控: 来自鹰眼，也是自己的规范，可arms-sdk自定义打点，可agent拦截获取日志
arms也存在p8s监控mysql/es
问题：sdk很薄，实际在agent增强了，sdk很弱，没错，你只能获取traceId/spanId/span属性+改变span的属性，无法新增span，无法自定义指标
arms不希望你通过sdk随便玩，怎么办？
1 otel sdk丰富span调用链
2 sls sdk写时序数据-自定义指标，明显sls才是未来可观测性的方向

客户端：arms sdk/agent，otel sdk/agent，arms agent+otel sdk(注意arms agent对otel sdk做了处理，arms和otel不同上下文，需将arms agent的外层点和otel sdk内层点合为一体)
arms服务端：任意arms和otel格式数据都能兼容
arms otel-collector：类似原生otel-collector，加入armsReceiver，armsExporter，transform逻辑丰富

sls trace: otel的后端(存储分析可视化告警)，同时也兼容其他格式trace数据接入(内部会转换为otel格式)

trace, trace提取的指标，定时上报的jvm/threaddump/连接池/系统指标等信息，自定义指标，log，中间件/物理机指标，APM至少有前三个

MDC：slf4j提出的用于线程间传递的上下文，logback等实现多用InheritableThreadLocal来实现，支持在日志中输出
arms agent对log的增强：开关打开，MDC加入traceId/spanId