feat: add opentelemetry provider

[houseme]

No description provided.

[gqcn]

@houseme 这样的包太耦合了不太好维护，因为trace和metric初始化的参数是不一样，并且后续可能还会有新增，如果都在provider包中对option重定义的话，后续维护成本会比较高。久而久之，你会发现这个provider其实后续会落后trace和metric很多。
如果是由业务开发者自己去封装蛮合适的，因为业务可以定制化初始化逻辑。但是作为基础框架来提供统一的封装反而不太好，这几个otel的组件有很多定制化的配置，不太容易在统一的组件中去做初始化。即便能做，也就是一个简单的脚手架，价值也不是很大。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@houseme Such a package is too coupled and difficult to maintain, because the initialization parameters of trace and metric are different, and there may be new additions in the future. If option is repeated in the provider package If defined, subsequent maintenance costs will be relatively high. Over time, you will find that this provider will actually lag behind trace and metric in the future.
It is quite appropriate if the business developer encapsulates it himself, because the business can customize the initialization logic. However, as a basic framework to provide unified encapsulation, it is not too high. These otel components have many customized configurations, and it is not easy to initialize them in unified components. Even if it can be done, it will be a simple scaffolding and not of great value.

[houseme]

@houseme 这样的包太耦合了不太好维护，因为trace和metric初始化的参数是不一样，并且后续可能还会有新增，如果都在provider包中对option重定义的话，后续维护成本会比较高。久而久之，你会发现这个provider其实后续会落后trace和metric很多。 如果是由业务开发者自己去封装蛮合适的，因为业务可以定制化初始化逻辑。但是作为基础框架来提供统一的封装反而不太好，这几个otel的组件有很多定制化的配置，不太容易在统一的组件中去做初始化。即便能做，也就是一个简单的脚手架，价值也不是很大。

这个 exporters 不是 prometheus ,是 [OTLP](https://github.com/open-telemetry/opentelemetry-go/blob/main/exporters/otlp)

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

@houseme Such a package is too coupled and not easy to maintain, because the initialization parameters of trace and metric are different, and there may be new additions in the future. If both option is added in the provider package If redefined, subsequent maintenance costs will be higher. Over time, you will find that this provider will actually lag behind trace and metric a lot in the future. It is quite appropriate if the business developer encapsulates it himself, because the business can customize the initialization logic. However, it is not very good as a basic framework to provide unified encapsulation. These otel components have many customized configurations, and it is not easy to initialize them in unified components. Even if it can be done, it is just a simple scaffolding and its value is not very great.

This exporters is not prometheus, it is [OTLP](https://github.com/open-telemetry/opentelemetry-go/blob/main/exporters/otlp)

[gqcn]

@houseme 这样的包太耦合了不太好维护，因为trace和metric初始化的参数是不一样，并且后续可能还会有新增，如果都在provider包中对option重定义的话，后续维护成本会比较高。久而久之，你会发现这个provider其实后续会落后trace和metric很多。 如果是由业务开发者自己去封装蛮合适的，因为业务可以定制化初始化逻辑。但是作为基础框架来提供统一的封装反而不太好，这几个otel的组件有很多定制化的配置，不太容易在统一的组件中去做初始化。即便能做，也就是一个简单的脚手架，价值也不是很大。

这个 exporters 不是 prometheus ,是 [OTLP](https://github.com/open-telemetry/opentelemetry-go/blob/main/exporters/otlp)

我理解当前开发者在使用时已经有provider提供：

• metrics的provider已经有contrib/metric/otelmetric包。
• trace的provider已经有contrib/trace/otlphttp和contrib/trace/otlpgrpc包。

[houseme]

@houseme 这样的包太耦合了不太好维护，因为trace和metric初始化的参数是不一样，并且后续可能还会有新增，如果都在provider包中对option重定义的话，后续维护成本会比较高。久而久之，你会发现这个provider其实后续会落后trace和metric很多。 如果是由业务开发者自己去封装蛮合适的，因为业务可以定制化初始化逻辑。但是作为基础框架来提供统一的封装反而不太好，这几个otel的组件有很多定制化的配置，不太容易在统一的组件中去做初始化。即便能做，也就是一个简单的脚手架，价值也不是很大。

这个 exporters 不是 prometheus ,是 [OTLP](https://github.com/open-telemetry/opentelemetry-go/blob/main/exporters/otlp)

我理解当前开发者在使用时已经有provider提供：

• metrics的provider已经有contrib/metric/otelmetric包。
• trace的provider已经有contrib/trace/otlphttp和contrib/trace/otlpgrpc包。

如果选择 otel 的就可以一次性初始化，可以设置不同的header传入参数