关键字: [亚马逊云科技， 生成式AI， CloudWatch Logs Insights， Cloudwatch Logs Insights， 可观测性， 日志模式分析， 自然语言查询， 生成式Ai]

导读

在这场演讲中，演讲者介绍了亚马逊云科技的CloudWatchLogs Insights功能，讨论了如何利用该功能实现云上运维的新思路。演讲者解释了CloudWatchLogs Insights可以通过日志模式观察、比对模式分析、自然语言生成查询等功能，帮助快速定位和分析系统问题的根源。此外，演讲者还演示了如何将CloudWatchLogs Insights与其他亚马逊云科技服务(如Amazon X-Ray、Amazon DevOps Guru)结合使用，实现更全面的可观测性和运维洞察。演讲的重点是利用生成式AI技术来提高云上运维的效率和质量，加速问题排查和修复。

演讲精华

以下是小编为您整理的本次演讲的精华。

在过去，我们可能会透过原始的方式去做触发，或者是去设定一些比较近拍相关的这种作流程以及设定一些拍段等等。接着，到了下一步，我们可能会带入一些像是机器学习比较进阶一点的这种应用场景来去做一个这个异常的检测，可能会通过历史上面的一些数据去找到固定的一些模式，然后进而去帮我们去做到一些可观测性。到了下一步的话，我们就会给予像是现在比较这个火的这个生成式AI或者是大模型这样子的一个技术，继而去做到一些事件上面的洞察分析，以及在上下关联的这个potential上面的一个这个上下文的承接，然后进而去解决我们的问题根源的分析。

有了这样子可以去做这个事件以及跟眷恋i结合的这样的应用分析以后，在下一步我们可能会想针对就是forecast的部分，我们通常会不只是单纯在研究现在的这个问题的根本原因，我们也希望对于未来事件的发生的时候也可以起到一些这个预测性的作用。那最后一部分就是针对这个自动化的过程，我们知道了这个问题发生的原因，然后也可以去做到的一些forecast上面的预测跟分析以后，怎么样去做到一个快速修复呢以及自动化的这个流程上面，就会可以加速我们在整体运维然后以及开发上面的一个效率。

基于AI以及可观测性上面，亚马逊这边由针对这样子的一个主题分为四个不同阶段的一个成熟度。首先在stage one的话，是属于这个基础的观测，我们可能会采集像是指标相关的指标、日志，以及追踪资料，然后方便我们去查找平常的这些系统的问题。到了stage two的话，比较像是在做更进一步，通过这些已经收集的数据，我们也怎么样去找到更多的洞见，协助我们不管是在系统的稳定性，然后以及在商业决策面上面，怎么样去做到一个更好的辅助。

到了stage three的话，我可能会透过像机器学习这样的一些应用技术，怎么样让我们去做一个模型上面的，基于模型上面的一个训练，然后以及学习，进而去引导我们在刚刚去比如说去做到一个预测啊等等这些的action。到了stage four，我们可能除了刚刚提到的这些辅助的洞见，然后以及这个自动化流行以外，我们可能还会希望透过这整个以ORD层面organizations这样的一个层面来看待整个系统的一个稳定性。

现在我们来说说大家平常可能在做运维上面可能会遇到的几个比较大的挑战。首先第一部分的话可能是太多的数据，相信大家平常在做这个，不管是日志的查找啊，指标的查找，当我们遇到一个问题的时候，我们可能会针对不同的这些数据来源一一去看实际发生问题的根本原因到底在哪里。其实当我们要去查找这些数据的时候，其实也是一个非常耗时，然后增加我们去分析问题的一个难度。

另外就是在变更管理上面，我们可能每天都会去做一些小版本啊，或者是大版本之类的这样子的一个变更，怎么样去透过一个比较有效管理的方式，要让我们去知道说哎这些变更到底是差异化在哪里等等，就可能也是大家平常会遇到的一个挑战。

