监控监视分布式系统和微服务技术

作者 : IT 大叔 本文共3149个字,预计阅读时间需要8分钟 发布时间: 2020-10-20

监视是任何软件开发生命周期(SLDC)的关键部分,并且随着微服务架构和DevOps实践的兴起,监视变得越来越重要和复杂。要了解如何监视微服务,我们必须退后一步以返回完整的旧版应用程序以及我们过去如何对其进行监视。
三棱锥监测理念

在整体环境中,我们过去常常获得一些指标,这些指标告诉我们我们的应用程序状态通常是如何从基础结构开始的,例如,托管应用程序的物理硬件:
服务器是否启动?
我的数据库启动了吗?
Web服务器可以与数据库对话吗?

然后,我们进行下一步以自行查询我们的应用程序,并提出另一个问题:
我的应用程序进程正在运行吗?

然后我们再上一层,监控功能和业务能力,从而引发不同的问题,例如:用户可以下订单吗?

过去的三级基础架构,应用程序和业务功能称为“监视区域”

监控监视分布式系统和微服务技术插图

让我们转到不同的角度,并稍微改变一下问题,
让我们通过询问
我的服务器是否启动来检查应用程序的运行状况?
并通过询问
是否有高CPU来检查应用程序性能?
并询问
我是否有足够的磁盘空间来检查容量?
通过回答这3个问题,我获得了有关系统的运行状况,性能和容量的另一个指标,这称为监控问题。

并且“监视区域”和“监视问题”之间存在许多关系,这取决于我们提出的一个问题的组合:例如
,我的服务器是否启动?有高CPU吗?我有足够的磁盘空间吗?
在这里,我的目标是基础架构的运行状况,性能和容量,
如果我问:
我的应用程序是否会生成异常?系统如何快速处理消息?我可以处理月末批处理工作吗?
在这里,我以应用程序层的运行状况,性能和容量为目标,如果我再次更改问题并询问:
用户可以访问结帐购物车吗?我们是否在满足SLA?增加另一个客户有什么影响?
我们针对业务功能层的运行状况,性能和容量。

监控监视分布式系统和微服务技术插图(2)

还有第三个许可证,我想向您介绍这个交互类型,它显示了我如何监视系统

  • 被动监视:您可以在其中访问系统仪表板并查看当前和过去的值
  • 反应式监视:监视系统会在发生某种情况时向我发出警报,例如当队列长度达到50时系统发送电子邮件
  • 主动监控:监控系统会自动采取措施修复系统,例如队列长度达到50时自动放大另一个实例来解决问题

监控监视分布式系统和微服务技术插图(4)

因此,这3个监控金字塔之间的关系是多对多的,所以如果我在本文开头问第3个问题:
我的服务器是否启动?
我的数据库启动了吗?
Web服务器可以与数据库对话吗?
然后我会在某个时间点监视基础结构的运行状况,这当然是被动监视。

因此,每当您决定要监控的指标时,请牢记您要监控的区域是什么,您要监控哪些方面以获取有关信息和交互作用

这三个金字塔是思考您正在监视的内容并询问是对您有用的整体系统还是分布式系统的一种方式。

当我们处理分布式系统时会发生什么?
分布式系统的问题是从单点开始的,我们剥离了与消息传递协议进行通信的功能,并且我们将剥离其他几个领域,而不仅仅是服务器,我们可以看到它们中每个都有自己的数据库除了微服务的动态性质之外,还有更多基础架构需要担心。如果我扩展我的一项服务,您会得到4个实例,它们全部消耗一个输入队列,或者也可能是分布式队列,那么监视队列长度是否有意义。这有点棘手,可能是,您应该监视它,可能不是。当您增加可以运行的系统的动态特性时,它会变得更加复杂,这将是我们可以收集的许多信息,而我们无所不能。

让我们看一下分布式系统的组件,看看如何监控它。

队列长度是每个代理技术或队列技术都有某种提供队列长度的方法的最简单度量标准,因此该度量标准告诉我们

  • 队列长度是未完成工作的指标
  • 高队列长度并不一定意味着存在问题,因此,如果队列长高但稳定或减少,或者有一些峰值可能是好的,但是如果每次都在增加,则有问题

因此,对于我们的金字塔,我们监视基础架构性能,但这并不能为我们提供清晰的见解,因此让我们在此处查找另一个重要指标。
消息处理时间,因此我们应该获得从消息开始到队列结束为止的时间,无论它是通过FTP上载文件还是在数据库上执行一些查询然后完成并将其从队列中删除

  • 处理时间是成功处理消息所花费的时间
  • 处理时间不包括错误处理时间
  • 这取决于队列等待时间,在这里成功完成该过程很重要,因为如果在处理过程中抛出的错误意味着不应该消除该错误,则可以将其发送到另一个Pod,以使其稳定或减少或者有一些峰值可以再次处理它。但是如果每次都在增加,那是个问题

