Elastic-5分钟教程：使用Elastic进行快速的根因分析

Elastic全观测性解决方案，允许您在单个数据存储中存储日志、指标和链路追踪等信息，这使得在可观测性数据上具有统一的可见性变得更容易。在本视频中，您将了解这对执行根本原因分析有何帮助

Elastic全观测性解决方案

允许您在单个数据存储中存储日志、指标和链路追踪等信息

这使得在可观测性数据上具有统一的可见性变得更容易

在本视频中，您将了解这对执行根本原因分析有何帮助

我们收到关于广告服务中的平均交易持续时间过长的警报

我们可从告警跳转到APM应用程序中的服务地图

所以，让我们来调查一下根本原因

在这里我们可以看到

广告服务是不健康的

红色圆圈表示得分大于75的异常

已被检测到

我们可以看到这些反常现象

正在影响着前端

让我们转到机器学习应用程序

调查这个问题

在单个指标查看器中，我们可以看到

临界点异常出现在10~11点之间

让我们进入anomaly explore

看看还发生了什么

我将选择APM、Kubernetes和Logs组

因为我们的应用程序部署在Kubernetes Pod中

让我们也按广告服务Kubernetes容器名称进行过滤

探索可能与我们的问题有关的其他异常情况

我们很快就能看到

我们的机器学习工作

检测到我们的内存和CPU使用率出现异常

还有一些与缓存相关的有趣的异常现象

让我们看看我们可以在APM应用程序中找到这些异常情况

9点20分左右有一个版本发布

在那之后

交易时长不稳定

让我们来看看在此版本之后是否有任何应用程序错误

广告服务在尝试获取广告时超时

但是为什么，到底是为什么呢？

让我们继续调查，通过检查

这些指标可以为我们提供哪些洞察力

关于运行广告服务的Kubernetes Pod

在发布之后

CPU大幅增加

内存使用量呈现峰值

非常不稳定

我们去看看日志吧

应用程序，看看我们能发现什么

关于特定的堆问题

以及是否与事务的超时错误有关

我们可以访问与高持续时间交易相关的POD日志

我将缩小查询范围以查找相关的heap或memory事件

我们可以看到

广告服务正在终止

由于内存不足

但是为什么呢？

我们知道

尝试接收添加时出现与缓存和超时错误相关的异常

上下文中的日志向我们表明

这些异常和错误正在发生

因为item被添加到缓存中

直到没有足够的内存

从而使广告服务终止

并重新启动

广告服务中平均交易持续时间较长的根本原因是版本损坏

它在缓存项目时不验证是否有足够的内存

结果

广告服务一直在重新启动

并且不能响应请求

显著增加了响应时间

通过回滚损坏的版本来控制该问题

我们会修复广告服务

以避免消耗过多的内存

感谢收看这段简短的视频

浅谈用Elastic进行根本原因分析

查看参考链接以了解更多信息