这是我参与「第五届青训营」伴学笔记创作活动的第 1 天
前言
在各类服务观测框架逐渐涌现的今天，使用哪个框架好像成了人们非常纠结的问题，这时 OpenTelemetry 出现了，OpenTelemetry 要解决的是对可观测性的大一统，它提供了一组 API 和 SDK 来标准化遥测数据的采集和传输，OpenTelemetry 并不想对所有的组件都进行重写，而是最大程度复用目前业界在各大领域常用工具，通过提供了一个安全，厂商中立的能用协议、组件，这样就可以按照需要形成 pipeline 将数据发往不同的后端。
OpenTelemetry
为何存在
微服务架构使开发人员能够更快地构建和发布软件，并具有更大的独立性，因为他们不再受制于与单体架构相关的复杂发布流程。随着这些现在分布式系统的扩展，开发人员越来越难以了解他们自己的服务如何依赖或影响其他服务，尤其是在部署之后或中断期间，速度和准确性至关重要。而这就是 OpenTelemetry 存在的意义。
功能是什么
为了使系统可观察，必须对其进行检测。也就是说，代码必须发出跟踪、指标和日志。然后必须将经过检测的数据发送到可观察性后端。有许多可观察性后端，从自托管开源工具（例如 Jaeger 和 Zipkin）到商业 SaaS 产品。过去，检测代码的方式会有所不同，因为每个可观察性后端都有自己的检测库和代理，用于向工具发送数据。这意味着没有用于将数据发送到可观察性后端的标准化数据格式。此外，如果一家公司选择切换 Observability 后端，这意味着他们将不得不重新检测他们的代码并配置新代理，以便能够将遥测数据发送到新选择的工具。
使用
我们可以通过 CloudWeGo 开源框架的中间件对其进行使用。
import (
...
"github.com/kitex-contrib/obs-opentelemetry/provider"
"github.com/kitex-contrib/obs-opentelemetry/tracing"
)
func main() {
serviceName := "echo"
p := provider.NewOpenTelemetryProvider(
provider.WithServiceName(serviceName),
provider.WithExportEndpoint("localhost:4317"),
provider.WithInsecure(),
)
defer p.Shutdown(context.Background())
svr := echo.NewServer(
new(EchoImpl),
server.WithSuite(tracing.NewServerSuite()),
// Please keep the same as provider.WithServiceName
server.WithServerBasicInfo(&rpcinfo.EndpointBasicInfo{ServiceName: serviceName}),
)
if err := svr.Run(); err != nil {
klog.Fatalf("server stopped with error:", err)
}
}