到了第三块部分的话，就是针对主动式的监控，我们怎么样在客户跟我们反馈问题之前，可以通过比较主动的方式，第一时间我们可以先去接收到系统上面的问题，而不是等到真正的用户来跟我们反应的时候，我们才以被动的方式去看问题出现的原因在哪里。

第四块的话，其实遇到蛮多客户，他其实现在监控的部分都是针对已知的部分去做监控，很多时候都是等到哎这个问题可能是之前没有面临过的，我们才会在针对这样子的一个问题，重新用这个反馈的方式，然后重新去更新我们的观测的系统。

所以我们可以想象一下，假设我们今天是在玩这样子的一个乐高游戏，要去找到其中一块指定的拼图，其实是会非常困难也非常耗时间的。但假如我们今天针对不同的，比如说应用场景，或者针对不同服务不同的类型，我们先去做一个很好的归类的时候，这时候我们要去找到特殊的某一块音符的时候，就会变得相当的容易。

所以因此我带入到我们今天的主题 CloudWatch Logs 的功能介绍。首先什么是 AI Ops?及什么是生成式 AI Ops?他们其实是稍稍微有些区别的，我们可以看一下。在这个大的圆圈里面，我们可以把它想成是一个主要的 AI Ops 的一个主题，里面可能包含的像是模式的分析、异常的检测、趋势预测等等。在中间的部分，主要是这个生成式 AI for Ops 这样子的一个概念，它并不只只只是去做单纯就是查找啊等等的问题，它其实是可以透过自然语言的方式，更直觉的更直觉化的方式帮助我们去找到这个问题的原因到底在哪里。所以包含像是要去做一些调查，或者是要去做一些组织上面的这个上下文的查找，然后以及文本到代码的转换，用自然语言的方式转化成代码语言的方式，然后更容易的去学习代码语这样子的一个门槛。

CloudWatch Logs 针对 AI Ops 这边，我们有提供几个功能，首先想跟大家分享的是针对日志模式的观察，除了我们可以透过这个 CloudWatch Logs Insights 去查找我们所关心的这一条日志数据以外，其实它也有提供像模式这样子的一个功能，通过模式它可以去帮各位去看一下现在的日志里面有哪些固定的这些模式，并且会去帮各位去做一个简单的总结，针对这样子的一个日志模式，它总共发生了多少次，占总体日志的比例是多少。

所以透过这个功能，我们就可以非常快速的去了解现在系统的日志的问题。除此之外，它也有提供一个比对模式的功能，我们可以针对两个不同的时间段上面可以去做一个分析。例如说这个错误日志出现的比例是持续增加或者是持续减少的，这有什么好处呢?我们可以透过这样子的一个功能去知道某个错误日志，它其实是在某个时间点上面突然新出来的模式，或者是说我今天想去修复某个问题，也可以通过这样子的一个功能去知道这个错误日志的数量是不断的在递减的，我们就可以知道现在系统的一个状态。

除此之外，我们也可以透过这样子的一个功能去看到异常的告警的结合，例如在这个错误的模式上面，它其实是在它的严重程度上面是处于一个一个比较高的一个状态，或者是说它持续发生的过程其实是多长的时间点。所以像这样子的一个资讯，也可以通过这个日志分析上面去找到。

针对就是刚提到自然语言的方式，在 CloudWatch Logs 上面，它有提供用自然语言的方式，然后直接去生成查询语句，我们就可以通过这样的方式直接去跑出相关的日志。这有什么好处呢?其实我们以往可能要去写这样查询语句是比较复杂的，而且也需要去有一些一定程度的了解，才有办法写出像这样子的一个查询语言。现在通过这个自然语言生成日志查询的方式，我就可以直接用很直接的方式，比如说请帮我捞取比如说错误的日志这样子的一个自然语言的方式，它就会自动针对这样的语句去生成查询语言，然后进而去捞出相关的一些数据。

