微服务故障排除方面的最佳实践

作者:Brendan Creane 编译:沈建苗

人们听到“微服务”时,常常想到Kubernetes,这是一种声明式容器编排系统。由于具有声明性,Kubernetes将微服务视作实体,这在故障排除方面带来了一些难题。不妨看看为什么在Kubernetes环境下为微服务排除故障可能具有挑战性,以及一些相应的最佳实践。

想了解为什么为微服务排除故障可能具有挑战性,不妨看一个例子。如果您在Kubernetes中有一个应用程序,就可以将它部署为pod,利用Kubernetes对其进行扩展。该实体是您可以监控的pod。若使用微服务,您不应该监控pod;相反,应该监控服务。所以您可能拥有整体式工作负载(部署为pod的单个容器),并对其进行监控,但如果您的服务由几个不同的pod组成,就需要了解这些pod之间的相互关系,才能明白服务是如何运作的。如果不这么做,您认为的事件可能不是真正的事件(即可能对服务的运作并不重要)。

说到监控微服务,您需要在服务层面、而不是在pod层面进行监控。如果您尝试在pod层面进行监控,将与编排系统发生冲突,并且可能出岔子。我承认,“您不应该监控pod”是大胆的声明,但我认为如果您这么做,大多数情况下会出岔子。

为微服务排除故障时常见问题的根源

为微服务排除故障时,网络、基础架构和应用程序等问题都很常见。

网络

网络层面的问题最难调试。如果问题出在网络上,您需要查看套接字层统计信息。底层网络拥有将A点连接到B点的套接字,因此您需要在网络层面查看往返时间,看看数据包是否在传输、是否存在路由问题等。

基础架构

pod重新启动时,基础架构问题会显露出来(Kubernetes中的崩溃循环)。发生这种情况的原因有很多。比如说,如果您的服务中有一个pod无法访问Kubernetes数据存储,Kubernetes会重新启动它。您需要跟踪支持该服务的那些pod的状态。如果您看到数次或频繁的pod重新启动,这就成了问题。

另一个常见的基础架构问题是Kubernetes API服务器过载,需要很长的时间才能响应。每当需要执行某个操作,pod都要与API服务器通信——因此,如果API服务器过载,这就成了问题。

第三个基础架构问题与域名系统(DNS)有关。在Kubernetes中,您的服务由名称来标识,名称则由DNS服务器来解析。如果这些解析很慢,您会开始看到问题。

应用程序

有几个常见的应用程序问题可能导致重新启动和错误。比如说,如果您的服务负载均衡未起作用,比如说由于您的URL发生了变化或者负载均衡系统没有执行正确的操作,就可能会导致某一个pod过载,从而导致它重新启动。

如果您的URL构建不正确,您会收到响应代码“404页面未找到”。如果服务器过载,您会收到500错误。这些是应用程序问题,只不过表现为基础架构问题。

微服务故障排除方面的最佳实践

以下是有效识别和排除微服务问题的两个最佳实践。

1. 在服务层面聚合数据

您需要使用一款工具来提供在服务层面聚合的数据(即日志),以便可以查看出现了多少次pod重新启动和错误代码等。这与当今大多数DevOps工程师使用的方法不同;在后一种方法中,每次pod重新启动都是单独的警报,导致工程师陷入到可能只是正常操作或Kubernetes自我纠正的警报中。

一些DevOps工程师可能想知道是否可以使用服务网格来聚合数据。虽然服务网格内置了可观察性工具,但您要小心:由于涉及大量数据,许多服务网格会采样数据;它们为您提供了原始数据,并提供了标签,以便您自行聚合数据。您真正需要的是一种工具,为您仅提供服务所需的数据以及服务层面的报告机制。

2.使用机器学习

在试图识别和解决微服务问题时,您需要监控属于服务的每个pod在如何运作。这意味着监控延迟、进程重启次数和网络连接错误等度量指标。有两种方法可以做到这一点:

设置阈值——比如说,如果有20多个错误,就设置警报。在像Kubernetes这样的动态系统中,这种方法有点原始,尤其是在使用微服务的情况下。

确立基准——使用机器学习来研究度量指标随时间的推移而如何变化,构建机器学习模型,以预测该指标在未来有怎样的表现。如果指标偏离基准,您会收到一则警报,指明哪些参数导致机器学习算法认为存在问题。

我建议别尝试设置阈值——你会被大量警报所淹没,这会导致警报疲劳。相反,应使用机器学习。久而久之,机器学习算法可以在问题出现之前发出警报。

文章来源:https://sdtimes.com/microservices/troubleshooting-microservices-challenges-and-best-practices/

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址