前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Opentelemetry 调研实践一(可观测性到底在说什么)

Opentelemetry 调研实践一(可观测性到底在说什么)

作者头像
米开朗基杨
发布2021-10-27 15:15:28
1.4K0
发布2021-10-27 15:15:28
举报

可观测性(Observability)并不是一个新词,而在几十年前被广泛地用于控制理论,用它来描述和理解⾃我调节系统。随着容器技术、微服务、⽆服务器迅速流行,使得系统间的访问越来越复杂,在云上、本地或两者上可能会运⾏数千个进程, 使用传统的监控技术和⼯具很难跟踪这些分布式架构中的通信路径和相互依赖关系。系统内部的可见性就变得非常重要。

那可观测性到底在说什么呢?

思考

  1. 你的应用真的是可观测的吗?
  2. 日志系统只是用于查询日志的吗,有没有可能日志系统与监控系统是联动的?
  3. 可以很容易统计一条请求的总耗时,但如何统计具体某个函数的执行时间、该函数调用次数?

上述 3 个问题如果你都能出”Yes”回答,那么作者建议直接滑走不用看下文。

如果你脱口而出,不就是日志平台跟监控系统能解决吗?

对,其实也不对

好,首先来说明一下可观测性跟监控系统的一些区别

问题域

可观测性跟监控系统确实很像,可观测性跟监控系统本质上是一样的,都是在解决一个问题,:度量你的基础设施、平台和应用程序,以了解它是如何运行。

但两者的问题域却完全不同,监控告诉我们系统的哪些部分是工作的,可观测性告诉我们那里为什么不工作了.

度量,是个程度可深可浅的词,比如回到问题一: 你的应用是可观测的吗,很多人会给出肯定的回答,在某些人的理解中,不就是监控应用的状态吗?对于 k8s 应用来讲,prometheus 就可以开箱即用地监控它,没错,状态是能够被监控的,通过监控系统我们可以知道某个时刻it works

但是这个应用是可观测的吗?当然不是,因它在出现问题的时候,通过监控系统可能没办法判断它在哪个函数中 crash 了

如果要知道它哪里出了问题,那么就需要在应用内部实现可见性,通过埋点或者是字节码注入的方式,让应用暴露它的业务、性能指标,比如函数的时延、调用次数、调用错误等,借助这些指标再结合旁路分析系统就可以很清晰地展现应用的全貌。

这就属于可观测性

三板斧

logging、trace、metrics 是实现可观测性的三板斧,每一个都有很多的解决方案可选,

Logging 中使用较多的有 EFK、loki

Trace 中有 Jaeger、Tempo

Metrics 中有 Prometheus,Netdata

通过这些工具收集的数据统称为遥测数据

这些工具基本开箱即用的特性,作者相信给很多企业带来了便利性。

想用好这三个工具业界还是有一些指导思想的,对于 logging 跟 metrics 很多人会相对熟悉一些,作者在这里想简单说一说 trace,trace 一般为全链路追踪,表示请求通过分布式系统的端到端的过程, trace 有两个很重要的属性:

  1. TraceID: 一次请求中的所有路径都会共用一个唯一的 TraceID,这个 TraceID 一般由初始节点产生,然后传递到所有节点
  2. SpanID: TraceID 只能够串起所有节点,但节点之间的调用顺序需要由 SpanID 来产生

由于篇幅有限,trace 将做为后续文章介绍的重点,不在这里展开

为什么

为什么要实现可观测性呢?

可能有些人会提出: 我没有做任何可观测性方面的工作,系统也一直work fine

确实,在小公司或者系统不那么复杂的情况下,落地可观测性是有成本的,毕竟需要花人力物力去搭建那么些系统同时需要有可运维能力

但是如果业务链路足够长、逻辑足够复杂,长远来看,可观测性的落地是非常有必要的,有以下几点原因:

  1. 现在到处吹捧云原生,从纯技术角度上来说,实现可观测性是趋势,也是技术追求
  2. 整个架构的可观测性对开发⼈员和运维⼯程师更友好、定位问题更快
  3. 可以更好地提供业务属性数据

痛苦

同时,也会发现一个很痛苦的问题:这些开源项目大多是孤立的,之间没有多大的关联性,大公司可能有能力研发自己的可观测平台实现大一统,对于小公司来说,需要在多个平台之前进行切换,如果有架构调整,那切换的成本相信是巨大的。

观测性能否做到一统呢?

这也其实也是【思考】中第 2 个问题,简单地说,能不能通过日志系统中的关键字,跳转到 trace 系统中看这条日志所处的请求的所有链路。

答案是肯定的,grafana 就做的非常不错,统一了 agent,从 logging、trace、metrics 三个纬度进行采集,loki 实现了日志的存储,新贵 tempo 实现 trace 的追踪,metrics 则原生支持 prometheus,grafana 则提供了统一的可视化界面,从 agent 到 view 集成度非常高。

但 grafana 不是作者要介绍的主角,client 端的实现才是作者要深入调研实践的主角,这就是 CNCF 牵头开源的新项目: OpenTelemetry

总结一下,以上主要介绍了可观性测是什么以及为什么需要可观测性,但没有回答一个很重要的问题:如何实现可观测性,这其实是接下来要分享的内容,会详细介绍借用 OpenTelemetry 如何实现可观测性

参考文章

  • https://cloud.tencent.com/developer/article/1801643[1]
  • https://opentelemetry.io[2]
  • https://grafana.com[3]

引用链接

[1]

https://cloud.tencent.com/developer/article/1801643: https://cloud.tencent.com/developer/article/1801643

[2]

https://opentelemetry.io: https://opentelemetry.io

[3]

https://grafana.com: https://grafana.com

原文链接:https://izsk.me/2021/10/19/OpenTelemetry-what-is-observability/

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-10-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 云原生实验室 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 思考
  • 问题域
  • 三板斧
  • 为什么
  • 痛苦
  • 参考文章
    • 引用链接
    相关产品与服务
    日志服务
    日志服务(Cloud Log Service,CLS)是腾讯云提供的一站式日志服务平台,提供了从日志采集、日志存储到日志检索,图表分析、监控告警、日志投递等多项服务,协助用户通过日志来解决业务运维、服务监控、日志审计等场景问题。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档