除此之外，CloudWatch Logs 这边也有搭配 DevOps Guru 这样的一个功能，然后进而去帮助我们做到一个更好的运维跟洞察。它提供的几个好处包含它可以通过统一的入口去做一个支持，以及它可以去做一个引导式的分析，例如说它可以在旁边一步步通过提示的方式来帮助我们去找到实际问题是发生的原因，并且它也会提供我们一些相关的建议，例如说哎，这个事件可能是因为我们在做什么样子的更新，所以才会导致有这样子一个错误，所以它可以用更主动的方式去提示我们系统的问题可能出现在哪边。

我这边也补充一下，这边提到刚刚提到说广泛大量的一个数据其实是不容易查找问题的，这边指的数据并不只指就是单纯的日志这样而已，其实它还包含像是日志、指标、分布式跟踪，以及在做部署等等的历史，它其实也是可以同步纳进在这个广泛大量数据的这样的一个收集里面。所以它其实看的层面并不只是以往可能针对日志、指标这几种资料，它其实可以看的数据是非常多的。等一下我们也会做一个演示，其实当你去配置这样子 CloudWatch Logs Ops 的时候，它其实会有一个选项是透过调查的方式，然后你可以直接去选择调查，然后就会根据你现有的一个数据去帮你找到针对这个问题所触发的原因有哪些。

刚才提到的是产品及服务上面跟大家去做一个快速的介绍。接下来针对这个可观测性的深层次 AI Ops 上面跟大家去来做个这个分享。这张图是可能大家平常在做一个运维上面可能会经过的几个步骤。从1开始，我们可能会先对异常发到一个告警，或者是一个通知等等。接下来第一步我们可能会先去看一下这个告警它的一个真实性，然后并且去找到说哎，这是不是一个真实系统发生的一个问题，假设它是一个真实系统缺乏出来的这样的一个实际问题的时候。接下来下一步可能会开始去看日志，去查服务，会去看相关的服务指标，或者是去找到内部跟这个服务或者是这个应用相关的一个团队，然后去找好一起来去看一下问题到底出现在哪里。

那这时候就会进入到这个推测这个问题的入口是到底发生在什么样的地方，然后可能会通过一些故障的手册啊，或者是去找到一些之前记录过的这些文档等等，去看一下之前是不是有类似的问题及怎么样去做一个排查，到最后可能会通过分析或者是去看到的实际发生错误的这条日志是发生在哪边，然后开始去做一些修复，然后迪拜重新去做一些测试，然后再上线部署等等，所以则是我们可以想象就是平常在做一个运维上面的路径。

当我们要去做这个 AI Ops 的这样子的应用的时候，我们其实可以从我们的目的上面去回馈我们到底想要做什么。这上面列的项目可能并不是每一条大家都一定需要去做一个导入。在这边分享几个部分，包含像是我们怎么样通过在做第二开发这个应用程序的时候去做到一个自动化的数据采集。以及针对在，我们可能会希望专注在实际这个创新啊研发，做真正有对公司有利益价值的事情，而不是每天都在看这个日志啊，或者是在搜这个调试等等注意这些相关的事情。另外就是在做运维层面，我们可能也希望缩短再花在运维已经花多少的时间，让整体的这个系统迭代是可以更快的。

所以针对这个目的性的时候，我们可以先从目的去回推我们到底想要做哪一部分的 AI Ops。从整体的分析来看的话，我们可以分为这个自动化以及人为方式的部分去做一个介入。我们这张流程图来跟大家说个做个说明。首先在第一步的部分，我们可能会先在第一步先去看说哎这个问题它发生在哪一个层面上面，有可能是针对网络的问题，或者是它提示这个我们运算上面发生了什么样子的一个问题。所以首先在第一部分，我们会先透过层面的方式去判断说这是发生在什么样子一个层面上面的问题。

