可观测性到底是什么？为什么说可观测性大趋势不可逆？

CodeCodeBond
102 阅读4分钟

GGBond📢

大家好哇我是 CocoBond啊

最近和可观测性生态打交道比较多，所以记录一下自己的可观测性生态的一些看法思考🥳

可观测性是什么？🤔

可观测性生态包括三大支柱组成，Log、Trace、Metrics。

Log 提供细节，Trace 提供上下文，Metrics 提供趋势。

三者结合可覆盖“从宏观到微观”的分析场景。

一般来说： 在这里插入图片描述 我们来剖析一下每个支柱的基本数据结构，以及他们是如何扮演好自己角色的 🎭：

  • Log（日志）：离散事件记录，描述单点运行时的具体行为（如错误日志、访问日志）。
  • Trace（追踪）：分布式系统中请求的端到端调用链路追踪（如链路耗时、跨服务依赖）。
    • Trace ID （unique 一条链路一个）
    • Span
      • Span ID （链路内unique）
      • Parent span ID
      • Start time
      • End time
      • Operation name
      • ...
    • Service
    • context更多
    • ...
  • Metrics（指标）：根据时间序列聚合的系统性能、资源等指标数据（如 CPU 使用率、吞吐量、qps、延迟）。
    • Name
    • Value
    • Type：折线、直方、
    • ...

三者之间的可转化关系为： 在这里插入图片描述

这意味着可以把log的数据变成trace、metrics，trace可以变成log、metrics，需要注意的是，metrics属于已经聚合过的一些数据，不可能转化为trace链路的数据，但是可以根据规则转化为log，比如一些指标异常告警的场景。 通过他们的相互可转化关系，可以感觉到他们的关系由宏观—>微观，界限是有些模糊的，

为了更直观感受这三大支柱是什么，再次列举一些它们常见的结构包含哪些：

  • Log（日志）：
    • Timestamp
    • Level： info、warn、error..
    • Source： Service name、file path..
    • Msg
    • ... 比如SpringBoot后端服务中的INFO、WARN、ERROR... 在这里插入图片描述 在这里插入图片描述 在这里插入图片描述
  • Trace（追踪）：
    • Trace ID
    • Span
      • Span ID
      • Parent span ID
      • Start time
      • End time
      • Operation name
      • ...
    • Service
    • context更多
    • ...
  • Metrics（指标）：
    • Name
    • Value
    • Type：折线、直方、
    • ...

🪄在可观测性生态中，我们经常会遇到的中间件工具数据库等有这些： Visualization: Kibana、Grafana、Jaeger(Trace)

  1. Log
    • Logstash,Filebeat Fluentbit Vector ilogtail
    • ES
  2. Trace
    • OpenTelemetry / Skywalking / Jaeger
  3. Metrics
    • DB: OpenGemini / Promethous / InfluxDB / TimescaleDB/ VectoryMetrics / TDengine

在早期三大生态的标准规范分别如下图所示： 在这里插入图片描述 目前来看，OpenTelemetry 是基本上是统一了trace、log、metrics的协议规范标准，并蓬勃发展中。能做到零代码侵入自动代理，和自定义数据格式上下游传导等

OpenTelemetry社区也相当活跃，里面有CNCF和Linux基金会做的关于OpenTelemetry实验课程也是相当优秀，非常适合新手入门学习 OpenTelemetry 入门-

​为什么我们需要可观测性？🤔

👀来看看Deepseek🐳 的回答👀

现代系统黑盒性&故障定位与根因分析的复杂性： 现代系统复杂度提升（如微服务、云原生）推动了对可观测性的依赖。微服务架构将单一应用拆分为数百甚至上千个独立服务，容器化和动态编排（如 Kubernetes）进一步加剧了组件间的动态变化。微服务间依赖关系复杂，单个请求可能涉及多个服务、数据库和中间件。若仅依赖传统监控工具（如日志聚合），需人工关联不同服务的日志，效率低下。

说说自己的看法🤔：

按照现在的时代技术发展趋势来看，软件架构越来越复杂，各种各样的微服务、边缘计算等，逐步进入超级大数据时代。比如像一个微服务架构的软件，像支付宝，一次支付的请求可能涉及十多个服务模块：登录鉴权、支付、订单等等。

不仅是需要监控的数据量规模、复杂性上来了，还有对监控系统要求也上来了，监控系统逐渐由一个运维工具变成一个基础设施，可观测性需要更进一步，不局限于以前告诉你系统cpu异常告警，现在需要可观测性能找到为什么出问题和哪里出问题，通过log、trace、metrics的联动分析，快速定位，分析瓶颈。

可观测性未来发展方向及趋势 📖

尽管Log、Trace、Metrics仍是基石，但可观测性正朝着两个方向突破：

(开头提到的)事件驱动范式：通过Wide Events将日志、指标、链路数据融合为统一事件流（如AWS CloudWatch EventBridge），利用流处理技术实现实时根因分析；

业务可观测性：将技术数据（如API延迟）与业务指标（如购物车放弃率）关联，通过Grafana等工具实现"从服务器到营收"的全景洞察。

最近貌似AIops也很火，感觉可观测性系统也可以朝着AIops的方向去进化，这样的话新可观测系统不仅能透视黑盒、预测风险、连接技术与业务的智能神经系统，还能做到像人类一样处理基础预定义的一些异常场景，实现智能告警、管控一体化，减轻运维同学压力 🤥

有段时间没有更新了，有种一直很忙但也不知道忙了什么的感觉哈哈🙄

avatar
文章
阅读
粉丝