【.com快译】众所周知，无服务器（Serverless）应用的优势在于它可以拥有多个功能和服务，这些功能和服务在逻辑上相互分布。但是，随着这些功能和服务的增长，以及各种代理和包装器（wrapper）的加入，这样的应用会变得越来越复杂，维护的成本也会越来越高。因此，我们需要对Serverless应用进行适当的监控，让开发者能够深入到每一次执行和事件的具体细节，更容易发现错误，准确衡量每一次调用所消耗的资源。此外，好的Serverless监控工具也有利于优化应用的开发成本和运行性能。什么是AWSLambda？在这里，我们以AWS的日志和监控工具为参考，先来看看一个好的日志监控系统应该具备的要素：数据信息越详细越好数据采集越频繁越好日志采集不应影响应用程序性能无服务器架构是面向服务架构(SOA)原则的扩展，其中服务（或功能）使用消息（或事件）进行通信。如果使用得当，无服务器架构不仅可以降低代码复杂性，还可以简化应用程序的管理。让我们来看看AWSLambda是什么以及它的用途。作为一项服务，AWSLambda可以在具有预分配CPU、磁盘和内存的容器中运行您的代码。所有这些连同您的代码及其相关配置称为Lambda函数。这些函数能够在运行时响应各种外部事件或触发器。因为是“无状态”，Lambda函数与底层架构解耦，开发者只需要专注于自己的代码，而Lambda负责Serverless应用程序的核心部分。功能即服务（Function-as-a-Service，FaaS-https://dashbird.io/blog/what-is-faas-function-as-a-service/）解决了之前的架构模型从从开发人员的角度来看，有许多问题需要解决，即：具有运行代码的能力，而不管服务器的可管理性、可扩展性和可用性。如果您想了解更多关于不可服务器的全部细节，请参阅无服务器知识库。需要监控什么？监控是通过外部工具和手段将系统产生的可观察数据可视化。大多数情况下，监控的挑战主要是：目标单元多，生命周期短，配置代理直接造成的延迟。因此，在具体实现中，我们可以针对Serverless应用采用有针对性的具体监控方式，也可以采用通用的监控方式，这取决于您的实际需求和所使用的平台。但是，无论采用哪种方式，我们都需要及时了解Serverless应用的各种性能开销，包括：延迟、冷启动、调用错误以及成本和使用情况。下面我们一一探讨。Latency面对大数据集，有些延迟很容易根据用户请求响应时间较长而检测到，而有些延迟可能隐藏在那些平均执行速度下，很难直接检测到。因此，监控延迟的更好方法是构建一个包含所有关键任务功能的自定义仪表板，一旦您检测到某个功能花费的时间比预期的要长，您就需要深入了解其详细的数据指标。作为开发者，我们面临的应用SLA要求往往是：99%的请求可以在1秒或更短时间内完成。因此，仪表板也需要通过测量和统计，以百分比的形式反映某些指标。冷启动Lambda函数通常在Docker容器中运行。第一次调用时，AWS会先“冷启动”一个新的容器，然后在里面执行一个函数。对于那些第一次访问应用的用户来说，很可能会经历几百毫秒，甚至几秒的延迟。初始等待时间过后，函数会保持“热”一段时间。在此期间，新呼叫不会出现延迟，最终用户响应也会更快。但是，当同时处理大量的并发流量时，AWS会扩展更多的容器来处理所有新的请求。这将导致完全不同的冷启动顺序。另外，如果该功能需要依赖弹性网络接口（ElasticNetworkInterfaces，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://文档。aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors。通常，一个典型的企业应用会通过API连接到其他SaaS工具，如果其中一个连接或节点出现问题，就会影响正常的业务逻辑。通过Dashbird提供的严重错误仪表板，我们可以快速了解应用程序第一次和最后一次出现特定瓶颈或错误的根本原因和具体时间。费用和使用量无论是Lambda、AWSS3bucket、VPC、DynamoDB等资源，费用都是和使用量成正比的。然而，当我们使用分布式云服务时，很难及时有效地跟踪资源使用过程中产生的成本。因此，在具体实施中，我们往往需要采用以账户级监控为主，功能级监控为辅的方式。例如，我们可以使用Dashbird应用统计从12小时到1个月的时间跨度，根据每5分钟采样的详细信息视图，进而发现目标应用中的使用趋势和成本异常。如果您想了解更多无服务器监控的最佳实践，请参考--https://sls.dashbird.io/en/serverless-best-practices。监控工具--AWSCloudWatch是Lambda的内置工具。AWSCloudWatch根据功能、版本和容器类型组织日志，并在日志中包含运行时、容器错误和时间戳。当然，Lambda还会为每次调用添加各种元数据。通过收集和跟踪各种指标，CloudWatch日志可以提供资源使用情况、应用程序性能和运行状况的基础设施范围视图。同时我们可以使用自带的AWSCloudwatchAlarm来设置各种指标告警和复合告警。从这里，您可以了解目标应用程序正在使用的CPU和内容。更重要的是，您还可以通过预定义的事件设置阈值，一旦达到或接近该值就会触发通知。因此，我建议大家在构建第一个FaaS应用时，以CloudWatch作为监控和跟踪的起点，等用户和请求量达到一定量级后再引入更全面的工具。问题管理和团队合作任何云应用程序，即使是最简单的应用程序，也会经常产生一定数量的事件和问题，尤其是那些不断开发和迭代的。因此，为了让开发团队能够有效地理解和解决问题，监控平台需要将各种未解决的、已解决的、暂时忽略的问题以一种友好的方式进行可视化和管控。通过设置和提供清晰的工作流程，团队将能够更顺畅地沟通并提出切实可行的解决方案。质量跟踪在监控过程中，重要的是快速可视化事件在过去是如何发生的。它不仅可以帮助我们进一步调查情况，还可以帮助我们发现错误的修复方法。通过这种可追溯的质量跟踪，我们可以避免在初始开发和纠错过程中犯同样的错误，同时还可以通过创建持续的自动化学习和评估方法来提高应用程序的质量和性能。事件驱动调试开发人员是监控程序的创建者，但他们并不负责持续监控自己在生产环境中的应用日志。那么，面对海量的应用日志，监控系统需要能够在不遗漏关键内容的情况下提供自动化告警服务。也就是说，我们需要通过自定义告警功能来成功实现监控和错误调试。在实际应用中，告警机制不仅需要能够检测到应用程序的错误，还需要能够发现架构本身可能间接影响应用程序的缺陷。比如在AWSLambda中，可能会出现包括超时、容器崩溃、内存耗尽等事件，那么我们就可以使用Dashbird的自动告警服务。详情请参考——https://dashbird.io/features/automated-alerting/。此外，对于系统中的容错组件，开发人员可以禁用单个问题警报并仅设置聚合指标。因此，他们不仅可以获得真正需要的信息，还可以专注于应用程序调优。总结如今，大多数开发团队也在使用Slack等即时通讯服务，以更快、更简单、更方便的方式专注于无服务器应用程序的开发和调试，实现即时警报和更快的响应修复。这正是我们正在监控的无服务器应用程序。原标题：无服务器应用监控终极指南，作者：TaaviRehem?gi