到了第二步的时候，我们就可以针对刚刚所收集好的这些应用数据，例如说像是这个分布式跟踪的资料啊等等。接着我们同样可以整合像是知识库这个知识库的概念，所以在整体的这个过程的部分，并不只是只是把数据互相的去做分析比对应用而已，而是会加入这个专业知识的部分，然后一起去协助我们排查这个问题的原因。

接下来在第三步的时候，我们就可以再去判断说哎，这个这样子的一个系统发生的问题是什么?然后可以通过一个总结事故的这个观察报告方式，然后去帮助我们的这个维护人员，然后去判断说到底要怎么样去修复。

整体的这个排查的过程，我们可能会一开始会先收到像这样的一个告警信息，有可能是针对指标的异常，或者是日志侧开始吐一些大量error这样子的一个信息。总之我们可能会先透过这样的一个系统异常的信息，先主动的去知道说哎，现在系统其实是发生了一些问题，接下来在旁边它可以会透过一些新的发现，那这些发现可能是透过同样一个问题而衍生出来的其他相关的一些异常检测出来的一个结果，所以有可能当我们今天应用程序它可能一直吐log，它有可能是因为对于DB的访问的问题，或者是它今天对于权限上面有某些的一些，那它就会去同步所在这段时间上面相关的这些应用到底发生了什么事，然后进而帮我们一步一步去做一个排查的发现。

接下来我们就邀请雅本老师帮我们做一个演示的解说。这个应该是大家比较熟悉的亚马逊的界面啊，这个如果你要拍照的话，说明你好没用过亚马逊啊，大家可以打到打开到这块，然后我们哎能回到刚才那页吗?我我我我来自己点播放啊，然后那个左边这块啊，今天我们要演示的功能是左边这块还是就是CloudWatch Logs Ops里边的调查部分啊，它其实就是根据分析，或者说叫时间洞察对吧?

那么我们整个出发点都是从告警开始的，刚才小鸟介绍过，那我们有多种出发的可能，其中一种就是从告警这一块，当告警发生的时候，可能在这个界面里，它会告诉你有哪些相关的告警，那通过告警，我们可以创建调查，然后我就点开开始对大概几秒钟的时间，它就开始做这个整个这个流程，那么我们啊鼠标已经开始动了，那我给大家简单介绍一下我们这个界面啊，效果非常非常简单，这个是X-Ray，大家也应该用过，没用过你也应该知道有这么一个东西，它叫分布式跟踪，在这里面我们可以看到，当你点击每一个节点的时候，可以看到一些很很详细的信息，比如这个就是延迟，然后请求数量在一个周期里面，还有它的错误率一点，每一个它都会有相关性，那么在这个整个东西开始的时候，你会看到它都没有报错，因为我们是一个注入的概念，比如说你的应用一开始可能是没有任何问题，然后我们注入问题，然后才会出现这个问题，从0开始往上上升对吧?

那么整个这个流程是这样，今天为什么没有时间给大家演示这个live demo?因为整个这个过程耗时会比较长。第一呢就是我先要注入一个没问题的，然后等它跑通了，高级变绿了，变成OK了，我开始注入问题，等它发现问题，发现问题之后我再创建高级对吧?所以这个时候你们看到我，我这块大概过一段时间它就从那个没有数据变成OK的状态，这是我的告警数据。

那完成这个告警数据OK之后呢，你点进去你是可以看到就如果它是OK状态下啊，当然我们之前测试你也看到有红过对吧?OK状态下它是0的，然后这个告警是什么?这个告警就是500错误数除以这个总的调用量，那它就是一个错误率的概念。

那对于我们很多客户来讲，SLO并没有拿到一个很高的维度去作为告警监控，SLO是什么就是你的服务的可用性和可靠性，那服务的可用性和可靠性实际上会是一个非常重要的指标，当它出现问题的时候，往往是入口错在报错，大家可以看到这是API网关会在入口处它在报错，那在这个时候你再看它的详细信息，那前两个我们可能不一定有多关注，但是后面你可以看到它的500的这个比例就开始上升了对吧?这个就是我们业务层最应该关注的，就是我前端的端口的返回出现错误，我不要等着我的客户跟我说出问题了，我自己应该知道对吧?

