跟踪虚拟服务器应用程序中的API网关指标

 虚拟服务器     |      2019-09-28 10:32:41

  成千上万的开发人员正在使用无服务器技术来构建Web API。诸如无服务器框架之类的工具使使用AWS Lambda,API Gateway和DynamoDB之类的基础架构轻松构建,即可构建REST API和GraphQL API。

  但是,监视这些API仍然有些麻烦。AWS提供的开箱即用的监控系统无法提供检查API所需的粒度,尤其是当故障可能跨越多个系统时。

  在本文中,我将向您展示一种使用Serverless Framework的新完整生命周期功能来监视无Server Web API的简便方法。

  首先,我们将介绍使用本机AWS工具很难理解API性能的三个原因:

  Lambda错误不会映射到HTTP错误

  在Lambda之外,您的请求有很多地方可能失败

  API Gateway指标不允许您深入研究根本问题

  在检查了问题之后,我将向您展示如何使用无服务器框架和计划中的一些其他功能来解决此问题。

  让我们开始吧!

  问题1:Lambda错误不会映射到HTTP错误

  如果您有使用AWS Lambda构建服务的经验,那么您可能对CloudWatch Logs和CloudWatch Metrics很熟悉。CloudWatch的伟大之处在于它与Lambda功能自动集成。您无需进行任何检测就可以使日志流动。

  也就是说,CloudWatch落后于该领域的其他监视工具。即使您是CloudWatch专家,Lambda和API Gateway之间也存在一些差距,这使您很难理解您的应用程序行为。

  传统Lambda监视的第一个问题是Lambda错误并不总是映射到HTTP错误。

  要了解我的意思,请看下面的示例代码。

 

  Lambda处理程序

  这是getUser我的应用程序中的一个端点,在这里我使用idHTTP路径中的参数来获取User对象并将其返回给客户端。

  请注意,在9-15行中,我有一个catch捕获任何错误并返回500状态代码错误的块。通过捕获此错误,我可以更轻松地为我的API客户端提供返回状态代码和可能有意义的错误消息的工具。

  但是,我也对我的应用程序运行状况失去了一些了解。如果我的DynamoDB表发生故障,而我无法读取任何用户记录,则每个用户都将收到错误并看到500状态码。但是从我的Lambda应用程序的角度来看,似乎一切都很好-没有错误!

  作为开发人员,我不仅对我的Lambda函数在返回客户端之前是否成功处理了所有错误感兴趣,而且还感兴趣。我还关心调用的面向用户的结果-客户端是否能够执行所需的操作?

  问题2:您的请求可能会在Lambda以外的许多地方失败

  传统Lambda监控失败的第二个方面是,除了Lambda功能外,还有许多API网关可能会失败的地方。在向Lambda函数发出请求之前,甚至在函数成功完成之后,您的用户都可能会遇到错误。

  API网关具有大量功能,可为您的API处理提供超级动力。如果您利用这些功能,则可能看不到用户看到的错误。

  例如,您可以在API端点上添加请求架构验证,以拒绝任何与所需架构不匹配的请求。

  同样,您可以将自定义授权者添加到端点,以要求在单击Lambda函数之前进行授权。

  在上述每种情况下,用户甚至都不会在仪表板上看到Lambda调用而看到错误。在前者中,他们会收到一个400 Bad Request错误,而在后者中,他们会收到一个401 Unauthorized错误。

  此外,即使您的请求到达Lambda函数并成功完成,您也可能弄乱了响应格式的形状。结果,由于500 Internal Server Error响应,您的用户将看到一个损坏的应用程序。

  在每种情况下,基本的Lambda指标和日志都无法帮助您意识到用户面临错误。

  问题3:API网关指标不允许您深入研究根本问题

  让我们切换到房屋的API网关一侧。您可以使用CloudWatch指标查看API网关级别的指标。这些将通过应用程序中的资源和方法显示2XX,3XX,4XX和5XX状态代码的数量。

  困难在于调试您的请求以找到根本原因。

  当您部署一些错误的配置时,对于一个过于严格的请求架构,它会导致400个错误的峰值,那么您如何深入研究适用的请求以发现问题呢?

  当数据库崩溃并导致500个错误时,如何找到指示问题的堆栈跟踪?

  在第一种情况下,您可能需要启用API网关访问日志,并需要某种系统来处理这些日志,以备以后使用。在第二种情况下,您要么需要使用某种应用程序错误平台来检测代码。 ,否则您需要将Lambda登录处理到外部系统。

  我们如何解决这个问题

  在以上各节中,我们指出了当前使用CloudWatch Metrics的单独方法的一些问题。

  为了解决这个问题,您需要对您的应用程序有一个更全面的了解。尽管您可能会在逐个功能的基础上考虑无服务器应用程序,但其中涉及的不仅仅是功能。

  您需要一种基于结果查看端点的方法-用户的最终结果是什么?-仍然能够深入到特定的调用以查看错误。

  如果我的createUser端点出现了500个错误,这是什么原因?是因为我无法访问Lambda函数中的关键服务,还是因为我的响应格式错误?

  如果我的getOrder端点有401 Unauthorized错误,是因为请求没有授权标头,从而使自定义授权者失败,还是因为经过身份验证的用户无权访问所请求的特定订单?

  无服务器框架为此提供了解决方案,使您可以在30,000英尺的高度查看端点,并深入了解详细信息。

  首先,您可以在函数调用错误旁边看到端点错误。记住我们上面讨论的内容-Lambda函数有可能成功返回,但端点会向用户显示错误。此视图使您可以查看两种错误源。

  API网关和功能错误

  如果您想更深入地研究某个特定的错误,请单击以查看完整的故事。您可以获得API网关指标,功能指标,日志,甚至是堆栈跟踪。在一个地方,您可以看到单个请求发生的所有事情,从而使调试变得更加容易。

  我们为此功能制定了很多计划。我们将添加一个图表浏览器,您可以在其中为满足某些参数的所有请求构建图形。是否想查看getUser今天中午到下午1点之间所有请求到您的端点的状态代码分布?没问题!

  使用过滤器发现图形问题之后,请在我们的调用浏览器中使用相同的过滤器查找有问题的调用。查找引起问题的确切调用,并查看日志和API Gateway指标以调试根本原因。

  这就是需要的-一种识别和诊断应用程序中问题的统一方法,而不是通过次要搜索界面将一大堆分散的资源和粘贴ID拼凑在一起。