51CTO|如何监控无服务器应用


北京联盟_本文原题:如何监控无服务器应用
51CTO|如何监控无服务器应用
本文插图

众所周知 , 无服务器(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)与其他服务进行通信 , 那么延迟还会增加 。


推荐阅读