当这个告警触发的时候啊，当然我们这块最简单的5分钟的告警这块就会有红的，那我们就能看到这LR它就会从状态从OK的状态变成告警状态，那么这个时候我点进去的时候，你就可以看到一些相对比较详细的信息，然后这个时候在最上面大家可以看到这一个出发点，因为谁给它触发的?就是刚才我给大家介绍的和CloudWatch告警的那个入口，它在告警这一块入口，当当然还有其他入口啊，比如它可以从指标的里边切入，这个时候你点进去之后就可以创建一个这个告警的流程啊，这个就是一些信息的注入，你当然提供越详细的信息，作为它的调查，初始化的调查就会做的更好，但是你后面还有很多的信息会可以提供上去，我们刚才介绍了它是一种引导式的这个调查问题的方式，也就是说你自己在不断的在被提示，也就是你可以买的东西里面选择你要哪些东西，往右边去，往左边去走，我们可以看到左边这块是已经选好的东西，右边是它不断给你提示的新东西来看new item就是说它不断在发现，那这里面还有一个log的概念，就是说当你点到它里面，你都看它可以干干过什么事情，你会发现它会查近期的变化，会从你的action的那个CloudTrail里面去查你有哪些action或者event对吧，然后它会查log啊，然后它会查产品的一些具体的权限，然后它会查那个每个服务的指标和每个服务变更和配置，那你这边就可以选择我是接受还是不接受。

那么，我们知道AI还是有幻觉，最好的模型还有百分之x的幻觉，它只是这个x大或者小，对于它来说，我们就可能出现我接受这个幻觉，或者我我接受这个事实，或者我拒绝它作为一个幻觉，到最后的时候啊，我们这个跳过了很多，到最后的时候，它会有一个叫海帕斯，它是有一个假设的，发现它认为这个事情它可以总结出问题，然后这个时候它把问题抛给你了，就是这是我总结出来的，就是基于你左边所有东西的一个一个结论。

那么如果你接受呢，我的这个分析呢，就结束了，如果你不接受呢，你可以提供一些新的线索，我可以继续做这个事情。这是引导模式的一个非常标准的玩法，那我们知道，其实作为这种根因分析呢，我们有多种这个可以做的一种方式，刚才小鸟分析分享过啊，我们一个叫全自动的，一个叫人工介入的，那这是人工介入的一种，那全自动当然就是我把所有信息拿出来对吧?然后我就分析，然后分析出来是有结果或者没结果两种情况，那么有结果它会出报告，没结果它会告诉我为什么没有结果，对吧?这是全自动的一个逻辑。

还有一种逻辑呢，其实对话，是的，我们大家其实跟那个AI在交流的过程当中，已经非常习惯对话式了对吧?对话的方式呢，是它成为你们员工中的一员。我们可以想象啊，如果出现一个大的，这个公司大的故障，我们会不会有一成立一个群，这个群里面是可能是一堆专家，也可能是一群，就是我们叫值班，就是夜里面或者什么时候在在在等待处理问题的人，还有可能是一堆领导督促我们在解决问题。但总的来讲它是一个群，大家在里面说话，有的人说赶紧解决，有的人说我有发现啊，有的人问说这问题到底是谁负责对吧?

那这个时候呢，你就想象里面加了一个机器人，这个机器人就是一边听你们说话，一边给你们提供信息啊，老板可能问这事谁负责，它就说老板我知道谁谁谁负责对吧?然后你说我感觉可能是CPU的问题，然后它就回复，应该不是，我刚查过了对吧，几台机器CPU什么情况，那它就是你们工作中的一员，它既能反馈给你信息对吧?它也可能会有提问，比如它卡在哪个地方?它说我想知道什么?那NO，在这次里面可能我没有查到，这是另外一种情况。

