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进行根本原因分析
查看参考链接以了解更多信息
