zhutianyu
1. 国际化支持 2. 脚步适配目录更改 3. 添加新语言脚本，以及从默认语言目录更新文件脚本
## 为什么需要采样 - 在生产系统中，调用是非常频繁的这就导致了在高频系统中，会产生非常多的span，这样就会给整个链路和存储带来压力 - 而一些系统又不是高频系统，所以可以存储所有的span 合理的采样可以极大降低成本和整体系统的压力 所以我们对于span的产生需要进行合理采样 ## 怎么进行采样 目前主要有两种采样形式 - 一种是基于头部的采样 也就是在根链路的产生的时候来进行采样策略判断是否进行采样，目前主流的分布式跟踪框架都主要使用这一方式，虽然头部采样的形式能比较好降低span的产生，但是在实际生产中，大部分都是正常的链路，少部分才是异常链路，采样策略可能会将错误链路给命中，导致异常被遗漏。基于头部的采样，是需要在TRACE-SDK进行配置，它直接在应用程序生效，所以管控这个配置是有成本的。如果在微服务更个服务比较独立的时候还存在一些服务开启了采样，一些服务没有开启采样，这就会导致某几个未开启服务产生大量span对整个上下游服务进行了传播，导致后端服务压力大增。 - 基于尾部的采样 基于尾部的采样能很好的将异常的链路进行保留，而且基于尾部的采样是允许在接收服务中的，这就意味着，应用程序只需要关注上报服务是谁，而不在需要关注额外的配置和配置变更。但是尾部采样也存在的一些问题，就是当span跨度过大时，进行的采样的时候，可能会遗漏部分长尾span.而且过大的全量流量对于上报服务来说也有着一定的压力考验。 ## 基于头部的采样  基于头部的采样是现在主流分布式跟踪的框架进行采样的主要模式。在otlp当中就原生实现了采样的配置，并支持了一些原生的采样策略。 - ALWAYS_ON 总是产生 - ALWAYS_OFF 不产生 - ALWAYS_PARENT 信任父span的采样结果...
## 指标关联Trace ### exemplar机制 #### prometheus prometheus主要是采用 exemplars 的机制在 metrics 中带上额外的信息。通过metrics的接口可以同事暴露exemplar https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md#exemplars-1 ``` # 后面的内容就是exemplar # lable 采样值 采样时间 foo_bucket{le="0.1"} 8 # {} 0.054 foo_bucket{le="1"} 11 # {trace_id="KOO5S4vxi0o"} 0.67 foo_bucket{le="10"}...
**What would you like to be added**:  **Why is this needed**:
**What would you like to be added**: 修改ES集群的冷热标签配置后 采集项的还是老的冷热标签 需要手工更新一次采集项 **Why is this needed**:
## 日志自定义上报方案(Logs Trace) ### 阿里云 #### 日志上报 - 基于Kafka协议上报日志 https://help.aliyun.com/document_detail/112902.html?spm=a2c4g.11186623.6.816.21329557cV5cMr - 基于Syslog协议上报日志 https://help.aliyun.com/document_detail/112903.html?spm=a2c4g.11186623.6.817.626f175bMJTh5c - 基于SDK上报日志 ### 腾讯云 - HTTP-API上报日志 https://cloud.tencent.com/document/product/614/12445 ## 蓝鲸日志平台 ### 架构设计  ### 模块说明 - bk-log-receiver 实现接收日志协议格式包括...
**What would you like to be added**: **Why is this needed**:
**What would you like to be added**:  **Why is this needed**: