关于运维:可观测性三支柱远不止此

26次阅读

共计 2400 个字符,预计需要花费 6 分钟才能阅读完成。

日志,指标和分布式链路追踪这三个可观测性的传统支柱,曾经是过期的,过于关注数据采集和底层数据格式,而不去关注后果(咱们建设可观测性的初心和指标),这个做法切实是滑天下之大稽。by Martin Mao

Gartner 把“可观测性”定义为“监控”的微小变革,可观测性提供了数字化业务利用、翻新速度、客户体验晋升方面的洞察能力。现在,DevOps 静止和云原生架构使得企业数字化业务变得更具竞争力,这须要更牛逼的可观测性体系的反对。

在 DevOps 呈现之前,研发工程师很少须要思考如何运维他们构建的零碎。当初,研发工程师须要思考构建更易于观测的零碎。为了更好的了解可观测性对后果的影响,工程师应该思考以下三个关键问题:

  • 1. 当零碎出故障时,如何能力让我尽快收到告诉?是在用户 / 客户体验受损之前吗?
  • 2. 如何能力简略、疾速地揪出故障点,圈定影响范畴?
  • 3. 如何能力找到间接起因并疾速止损?

无论应用什么采集办法和工具,可观测性体系最应该着重建设的,就是答复以上三个问题的能力。

可观测性不是什么

现在,有很多人将可观测性定义为一组数据类型的汇合——即三个支柱:日志、指标和分布式链路追踪。对于落地可观测性而言,这种孤立的办法过于关注数据采集和底层数据格式,反而疏忽了最终后果(咱们建设可观测性的初心和指标)。

简略的采集零碎中这三种数据并不能保障有更好的后果。反而,很多公司发现:可观测性数据量和这些数据衍生的价值之间关联甚微,并非可观测性数据量越大产生的价值就越大。

可观测性的 3 个阶段

咱们不是第一个对三支柱提出异议的人。像 Charity Majors(可观测性具备多方面定义) 和 Ben Sigelman(揭穿“可观测性的三支柱”神话) 所提出的大部分批评咱们也是认同的。咱们开发了一种落地可观测性的新办法,重视后果而非重视输出,代替可观测性的三支柱,咱们称之为“三阶段”办法。“三阶段”重点关注如何实现踊跃的可观测性后果,以及如何让团队一步一步达成可观测性指标。

日志,指标和分布式链路追踪这三个可观测性的传统支柱,曾经是过期的,过于关注数据采集和底层数据格式,而不去关注后果(咱们建设可观测性的初心和指标)。

每个阶段的重点都是为了尽快地升高对客户的影响或修复故障(即:止损)。止损是援救客户体验和复原服务 Service Level 的动作。在每个阶段,工程师都在寻找足够的信息来止损,即便他们尚未定位到根因。

译者注:做过 SRE 的兄弟必定分明,大部分状况下,『止损』只须要晓得间接起因就够了,不须要晓得根因,根因能够在复盘阶段再去梳理。举个例子,某个故障是变更引起的,变更自身就是间接起因,止损伎俩就是回滚,根本原因可能是这次变更引入的代码 Bug,但具体是什么 Bug 在止损阶段不须要晓得。

第一阶段:定故障

晓得故障正在产生,有时就能够止损了(不须要更多信息)。比方,你降级了某个服务,而后,这个服务告警了,想都不必想,回滚这个变更就是最快的止损伎俩,不须要先去确认故障影响面、故障根因。变更是万恶之源,生产事变有一大半都是变更引起的,当你在做变更的时候,时刻把握服务的健康状况就异样要害。

胜利的要害:

  • 疾速报警:缩短问题产生和发出通知之间的工夫。
  • 将告诉范畴限定在须要采取行动的团队内:从一开始就限定问题的范畴,并将其指派给相干的团队。
  • 进步降噪比:确保每一个警报都有对应的操作预案。
  • 自动化告警配置:自动化或模板化的告警配置能够帮忙工程师无需投入微小精力来实现简单配置就能够收到警报。

工具和数据:

  • 告警
  • 指标(原生指标以及从日志和链路追踪生成的指标)

第二阶段:定边界

理解故障范畴有助于止损。例如,如果你确认只有一个实验组的客户影响,则敞开该试验个性可能就会解决问题。

为了帮忙工程师做故障定界,须要把告警疾速置于上下文环境中来剖析,理解有多少客户受影响、有多少零碎受影响,以及影响水平如何。好的可观测性零碎,以数据驱动工程师的排查过程,将焦点放在场景化数据上以诊断故障。

胜利的要害:

  • 上下文信息仪表盘:告警间接链到仪表盘,显示告警相干的原始数据,以及相干的上下文数据(译者注:只链到仪表盘其实不够,还应该链到相干的日志、trace、事件等)。
  • 多维度的数据分析:容许工程师依据不同的维度对数据进行剖析,以进一步放大问题范畴。
  • 充分利用现有埋点数据:假如每次都有完满的数据埋点是不可能的,所以充分利用既有的数据十分要害,但须要尽可能依照场景化的形式来串联数据。

工具和数据:

  • 仪表盘
  • 指标
  • 日志

第三阶段:定起因

想要剖析问题的起因,就须要找到相干服务的 owner 一起配合,然而服务的依赖关系盘根错节,想要找到服务依赖链路上的所有 owner 并不容易。

好的可观测性实际,能够给工程师一个更直观的视角,揪出那些引起指标异样的罪魁祸首。另外,它也提供了修复底层问题的洞见,以防止事变再次发生。

胜利的要害:

  • 易于了解服务依赖拓扑关系:对于以后正在故障的服务,疾速圈定其上下游依赖。
  • 在不同的工具和数据之间串联跳转的能力:对于简单的故障,您须要在日志、链路、指标之间重复跳转,现实的状况是在一个繁多的工具中实现。
  • 确定根因的工夫:有时候无奈防止在故障期间做根因剖析,而在这些状况下,通过在告警告诉或仪表板上显示出可能的故障起因,能够缩小确定根因的工夫。

工具和数据:

  • 链路追踪
  • 日志
  • 指标
  • 仪表盘

论断

优良的可观测性能够带来竞争劣势、世界一流的客户体验、更快的翻新和研发人员的幸福感。然而,仅仅关注于输出和数据(三支柱),组织是无奈做到优良的可观测性的。通过专一于本文提到的『三阶段』以及面向后果的形式,团队就无望落地优良的可观测性实际!

本文翻译自:https://thenewstack.io/beyond-the-3-pillars-of-observability/,国内来看,Martin Mao 的这个理念和快猫的理念一模一样, 如果您也须要这类面向后果的旧式可观测性零碎,能够理解一下快猫的产品

正文完
 0