如何监控无服务器应用

什么是AWS Lambda?

在此，我们以AWS的日志记录和监控工具为参照，首先来看看一套良好的日志监控系统所应该具备的要素：

• 数据信息越详细越好
• 数据的采集越频繁越好
• 日志收集不应影响应用程序的性能

无服务器架构是面向服务架构(SOA)原理的扩展，其中服务(或称功能)采用消息(或称事件)进行通信。如果使用得当，那么无服务器架构不但可以降低代码复杂性，而且能够简化对于应用程序的管理。下面让我们来了解一下有关AWS Lambda的概念及其用途。

作为一项服务，AWS Lambda可以将您的代码运行在某个已经预先分配好CPU、磁盘和内存的容器中。所有这些，连同您的代码、及其关联的配置被称为Lambda功能函数(function)。这些功能在运行时能够响应各种外部事件或触发器。由于它是“无状态(stateless)”的，因此Lambda功能与底层架构解耦，开发人员只需专注其代码，而由Lambda来负责无服务器应用的核心部分。

功能即服务(Function-as-a-Service，FaaS - https://dashbird.io/blog/what-is-faas-function-as-a-service/)从开发人员的角度，解决了过往架构模型需要处置的许多问题，即：无需考虑服务器的管理性、可扩展性和可用性，即可具有代码的运行能力。如果您想了解更多有关无法服务器化的整个详细知识，请参考无服务器知识库。

需要监控什么?

监控，就是通过外部工具和手段，让由系统产生的、可观测的数据可视化。在大多数情况下，监控所面临的挑战主要是：目标单元多、生命周期短、以及由配置代理所直接导致的延迟。因此，在具体实现中，我们既可以对无服务器应用采取有针对性的特定监控方式，也可以使用通用的监控办法，具体则取决于您的实际需求和所使用的平台。

不过，无论采取哪种方式，我们都需要及时获悉无服务器应用的各项性能开销，其中包括：延迟、冷启动、调用错误、以及费用与使用量等方面。下面我们将逐一进行讨论。

延迟

在面对大型数据集时，有的延迟很容易根据较长的用户请求响应时间而被发现，而某些延迟则可能隐藏在那些平均执行速度之下，很难被直接检测到。因此，监控延迟的一种较好的方法是：构造一个包含了所有关键任务功能的自定义仪表板，一旦检测到某个功能的用时比预期更长，则需要深入查看其详细的数据指标。

作为开发人员，我们所面对的应用SLA需求往往是：让99%的请求都能够在1秒钟或更短的时间内完成。因此，仪表板还需要通过测量和统计，以百分比的形式反映某些指标。

冷启动

Lambda功能函数往往会运行在Docker容器之中。在首次调用时，AWS会首先“冷启动”一个新的容器，然后在其中执行某项功能。这对于那些初次访问应用的用户来说，很可能会感受到几百毫秒、甚至是几秒钟的延迟时间。在初始等待时间过后，该功能函数会在一段时间内保持“活跃(warm)”的状态。此间，新的调用既不会遭遇延迟，最终用户的响应也会比较快。不过，在应对同一时刻的大量流量并发时，AWS会通过扩展更多的容器，来处理所有新的请求。而这将导致完全不同的冷启动序列。此外，如果功能函数需要依赖于弹性网络接口(Elastic Network Interfaces，ENI-- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)与其他服务进行通信，那么延迟还会增加。

可见，在大多数情况下，我们需要避免出现冷启动现象。不过，云服务平台通常不会直接提供针对应用程序栈的冷启动检测和监控。我们需要借用Dashbird(https://dashbird.io/features/)之类的监控服务，来发现目标架构中值得改进的地方。如果您想了解更多有关如何解决冷启动问题的介绍，请参考--https://dashbird.io/blog/can-we-solve-serverless-cold-starts/。

调用错误

有时候，在功能函数接收到调用请求之前，该请求就已经被拒绝了。而且，此类调用错误会让Lambda返回400或500系列的HTTP状态代码。具体请参见常见错误的列表--https://dashbird.io/knowledge-base/logging/lambda-invocation-function-and-runtime-errors/，或完整的调用错误列表--https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors。

通常，典型的企业应用会通过API连接到其他SaaS工具上，如果其中的某个连接或节点出现了问题，则会影响到正常的业务逻辑。我们可以通过由Dashbird提供的严重错误仪表板，来快速了解应用程序在第一次和最后一次发生特定瓶颈、或错误的根本原因和具体时间。

费用与使用量

无论是Lambda，还是AWS S3存储桶、VPC、DynamoDB等资源，其费用都是与使用量成正比的。而我们在使用分布式云服务时，很难有效且及时地跟踪资源在使用过程中所产生的花销。因此，在具体实现中，我们往往需要采取以帐户级别监控为主，功能级别监控为辅的方法。例如，我们可以使用Dashbird应用来统计从12小时到1个月的时间跨度，按照每隔5分钟抽样一次的详细信息视图，进而发现目标应用中的使用趋势和费用异常。如果您想了解更多有关无服务器监控的最佳实践，请参考--https://sls.dashbird.io/en/serverless-best-practices。

监控工具--AWS CloudWatch

作为Lambda的内置工具，AWS CloudWatch会根据功能、版本和容器类型，来组织日志，并在日志中包含运行时、容器错误、以及时间戳。当然，Lambda也会为每次调用添加各种元数据。通过收集和跟踪各类指标，CloudWatch日志可以提供有关资源使用情况、应用程序的性能、以及运营状况的等基础架构范围内的视图。

同时，我们可以使用其自带的AWS Cloudwatch Alarm，来设置各种指标警报和复合警报。据此，您可以获悉目标应用正在使用的CPU和内容的情况。而且，您还可以通过预定义事件来设置门限值，一旦达到或接近该值，就会触发通知。因此，我建议您在构建第一个FaaS应用程序时，就将CloudWatch作为监控和跟踪的起点，而当用户和请求数大到一定数量级时，再引入更加全面的工具。

问题管理与团队合作

任何云端应用程序，即使是最简单的，也会频繁地产生一定数量的事件与问题，尤其是那些正在不断开发与迭代的应用。因此，为了能让开发团队有效地获悉和解决问题，监控平台需要以用户友好的方式，可视化和控制各种未解决、已解决、暂时可以被忽略的问题。通过设置和提供清晰的工作流程，团队将能够更流畅地沟通，并提出切实可行的解决方案。

质量跟踪

在监控过程中，快速可视化某个事件在过去所发生过的状况是非常重要的。它不但能够帮助我们就某种情况开展进一步的调查，还可以协助我们发现针对某个错误的修复方法。通过此类回溯性的质量跟踪，我们可以避免在初始开发和错误纠正的过程中犯同样的错误，同时也能通过创建持续的自动化学习和评估方法，来提高应用的质量与性能。

事件驱动的调试

开发人员虽然是监控程序的创建者，但是他们并没有责任在生产环境中持续监控自己的应用日志。那么面对大量的应用日志，监控系统就需要能够在不错过关键内容的前提下，提供自动化的警报服务。也就是说，我们需要通过自定义警报功能，来成功实现监控和错误调试。

在实际应用中，警报机制不仅需要能够检测出应用程序的错误，还要能够发现可能间接影响应用的架构自身缺陷。例如在AWS Lambda中，可能会出现包括超时、容器崩溃、内存耗尽等方面的事件，那么我们就可以采用Dashbird的自动化警报服务，具体请参见-- https://dashbird.io/features/automated-alerting/。此外，对于系统中的容错组件，开发人员则可以禁用单个问题警报，只设置汇总之后的指标。据此，他们不但可以得到真正所需的信息，还能够将注意力放在应用调优上。

小结