大家好，我是阿里巴巴云的Li Huangdong。如何使用kubernetes缓慢监测定位。托迪的课程主要分为三个部分。首先，我将引入缓慢通话的危害和常见原因。其次，我将介绍慢速通话的分析方法和最佳实践；最后，通过几个情况来证明缓慢的调用。分析过程。
在开发软件的过程中，缓慢的呼叫非常普遍。可能带来缓慢的危害包括：
因此，这似乎是一个巨大的风险，似乎无关紧要，我们应该保持警惕。最好不要因为缓慢的呼叫而忽略它。您应该尽可能分析其背后的原因以控制风险。
慢速通话的原因是什么？慢速通话的原因是数千万，有五个常见的原因。
今天，我们的例子围绕着这五个方面，让我们看看。
缓慢定位的步骤是什么，或者最佳实践是什么？我在这里总结了三个方面：金信号 +资源索引 +全局体系结构。
让我们先看一下黄金信号。首先，黄金信号来自Google SRE圣经
站点可靠性工程
这本书。用于表征该系统的最低指标的集合是健康的，其中包括：
除了黄金信号外，我们还需要注意资源指标。服务问题，您只需要花费5％。
在有黄金信号和资源指标之后，我们还需要注意什么？就像白兰地在方法论中提到的那样，“我们看不到树木，看不到森林。” Zhuge Liang还说：“不寻求整体情况不足以寻求域名。并通过设计方法来系统地解决问题。这也是一种更好的方法。因此，我们需要黄金信号，资源指标和全球体系结构的组合。
接下来，我将谈论三个案例。首先是节点CPU的问题。这也是由典型的资源问题引起的服务缓慢的问题，即由服务自己的资源引起的问题。第二是服务中间部分缓慢呼叫的问题。第三个是网络性能差。第一种情况是确定服务本身是否有问题。第二种情况是判断下游服务问题；第三个是判断自己与服务之间的网络性能问题。
我们以E -Commerce应用程序为例。首先，流入入口是Alibaba Cloud SLB，然后流量进入微服务系统。在微服务中，我们可以通过网关接收所有流量，然后网关将访问相应的内部服务，例如productservice，cartservice，paymentservice.below，我们依靠一些中间件，例如redis，mysql等。整个体系结构我们将使用阿里巴巴云的武器kubernetes监视产品来监视整个体系结构。在故障注入的术语中，我们将通过Chaosblade注入不同类型的异常，例如CPU Full和网络异常。
节点CPU将满足什么样的问题？节点CPU已满后，上述POD可能无法申请更多的CPU，从而导致内部的线程等待调度，这会导致慢速呼叫。对于节点，除了CPU外，还有一些资源，例如磁盘，内存和其他资源。
接下来，让我们看一下Kubernetes群集中CPU的某些特征。首先，CPU是压缩资源。在Kubernetes中，我们在右侧查看这些配置。有几种常见的配置，例如请求。请求主要用于调度。限制在运行时使用限制。超出了这一限制，它将受到限制。因此，我们的实验原理是说节点的CPU已完全注入，导致POD无法申请更多的内存，从而导致服务较慢。
在官方开始之前，我们通过拓扑映射确定了密钥链接并在其上配置了一些警报。例如，网关和付款链接，我们将配置警报，例如平均响应时间P90和慢速呼叫。配置，我将注入一个节点CPU以使失败。然后，该节点由网关节点选择。大约五分钟后，我们可以收到警报，即第二步中验证警报的有效性。
接下来，我们输入根本原因。首先，我们输入网关的应用程序详细信息。第一步是检查相关的金信号。金信号是响应时间。我们看到响应时间非常直观，可以突然增加。慢速呼叫的数量不足。P90/P95显着增加，超过一秒钟，这表明整个服务也放慢了速度。
接下来，我们需要分析资源指标。在POD CPU使用图中，我们可以看到在此期间，POD使用迅速增加。此过程表明您需要从主机或节点申请更多内存。LET仔细研究节点或托管的CPU使用情况。我们看到在此期间的使用率接近100％。POD不能申请更多的CPU，这进一步导致服务缓慢，从而导致平均响应时间大幅增加。
将问题定位后，我们可以考虑特定的解决方案。配置弹性望远镜通过CPU用法。因为我们不知道相关的流量或资源，而这是不够的。使用此场景是配置弹性望远镜资源，以配置节点的弹性望远镜，主要是为了确保在负载上升时资源可以动态扩展。为了配置弹性望远镜应用程序，我们可以设置一个容量，我们可以设置一个容量增加副本数量以增加CPU指数的流量。在这个地方，我们可以配置最大副本的最大副本，最小的副本为三个，依此类推。
效果如下：当CPU注入缓慢的故障时，缓慢的呼叫将上升。上升完成后，它将触发到弹性望远镜，即CPU的使用率超过阈值，例如70％。然后，它将自动扩展一些副本以共享这些流。我们可以看到，慢速呼叫的数量逐渐减少，直到它消失为止，这表明我们的灵活望远镜退化起着作用。
让我们看第二个情况。首先介绍准备工作。在左侧，我们可以看到网关进来并丢弃了两个下游服务。一个是mysql，另一个是productservice.Alarm.Alarm.Alarm.Second，我们看到该产品也在密钥链接上。我给它一个大于一秒钟的p99警报，第三个是mysql，警报大于一秒钟。注入MySQL慢速查询故障。大约两分钟后，我们可以看到警报被触发。网关和产品上有一个红点和一个灰点。实际上，这已报告给报告。Failure是报告的警报，Kubernetes监视将通过名称Space应用程序自动将此警报事件用于节点，因此您可以查看哪些服务以及哪些应用程序浏览器异常。这可以迅速将问题定位在问题所在的情况下。接下来，我们收到了警报，下一步是执行根本原因。
首先，让我们谈谈更新定位的过程。警报驱动程序由于预防而比补救措施更好，因此我们使用第一个配置警报，然后更新定位过程。被可视化。收到警报后，警报的相应申请发生了什么。我们查看了该网关的第一个，我们看到网关的P99上升至1800毫秒以上，因此我们触发了一个大于1秒钟的警报阈值。我们还可以看到一些细分市场上升，然后我们进一步查看另一种警告服务，即产品。单击此节点后，我们可以从该面板中看到该产品。慢速呼叫，P99和P95已经发生了不同程度，其中大多数都超过一秒钟，然后此时我们可以看到产品本身可能存在问题，因为我们检查了产品的下游，一个是NACOS，另一个是MySQL。当我们看到MySQL的相互作用时，我们发现其中有大量慢速通话。看到这些缓慢的呼叫声之后，当被调用时发生了。查看这些数据后，我们会发现，当产品在SQL中调用MySQL时，它会执行非常复杂的功能，并且JOIN具有多个表的SQL语句。这需要大量时间来调用跟踪。这样，我们可以将其定位。基本上，这基本上是该SQL生成的问题。
首先，为了总结我们的整个过程，我们将确定通过体系结构的关键路径，然后在此关键路径上配置警报以主动发现异常。发现异常后，我们可以通过应用自己的资源索引金来找到问题信号。如果没有问题，那么我们可以跟踪下游。让我们看一下下到达中的资源指标。使用这样的方法来定位慢速呼叫的依赖问题，即中间件呼叫的问题。
接下来，让我们谈谈最后一个示例是网络性能差。Kubernetes的网络体系结构相对复杂。容器之间的通信，POD之间的通信，POD与服务之间的通信，外部和服务之间的通信等。因此，复杂性相对较高，学习曲线很陡峭，这在定位问题上带来了一些困难。我们处理这种情况吗？如果您使用关键网络环境指标查找异常网络，那么关键的环境指标是什么？第一个是速率和带宽，第二个是吞吐量，第三个是延迟，第四个是RTT。
首先，我将在此处配置警报，以注入MySQL的高数据包损耗率。等待几分钟后，我们将收到一个缓慢的通话警报。网关和产品的响应时间大于一秒钟的警报。接下来，让我们看一下根本原因的根本原因。我们看到了网关，慢速呼叫p99的响应时间增加了，然后问题也增加了平均响应时间，即现在的服务缓慢地调用，然后我们有。在NACOS，REDIS和MYSQL的三个服务上。可以发现，缓慢的呼叫是显而易见的。然后，当我们在下游检查它时，我们发现问题是由MySQL调用的。在同一时间，它的RTT和RE -TRANSMISSION现象也很明显。
在正常情况下，RTT非常平滑。它反映了上游和下游之间的往返时间。如果它很快上升，可以从基本上认为它是一个网络问题，因此可以看出，其中有三个，从网关，产品，mysql中，我们可以从这里总结一下识别关键路径的这种方法，然后在拓扑上配置警报以很快找到问题，无需验证许多在各个地方散布的信息。我们只需要转到拓扑即可检查相应的性能指标，网络指标，等等。并迅速找到问题。因此，这是我们的金信号 +资源指示器 +资源拓扑定位（如慢速通话）的最佳实践。
最后，总结这次的最佳实践：
1.通过默认警报积极发现异常。默认警报模板涵盖了红色，常见的资源类型指标。在默认发布的警报规则外，还可以根据模板自定义用户。
2.通过黄金信号和资源指标发现和定位异常。
3.通过拓扑图的上游和下游分析，依赖性分析和体系结构感知，这有助于从全球角度审查体系结构，以获取最佳解决方案，不断改进并构建更稳定的系统。