监控监视分布式系统和微服务技术插图(6)

这导致我们有了一个新概念,那就是关键时刻。从将我们的消息提升到已处理的队列的最前面然后停止的时间是计时器,因此,如果存在网络延迟,或者甚至将处理消息的实例崩溃并重新启动,并且有很多重试来传递消息,这很关键时间停止不,它实际上仍在计数。从中我们可以得到一个描述关键时间的公式。

关键时间=排队时间+处理时间+重试时间+网络等待时间

并且与其他指标非常相似(如果指标稳定或正在下降,或者有一些峰值可能很好,但如果每次都在增加,则有问题)

让我们放在一起

Each of these metrics represent a part of the puzzle.
Looking at them from endpoint’s perspective not per message.
Look at them together gives great insight into your system.

让我们展示一些案例并进行分析

情况1:

监控监视分布式系统和微服务技术插图(8)

我们这里有什么?稳定的临界时间,尖峰的处理时间和稳定的队列长度。这告诉我们关于系统的什么?
系统有点跟进所有传入的消息,我们也在处理它们,因为队列长度没有增加,但是为什么处理时间不稳定?当处理程序收到它锁定的消息直到更新某些资源时,可能有很多原因导致跳来跳去,可能是资源争用,或者可能存在锁定机制,直到该端点处理的某些消息也很快其他信息则没有,您可以使用该信息将慢速信息隔离到其端点中,并独立扩展新端点。

情况2:

监控监视分布式系统和微服务技术插图(10)

在这里,我们有高临界时间,高处理时间和中等长度的队列,但是一切都很稳定。这告诉我们什么?
系统正在满足容量需求,但我们已处于极限,因此只要任何流量高峰(队列长度是天空火箭),关键时间也将达到极限。因此,这可能是扩展这些资源的良好指示。

情况3:

监控监视分布式系统和微服务技术插图(12)

在这里,我们有高临界时间,低处理时间和低队列长度。这是什么意思?
可能是网络存在问题,因为如果您记住关键时间的等式包括网络延迟时间,那么在处理邮件时可能还会重试很多,因此我们仅对成功处理的邮件的处理时间进行衡量,因此问题才是连通性或重试。
那么,如果监视分布式系统,您的通信故障如何?
实际上,如果您监视分布式系统是我进行健康检查的简便方法,并且您的服务是否以200个状态答复,则表示状态已启动,但是通常使用代理完成与分布式系统的通信,并且当实例向代理发送消息时,它不知道是否邮件到达目的地或不是最简单的选择这里是当邮件到达目的地时,已读回执将被发回。这是个好主意吗?这不是为什么吗?我们创建了将已解耦的系统转换为req / res system :(,并且我们将通过该系统发送的消息加倍。
这里的解决方案是对等连接,告诉我们端点是否实际上正在处理来自另一个端点的消息。

使用什么工具?
我们有一堆工具可以为我们收集指标,而splunk,kibana,D3和Grafana均适合监控。

我们将如何收集我们发送的所有这些信息?
如果我们谈论关键时间或处理时间,则它将是每条消息度量标准,当我们发送一条消息时,该消息将具有与其相关的处理时间和关键时间。
您可能会每隔一分钟或每五分钟进行一次队列长度和连接性检查

监控监视分布式系统和微服务技术插图(14)

我们如何存储呢?
一个好的存储模式是:度量标准类型,消息类型,时间戳和值。但这是一种非常昂贵的指标存储方式,可以通过多种技术来实现,但这超出了本教程的范围。

我们如何显示指标?
我们可以使用ELK堆栈来做到这一点,这将是合适的用例。

结论:

监视分布式系统不是一个容易的过程,它与系统的动态程度成正比,但与理解监视的原理以及选择有助于分析系统并保持其健康的正确度量标准成正比:)

免责声明:
1. 本站资源转自互联网,源码资源分享仅供交流学习,下载后切勿用于商业用途,否则开发者追究责任与本站无关!
2. 本站使用「署名 4.0 国际」创作协议,可自由转载、引用,但需署名原版权作者且注明文章出处
3. 未登录无法下载,登录使用金币下载所有资源。
IT小站 » 监控监视分布式系统和微服务技术

常见问题FAQ

没有金币/金币不足 怎么办?
本站已开通每日签到送金币,每日签到赠送五枚金币,金币可累积。
所有资源普通会员都能下载吗?
本站所有资源普通会员都可以下载,需要消耗金币下载的白金会员资源,通过每日签到,即可获取免费金币,金币可累积使用。

发表评论