【51CTO.com快译】众所周知，无服务器(Serverless)应用的优势在于它能够拥有多个在逻辑上彼此分布的功能与服务。不过，随着这些功能和服务的增长，以及各种代理和包装器(wrapper)的添加，此类应用会变得越来越复杂，而且维护的成本也会越来越高。因此，我们需要对无服务器应用采取恰当的监控，以便开发人员能够深入地了解每次执行和事件的具体细节，更容易地发现错误，并可以准确地衡量每次调用所消耗的资源。此外，良好的无服务器监控工具也有益于优化应用程序的开发成本和运行性能。
什么是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/。此外，对于系统中的容错组件，开发人员则可以禁用单个问题警报，只设置汇总之后的指标。据此，他们不但可以得到真正所需的信息，还能够将注意力放在应用调优上。
小结
如今，大多数开发团队也在使用Slack之类即时消息服务，以更快捷、更轻松、更方便的方式，专注于无服务器应用的开发与调试，实现即时的警报和更快的响应修复。这也正是我们监控无服务器应用的意义所在。
原标题：The Ultimate Guide to Monitoring Serverless Applications，作者: Taavi Rehemägi
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
