排除API网关错误的故障
调试无服务器应用程序需要转变思路：在传统的应用程序栈中，整个请求-响应周期都存在于你的应用程序日志中。而在无服务器应用中，情况并非如此。你必须自己将API调用和AWS Lambda函数之间的联系起来，而这可能涉及到大量不辞辛苦的腿部工作。
在这篇文章中，我们将向您展示无服务器框架仪表板的最新故障排除功能是如何消除腿部工作的，无论您是无服务器应用开发的新手还是老手。
配置错误的API网关
让我们从一个常见的场景开始：假设你想检查你编写的一个函数的性能。你打开无服务器框架的仪表盘，但你没有看到该函数的调用被调用。你点击了应该触发该函数的API端点，但它回应的是503状态代码：服务不可用。
现在，503错误是很难诊断的。通常情况下，503是由于API网关配置错误造成的。
这可能是由于你的Serverless.yml文件中的缩进不正确，打字错误或间距错误，或者引用了一个不再存在的函数。由于有多种可能的原因，你需要请求和调用日志来确定实际发生了什么。
获取日志可能不是一个简单的操作。首先，APIGW日志和Lambda函数日志并不存储在一起。还记得那个头脑风暴吗？你必须进入收集所有AWS日志的CloudWatch，并分别寻找日志。如果你的应用程序中只有一个API端点和一个Lambda函数，这是一个恼人的不便，但如果你使用的是API网关，而它每秒被几百个请求击中，这就是一个真正的问题。
你可以通过请求ID搜索，但客户在报告问题时并不总是包括请求ID。找到一个没有请求ID的日志，就是不辞辛苦的腿部工作的开始。
有了无服务器框架仪表板的新请求探索器，你可以避开这个痛苦的过程，直接找到你需要的日志和堆栈跟踪。探索器让你可以通过端点、方法、状态代码和时间范围来定位请求。每个请求都会打开一个详细的报告，在那里你可以找到日志，以及一个指向相关函数调用报告的链接。你可以跳过搜索，把所有时间集中在有趣的部分：解决问题。
.png)
畸形的响应
如果你已经开发了一段时间的无服务器应用程序，并且善于避免可能引发配置错误的API网关的常见错误，你仍然可以发现自己在追寻APIGW错误。这里有一个例子。
假设你记录了一个Lambda错误，这样你就可以跟踪它，但你忘记了你必须对APIGW做出回应。同样，你需要进行这种思维转换--你的Lambdas必须与你的APIGW正确链接，当你对Lamdba进行修改时，你必须自己连接这些点：返回的对象需要一个statusCode、body和headers属性。如果你漏掉了一个，或者格式不正确，当你点击它时，APIGW将返回一个 "内部服务器错误"。
使用request explorer，你只需要求向这个端点发出状态码为502的请求，在几秒钟内，你就会进入日志，看到 "畸形的lambda代理响应 "信息，然后你就会重构你的Serverless.yml。
如果没有request explorer，你还是会得到解决的，但如果你是在大规模工作，并且使用APIGW，你将会走很长的路才能达到目的。
今天就试试无服务器框架的请求探索器吧，让你在调试无服务器应用程序时少走弯路。
