聊聊云原生转型之前实现可观察性的必要性

2023-03-18 15:53:05 浏览数 (1)

程序员的世界非常魔幻,有时不明白老板们在想什么,突发奇想说公司想做云原生转型,然而计划的第一件事是从 Jenkins 流水线转移到 Gitlab CI。碰到什么困难,老板们开始怀疑技术上存在问题,试图通过技术解决一切问题,而不考虑公司组织架构是否需要变革。

要做云原生转型仅仅靠技术就够了么?有时仅仅只是创造了一堆工作要做,可能不会带来任何收益,反而会增加工作量。

我不知道你公司是提供什么业务服务的,也不知道公司目前的组织和技术架构是什么样子,所以也无法为你提供云原生转型方法。如果单纯从云原生转型来说,云原生对于公司没有好坏之分,只能说是否适合当前组织后续发展。

所以各位老板们,无论做云原生转型,还是做组织架构调整,还是做技术迭代升级,只要你还准备继续迭代和升级,首先你需要了解你的系统到底发生了什么;要想了解公司的业务发展就要从监控和可观察性开始。

1、为什么要从可观察性开始?

首先,如果你不理解也不能清楚地看到你的系统发生了什么,那么做一些云原生转型也是徒劳无功的。

为什么这样说呢?(从某种意义上来说,云原生是一种提效手段,所以找到组织效率低下的原因,然后再进行转型和升级)

从宏观上来说,如果你的产品不能为公司或者组织带来收益,然后进行技术转型,可能依然如此。比如无法带来的收益的原因可能是销售或者用户侧出现问题。

从微观上来说,公司的基础架构和用户数量是否呈爆发式增长,如果在可控范围内或者目前在很好的运转。换一种说法,如果找不到现在效率低下的原因,贸然进行云原生转型可能会徒增工作量。

看谷歌的Site Reliability Engineering这本书,不需要看全书,看前三章就可以了。它从谈论接受风险、SLO、然后是监控开始。所有这些都与监控和可观察性有关。

SRE 书籍为您提供了使您的产品可靠的需求层次结构:

看看这个金字塔。一切靠什么?

监控。

可靠的生产系统需要有良好的监控。如果没有监控,您甚至无法判断该服务是否正常工作,更不用提用户体验是否良好,用户在使用过程是否出现问题。

监控靠什么?

可观察性。

可观察性是关于将您的黑盒应用程序转变为开放的、经过检测的微服务,这使您能够快速检查和了解正在发生的事情,它能够立即观察系统的运行情况。

老实说,在向云原生过渡的过程中,弄清楚实现可观察性是重中之重。

如何做到可观察性?

规范化编程语言监控类库

编写的 Java 将与 PHP 或 Go 有所不同。这在很大程度上也取决于生态系统。您需要拥有构建良好的框架、库和工具。其中一些更难检测和操作。通过标准化的框架思考到底我们的系统需要什么监控?

  • 一个典型的应用程序需要多长时间才能启动?
  • 在没有任何负载的情况下,应用程序需要多少内存/CPU?
  • 它可以处理的最大负载是多少?
  • 资源如何看待最大负载?
  • 当负载超过系统资源时它的行为如何?
  • 每个请求的延迟是多少?

这些是您需要快速了解的一些关键问题。为此,您应该有一个现成的仪表板,只需单击一下即可,就可以查看你认为必不可少的指标,在这个过程中并不是一蹴而就的,需要在使用过程中,不断优化和改进监控面板。

通常,不同编程语言处理内存和CPU存在一定的多差异。Go 提供轻量级线程和垃圾回收。Python 有一个全局解释器锁。Java 使用 JVM 虚拟化了一切。PHP 依靠网络服务器来完成大部分工作。这就可能需要根据编程语言的特性产生不同的监控面板:

  • 内存泄漏的关键指标是什么?
  • 它有垃圾收集吗?
  • 并发性如何在该语言中表现如何?
  • 应用程序线程或 goroutine 之一是否泄漏?

您应该能够通过监控面板相对容易的识别 GC 问题或内存泄漏。

对最重要的服务指标发出警报

必须跟踪面向客户的应用程序指标!您应该遵循几种模式。一个示例是RED 方法,跟踪请求速率(即每秒 HTTP 请求数)、错误率(每秒 500 次响应)和持续时间。对于持续时间,您通常希望第 50 个百分位小于 X 毫秒,第 99 个百分位小于 Y 毫秒。您需要确保您拥有数据库/队列和其他有状态服务的最关键指标,不至于数据库已经极度不稳定而没有人注意到。

另一个例子是谷歌在他们的 SRE 书中谈到了四个黄金信号。

  • 延迟-服务响应请求所需的时间。
  • 流量-您的服务当前正在处理的请求数。
  • 错误-请求失败的比率。
  • 饱和度——您的服务可以在不中断的情况下处理多少请求。

这里的关键是对有问题的指标发出告警。这些指标通常可以让您快速了解客户何时遇到问题。您还可以通过确定错误预算并进行 SRE 式警报。确保 oncall 人员收到警报,并第一时间进行问题的发现和解决。

通过告警你可以在你的客户感知到问题之前,提前发现和解决问题。

添加一些黑盒监控

获取可用的服务指标有时可能很棘手。例如,您正在托管一个 FTP 服务器。大多数开源服务器都是在 Prometheus 出现之前编写的,因此这些开源服务器不会公开任何指标。监控这种情况最直接的方法是使用黑盒监控方法。

你只需要在重要的业务流程中加入监控指标收集,比如捕获到异常或者出现错误信息。这非常重要,因为有时白盒指标根本不起作用。一个例子是服务过载或陷入死循环。外部监控指标无法感知到异常数据存在。

结论

通过监控指标可以清晰看到用户流量大小,请求延迟状况,是否需要性能优化,当前架构是否可以满足用户增长的需求,资源占用如何,什么时候需要扩容。

希望到现在为止,在开始云原生之旅的开始之前,首先保证系统运行指标可视化,保证系统的可观察性,一切从监控开始。

0 人点赞