当人们听到“微服务”时，他们通常会想到Kubernetes，一种声明式容器编排系统。由于其声明性，Kubernetes将微服务视为实体，这在故障排除时造成了一些困难。查看为什么在Kubernetes环境中对微服务进行故障排除具有挑战性，以及一些相应的最佳实践。要了解为什么对微服务进行故障排除可能具有挑战性，让我们看一个示例。如果您在Kubernetes中有应用程序，则可以将其部署为pod以使用Kubernetes对其进行扩展。该实体是您可以监控的Pod。对于微服务，您不应该监视pod；相反，您应该监控服务。所以你可能有一个单一的工作负载（一个单一的容器作为一个pod部署）并监控它，但是如果你的服务是由几个不同的pod组成的，你需要了解这些pod之间的相互关系才能理解这个服务是如何工作的，并受到监控，如果您不这样做，您认为的事件可能不是真实事件（即可能对服务的运行不重要）。在监控微服务时，需要在服务级别进行监控，而不是在Pod级别进行监控。如果您尝试在Pod级别进行监控，您将与编排系统发生冲突，并且可能会出错。1.对微服务进行故障排除时出现问题的常见根本原因在对微服务进行故障排除时，网络、基础设施和应用程序问题很常见。网络级别的问题最难调试。如果问题出在网络上，则需要查看套接字层统计信息。底层网络拥有连接A点和B点的套接字，因此您需要查看网络级别的往返时间，以了解是否正在传输数据包，是否存在路由问题等。基础设施问题可能会自行显现（Kubernetes中的崩溃循环）当基础架构pod重新启动时。发生这种情况的原因有很多。例如，如果您服务中的某个pod无法访问Kubernetes数据存储，Kubernetes将重新启动它。您需要跟踪支持该服务的那些pod的状态。如果您看到多次或频繁的pod重启，这就会成为一个问题。另一个常见的基础设施问题是KubernetesAPI服务器过载并且需要很长时间才能响应。每次需要执行操作时，pod都会与API服务器通信——因此，如果API服务器过载，这就会成为一个问题。第三个基础设施问题与域名系统(DNS)有关。在Kubernetes中，您的服务由名称标识，名称由DNS服务器解析。如果这些解析缓慢，您将开始看到问题。该应用程序有几个常见的应用程序问题，可能会导致重启和错误。例如，如果您的服务负载平衡不起作用，例如因为您的URL已更改或负载平衡系统未执行正确的操作，则可能导致pod过载，从而导致其重新启动。如果您的URL构造不正确，您将收到“404页面未找到”的响应代码。如果服务器过载，您将收到500错误。这些是简单表现为基础设施问题的应用程序问题。2.微服务故障排除的最佳实践以下是有效识别和排除微服务问题的两个最佳实践。在服务级别聚合数据你需要一个工具来提供服务级别的聚合数据（即日志），这样你就可以看到有多少pod重启、错误代码等。这与当今大多数DevOps工程师使用的方法不同；在后一种方法中，每个pod重启都是一个单独的警报，导致工程师陷入可能只是正常操作或Kubernetes自我纠正的警报。一些DevOps工程师可能想知道是否可以使用服务网格来聚合数据。虽然服务网格内置了可观察性工具，但要注意：由于涉及大量数据，许多服务网格都会提供样本数据；他们为您提供原始数据，并提供标签，以便您自己汇总数据。您真正需要的是一种工具，它只为您提供服务所需的数据和服务级别的报告机制。当尝试使用机器学习识别和解决微服务问题时，您需要监控属于该服务的每个pod的执行情况。这意味着监控延迟、进程重启次数和网络连接错误等指标。有两种方法可以做到这一点：设置一个阈值——比如，如果有20个以上的错误就设置一个警报。在像Kubernetes这样的动态系统中，这种方法有些原始，尤其是在使用微服务时。基准测试——使用机器学习来研究指标如何随时间变化，并构建机器学习模型来预测该指标未来的表现。如果指标偏离基线，您将收到一条警报，指示哪些参数导致机器学习算法认为存在问题。我建议不要尝试设置阈值-你会被警报淹没，这会导致警报疲劳。相反，使用机器学习。随着时间的推移，机器学习算法可以在问题出现之前发出警报。参考：https://www.kubernetes.org.cn/9812.html
