服务观测框架 OpenTelemetry | 青训营笔记

270 阅读2分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 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)
    } 	
}

参考

github.com/kitex-contr…

www.jianshu.com/p/34f471c77…

opentelemetry.io/docs/