所以大家可以看到所有的这个这种根因分析，它其实有多种模式是可以做的。那今天我们看到的是其中一种模式，在CloudWatch Logs Ops里面，大家可以根据自己公司里面的实际情况，选择喜欢使用的服务，或者建立自己想用的AI Ops的流程。

好吧，今天我们的分享就到这里，谢谢各位!请大家扫码扫码填写问卷。

接下来有请闪电演讲使用可观测性工具加速生成式AI应用卧底分享嘉宾亚马逊科技解决方案架构师杜晨曦有请。

刚才我们介绍了CloudWatch Logs在AI Ops领域的一些新功能和思路。我总结一下它所带来的主要价值:

首先，它可以解决我们在运维过程中遇到的一些难题，比如大量数据难以查找问题根源、变更管理的差异化、缺乏主动式监控、未知问题难以发现等。通过日志模式分析、比对模式、异常告警结合、自然语言查询等功能，我们可以更高效地定位和分析问题。

其次，它将可观测性数据与专业知识库相结合，不只是简单分析数据，而是会加入领域知识，协助我们更准确地找到问题根源。同时通过引导式分析和建议，以更主动的方式提示可能的问题所在。

第三，它为我们提供了自动化和人机交互两种模式。全自动模式下，它会自动分析所有数据，有结果时给出报告，无结果时解释原因。人机交互模式则更像是把AI作为工作中的一员，通过对话的方式，一步步引导找到问题，并给出建议。

最后，通过现场演示，我们可以看到CloudWatch Logs Ops与其他亚马逊云科技服务集成的全流程，包括从监控告警入口、调查初始化，到通过日志、指标、变更历史等数据源的不断分析，最终给出问题假设，供我们确认或补充线索。

总的来说，Amazon CloudWatch Logs为我们提供了一种新的可观测性思路，将人工智能、机器学习等技术应用于运维领域，提高了运维效率，加速了问题分析和修复，同时也为未来的自动化、智能化运维奠定了基础。

在此过程中，我们既可以利用AI的智能分析能力，也不会完全被取代，而是通过人机协作的方式，发挥人的主观能动性，达到事半功倍的效果。我相信这种新思路一定会为云上运维带来全新的体验和价值。

刚才提到的是表片产品及服务上面跟大家去做一个快速的介绍。接下来我们有几个客户案例，包含像是 SmallHD 公司，它是一个专门从事照片编辑的公司，以及像是 Standard Gate 这个是一个医疗保健平台，还有亚马逊内部的一些团队，像是亚马逊的运动服务团队、音乐团队等，他们都有采用这种基于 CloudWatch Logs 的 AI Ops 解决方案，主要目的就是希望可以加速在查找问题上面的效率。

接下来针对这个可观测性的深层次 AI Ops 上面跟大家分享。这张图是大家平常在做运维上面可能会经过的几个步骤。从第1步开始，我们可能会先对异常发出告警或通知。接下来第一步我们可能会先去看一下这个告警的真实性，然后找到这是不是系统真实发生的问题。假设是真实发生的系统问题，接下来可能会开始查看日志、服务指标，或找到内部相关的团队，一起查看问题出现在哪里。

这时候就会进入推测问题根源发生的位置，然后可能会通过故障手册或记录过的文档等，查看之前是否有类似问题及如何排查。到最后，可能会通过分析或查看实际发生错误的日志条目，然后开始修复，再进行测试，上线部署等。

当我们要去做 AI Ops 的这样子的应用的时候，我们其实可以从我们的目的上面去回馈我们到底想要做什么。这上面列的项目可能并不是每一条大家都一定需要去做。在这边分享几个部分，包含在开发应用程序时如何去做自动化的数据采集;我们可能希望专注于实际创新研发，做对公司有价值的事情，而不是每天都在查看日志或调试;在运维层面，我们可能希望缩短在运维上花费的时间，让整体系统迭代更快。

