不同于标准的应用开发方法，使用AWS Lambda的无服务计算不便于调试。以下这些工具可以帮助开发人员调试Lambda错误。

开发人员可以用来建立和管理无服务应用程序的AWS Lambda教程、工具和框架已经有一些了。但关于调试Lambda方面的信息还很缺失。

Lambda函数不像标准应用部署。开发人员无法通过SSH连到服务器上查看日志文件，输出或运行测试命令来了解到底哪里出错了。Lambda函数运行在一个即时环境中，启动一个新容器并执行代码，然后在几分钟内快速销毁该容器。虽然一些容器可以被重用，但开发人员无法在函数调用失败时访问容器从而确定哪里出错了。

相反，开发人员必须使用日志记录工具，如Loggly或CloudWatch Logs 加上Kibana，来诊断问题。他们还可以使用像最新开源的AppEnlight这样的工具来管理Lambda的自定义AWS指标。

使用日志管理诊断问题

最简单的选择是使用Amazon内置的CloudWatch Logs；CloudWatch Logs允许开发人员通过内置的控制台搜索日志或者使用Kibana在亚马逊弹性搜索服务（ES）中对日志进行索引。但是，Amazon ES在日志量很大的情况下可能会非常昂贵。

开发人员可以使用CloudWatch Logs，通过CloudWatch指标进行基本的警报和图形化，但这些指标必须被预先设置好。没有办法可以追溯添加AWS指标，和查看指标创建之前的历史记录。此外，许多AWS指标（例如高级的定时功能和基于绘制的图形功能）在CloudWatch Logs中不可用。开发人员如果想要用这些功能的话，只能使用Kibana。

还有一些工具可以用来追踪CloudWatch Logs，如Apex的内置日志功能。此功能允许开发人员在部署完一个应用程序后或试图主动诊断一个问题时，可以近乎实时地查看日志。

最好的选择是使用CloudWatch Logs来访问日志，然后发送JSON格式的日志消息。这些消息将复杂的数据显示在日志中，帮助提供IT团队解决问题所需的信息。但日志往往还不够 - 你无法从日志中跟踪高级的问题，例如函数超时或一个异步函数抛出的异常。

使用AppEnlight进行高级诊断

NewRelic和其他应用性能监视工具对于基于Web的应用诊断非常有用，但那些没法在没有持久状态或任何直接基于Web请求的环境中执行（例如Lambda）。AppEnlight是一个可以为任何应用程序提供性能和错误日志功能的工具，即便不是基于Web的应用。

因为AppEnlight是开源的，所以可以调整。我创建了一个名为appenlight-reporter的NodeJS包管理器模块来帮助检测Lambda函数。在注册一个免费的AppEnlight帐户后，开发人员可以创建一个新的AppEnlight Reporter实例以添加AppEnlight插装：

var AppEnlightReporter = require('appenlight-reporter');

var appEnlight = new AppEnlightReporter({

  api_key: ‘API-KEY',

});

代码插装是指追踪错误报告，资源日志或完成一个操作所需时间的能力。代码插装提供了对特定代码或整个应用程序为什么会花费很长时间来处理或整个失败的详细分析。例如，代码插装会显示接收一个来自MySQL的请求花费了多长时间，以及在此时间内发生了哪些错误消息。一些框架，如NewRelic，提供了代码的自动化插装工具；其他的框架允许自定义事务跟踪，这要求开发人员标记代码块的开始和结束。

DevOps团队可以通过端点选项将报告器配置为直接连接到自定义的托管实例。他们还可以使用默认的标记和一个自定义的server_name。

AppEnlight Reporter可以分析自定义函数调用和AWS指标；还可以直接将错误报告发送到AppEnlight。开发人员可以使用以下代码发送一个自定义指标到AppEnlight：

appEnlight.sendMetrics(‘metricName', [

 [‘tagName', ‘tagValue'],

 [‘numericTag', 0],

]);

Use this code to send error reports to AppEnlight:

使用此代码发送错误报告到AppEnlight：

appEnlight.sendReport({

 view_name: ‘functionName',

 priority: 8, // Should be 0-10

 error: ‘Details of the Error that occurred',

 http_status: 500,

 tags: [

   // Custom tags just like with sendMetrics

 ],

 start_time: start_date.toISOString(),

 request_id: context.awsRequestId,

});

建议开发人员发送context.awsRequestId，因为这有助于将请求与发送的日志对应起来。如果与winston-appenlight包一起使用，日志行将显示在所有发送的错误报告中。DevOps团队还可以使用简单的Lambda函数将所有日志和请求ID一起从CloudWatch Logs发送到AppEnlight，从而简化日志记录的流程。

AppEnlight仪表盘

一旦AppEnlight从Lambda函数那里接收到数据，DevOps团队就可以使用两个主要的功能来诊断问题。Logs的部分允许开发人员对日志进行全文搜索，并通过标签，函数名称和resource进行过滤。

AppEnlight为开发人员提供了一个界面用于检查Lambda日志

开发人员还可以查看日志事件图表，并选择一个标签，添加一个过滤器。

除了Logs以外，AppEnlight还有一个仪表板系统，用于查看自定义指标的统计信息。以下仪表板使用的是自定义指标Created通过New Abstract标签创建的过滤：

AppEnlight仪表板允许开发人员创建自定义指标，例如Abstracts Created。

仪表板还可以有很多图表，将来自AWS指标和日志的统计信息进行合并显示。

AppEnlight有一个错误报告的方法，对于每一个sendReport函数调用，DevOps团队可以查看所有发送的错误以及特定错误发生的次数列表。配置日志，以便与错误报告相同的RequestID一起发送。那些日志会直接显示在错误报告中：

开发人员可以在AppEnlight中检查错误报告的历史记录

AppEnlight的免费托管版本对于接受数据的多少有限制。免费版本可以帮助开发人员熟悉适应该服务，但用户可能必须升级到付费版本才能享受到全部的好处。那些运行自己定制的AppEnlight托管版本的DevOps团队没有数据上的限制，因此对于任何具有大量关键任务数据的应用程序都推荐这种方法。

该开源AppEnlight工具允许用户提交Pull-Requests到代码库来改善性能和测试新颁本。该工具的一个Docker容器版据说正在开发中。