所以针对这个目的性，我们可以先从目的去回推我们到底想要做哪部分的 AI Ops。从整体分析来看，我们可以分为自动化和人为方式的部分去介入。首先在第一步，我们可能会先透过层面的方式去判断这是发生在什么样的层面上的问题，有可能是网络问题或计算问题等。

到了第二步，我们就可以针对刚收集好的应用数据，例如分布式跟踪资料等。接着我们同样可以整合知识库的概念，所以在整个过程中，并不只是把数据互相分析比对而已，而是会加入专业知识的部分，一起协助排查问题原因。

接下来在第三步，我们就可以再去判断这个系统发生的问题是什么?然后可以通过总结事故的观察报告方式，帮助维护人员判断要怎么修复。整个排查过程，我们可能会一开始收到异常告警信息，有可能是指标异常或大量错误日志等。总之我们可能会先透过这样的系统异常信息，主动地知道系统发生了问题。

接下来在旁边它可以会透过一些新的发现，这些发现可能是透过同样一个问题而衍生出来的其他相关异常检测出来的结果，所以有可能当应用程序一直吐出错误日志，它可能是因为对数据库访问的问题，或者是权限问题等，它就会去同步在这段时间内相关应用发生的事情，然后进而帮助一步步去做排查发现。

在这个演示中，我们今天要演示的功能是左边的 CloudWatch Logs Ops 里的调查部分，它其实就是根据分析或时间洞察。我们整个出发点都是从 CloudWatch 告警开始的。当告警发生时，可能在这个界面里，它会告诉你有哪些相关的告警。通过告警，我们可以创建调查，大概几秒钟的时间，它就开始做这个整个流程。

在这个界面上，我们可以看到 X-Ray 的分布式跟踪，有一个简单的架构图，当你点击每一个节点时，可以看到延迟、请求数量、错误率等很详细的信息。在整个过程开始时，你会看到它都没有报错，因为我们是一个注入的概念，比如说你的应用一开始可能是没有任何问题，然后我们注入问题，才会出现这个问题，从0开始往上升。

整个流程是这样，今天为什么没有时间演示 Live Demo?因为整个过程耗时会比较长。第一我先要注入一个没问题的案例，等它运行通了，变绿了，变成 OK 了，我再注入问题，等它发现问题，发现问题之后我再创建告警。所以这个时候你们看到，过一段时间它就从没有数据变成 OK 状态，这是我的告警数据。

完成这个告警数据 OK 之后，你点进去可以看到，如果它是 OK 状态，当然我们之前测试你也看到有红色过，OK 状态下它是0的，然后这个告警是什么?这个告警就是500错误数除以总调用量，它就是一个错误率的概念。

对于我们很多客户来讲，SLO 并没有拿到一个很高的维度去作为告警监控，SLO 是什么就是你的服务的可用性和可靠性，实际上会是一个非常重要的指标。当它出现问题时，往往是入口处报错，大家可以看到这是 API 网关在入口处报错，在这个时候你再看它的详细信息，前两个我们可能不一定关注，但后面你可以看到它的500错误比例就开始上升了。这就是我们业务层最应该关注的，就是我前端的端口返回出现错误，我不要等着客户跟我说出问题了，我自己应该知道。

当这个告警触发时，我们这块最简单的5分钟告警就会有红色，点进去可以看到一些相对比较详细的信息。在最上面大家可以看到这个出发点，因为是谁给它触发的?就是刚才我给大家介绍的 CloudWatch 告警入口，它在告警这一块入口。当然还有其他入口，比如它可以从指标或日志的里边切入。

这个时候你点进去之后就可以创建调查流程，这个就是一些信息的注入，你当然提供越详细的信息作为初始化调查就会做得更好，但后面还有很多信息可以提供上去。我们刚才介绍了它是一种引导式的调查问题的方式，也就是说你自己在不断地被提示，类似于你在购物的时候，可以选择你要哪些商品，往右边去、往左边去走。我们可以看到左边这块是已经选好的东西，右边是它不断给你提示的新东西来看。

这里面还有一个日志的概念，就是说当你点进去，你都看它可以干过什么事情，你会发现它会查近期的变化，会从你的操作的 CloudTrail 里面去查你有哪些操作或事件，然后它会查日志，然后它会查产品的具体权限，然后它会查每个服务的指标和每个服务变更和配置。你这边就可以选择我是接受还是不接受。

我们知道 AI 还是有幻觉，最好的模型还有百分之几的幻觉，它只是这个百分比大或者小。对于它来说，我们就可能出现我接受这个幻觉，或者我接受这个事实，或者我拒绝它作为一个幻觉。到最后时，它会有一个叫做假设，它是有一个假设的发现，它认为这个事情它可以总结出问题，然后这个时候它把问题抛给你了，就是这是我总结出来的，就是基于你左边所有东西的一个结论。

如果你接受我的这个分析结果，就结束了。如果你不接受，你可以提供一些新的线索，它可以继续做这个事情。这是引导模式的一个非常标准的玩法。

我们知道，其实作为这种根因分析，我们有多种可以做的方式。刚才已经分享过，我们一个叫全自动的，一个叫人工介入的。这是人工介入的一种，全自动当然就是我把所有信息拿出来，然后我就分析，然后分析出来是有结果或者没结果两种情况。有结果它会出报告，没结果它会告诉我为什么没有结果。

还有一种逻辑是对话式的，其实对话，大家跟AI交流的过程中，已经非常习惯对话了。对话的方式是它成为你员工中的一员。我们可以想象，如果出现一个大的公司故障，我们会不会成立一个群，这个群里面是可能是一堆专家，也可能是一群值班人员在等待处理问题，还有可能是一堆领导在督促解决问题。但总的来讲它是一个群，大家在里面说话，有的人说赶紧解决，有的人说我有发现，有的人问这问题到底是谁负责。

这个时候，你就想象里面加了一个机器人，这个机器人就是一边听你们说话，一边给你们提供信息。老板可能问这事谁负责，它就说老板我知道谁谁谁负责。你说我感觉可能是CPU的问题，然后它就回复，应该不是，我刚查过了，几台机器CPU什么情况。它就是你们工作中的一员，它既能反馈给你信息，它也可能会有提问，比如它卡在哪个地方?它说我想知道什么?那没关系，在这次里面可能我没有查到。

所以大家可以看到所有的这个根因分析，它其实有多种模式是可以做的。今天我们看到的是其中一种模式，在CloudWatch Logs Ops里面，大家可以根据自己公司里面的实际情况，选择喜欢使用的方式，或者建立自己想用的AI Ops流程。

好吧，今天我们的分享就到这里，谢谢大家!

总结

亚马逊云科技正在推广一种新的运维思路，利用CloudWatch Logs Insights和生成式AI技术，帮助企业更高效地发现和解决系统问题。这种方法包括以下几个关键点:

1.           通过分析日志模式、异常检测和自然语言查询，快速定位问题根源，减少排查时间。CloudWatch Logs Insights可以发现日志中的新模式、异常情况，并支持用自然语言生成查询语句。

2.           结合知识库和引导式分析，AI能主动提示可能的问题原因和建议。它不仅分析数据，还融入了专业知识，更好地指导问题排查流程。

3.           提供多种AI辅助模式，包括全自动分析、人工介入引导和对话式交互。用户可根据实际需求选择合适的模式，实现高效的运维洞察。

4.           将多源数据整合分析，不仅包括日志、指标和追踪数据，还涵盖部署历史、配置变更等，全面支持问题分析。

5.           通过自动化工具收集和分析数据，让运维人员专注于创新研发，提高工作效率。该方法旨在缩短运维时间，加速系统迭代。

总之，这种新的运维思路利用AI技术赋能CloudWatch Logs，实现更智能、高效的系统可观测性和问题分析，为企业带来运维效率的全面提升。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。