无服务器架构中的日志处理

作者：Daniel Berman

译者：海松

原标题：Logging in a Serverless Architecture

无服务器架构中的日志处理会遇到诸多挑战，让我们就此作一番探究，同时也了解 ELK Stack（使用 Kinesis Firehose）是如何解决这些问题的。

在我们以前的文章中，有一篇内容是关于 NASA 同一艘飞船进行通讯联系的，那艘飞船被派往火星，主要任务是研究和探测火星的气候、大气以及行星表面。最后，NASA 宣布与那艘火星气候探测飞船失去联系，而在此前的24 小时中，NASA 的工程师们曾想尽办法联系一个早已不存在的对象。

在无服务器架构运行模式下，函数及其容器在数秒钟内便完成开启和关闭，除非能及时捕捉，否则和上面提到的例子相似，我们将不可挽回地丢失其确定和不确定的状态以及其它信息。

无服务器架构促使开发人员编写出快速、独立和可执行的代码，这些代码由事件触发并驻留在临时容器内。不过，如果其中某一个函数未能如期运行会出现什么情况？DevOps团队人员如何确认相应事件是否激活了对应的函数？

在无服务器应用程序中，各服务趋于小型化且分工精确，这让追根溯源变得异常复杂。在查找故障源时，相关服务和这些服务的集成点可能根本不存在。当操作涉及超过一个函数时，查找故障源就像在黑夜中寻找猎物一般困难。

要查看无服务器应用程序的运行情况，以及故障时会发生什么，最重要的就是记录日志。

1.为什么需要进行无服务器日志处理？

对开发人员来说，日志的必要性是显而易见的，但具体到无服务器架构日志记录，仍有一些特殊情况需要考虑。

显然，当数个函数发生故障导致其无法提供所请求的功能时，为了能分析不同函数的日志，日志中必须包含事务唯一识别符，只有这样才能方便地发现和汇集事务。在无服务器应用程序内，相同的日志必须包含参与操作的所有函数的更多信息，包括响应值和运行次数。

如果一项函数在运行期间发生崩溃，其实例和容器在崩溃后也不复存在，那么崩溃日志记录对于了解问题所在至关重要。现在的关键是，我们如何记录下崩溃日志，我们又如何从一项业已失效的函数中得到这些日志呢？这就要求我们具备创造型思维。

有种值得注意的解决方案，即创建一个函数，它在另一项函数崩溃时会被触发，或者从根本上说，它与其他各函数是关联的。该函数负责收集容器中的所有信息，包括崩溃前的所有记录，由基础架构引发的事件可以触发该函数，而且通过配置可使其能够触发崩溃函数的另一个实例。利用这种方法，在无人工干预的情况下，通过对故障的及时响应和恢复，日志可以由无服务器应用程序实现自我维护。

无服务器日志在应用程序检查中还具有其它重要作用。当云应用程序遭到恶意软件或者黑客攻击时，利用日志可以轻而易举地检查服务负载、识别滥用服务的企图。在无服务器环境中，服务执行不但很短暂，而且它也将自动伸缩作为其目标，因此识别和处理上述攻击活动便成为一项现实的挑战。在攻击发生时，良好的规划、专业的日志记录以及合适的分析工具，可以识别出攻击类型，同时找出正在遭受攻击的函数并对其采取恰当的保护措施。

无服务器架构会面临另一个软件方面的重大问题——即无状态。有时各项函数的存续的时间仅为几秒钟，因其容器状态无法得以保留，从而造成在后续调用相同函数时，该函数无法访问之前运行的数据。对于这个问题，有一些不同的解决方案，其中有些方案要求集成外部工具，而另一些则要求实现一个专门设计的无服务器框架。

日志则可以相当轻松地解决这一问题。集中备份的函数日志起到了存储介质的作用，可以授权函数访问此前的运行数据，如果不这样处理，这些数据本来是要被丢弃的。函数可以基于先前的事件对应用程序状态作出评估，而非仅仅基于应用程序的当前状态。

2.那么，应该如何在

无服务器环境下记录日志呢？

通常，应用程序服务日志存放在其容器的本地磁盘内。当基于云的应用程序增长扩容之后，访问、管理和分析这些日志会是一件相当复杂的工作。如果不使用合适的工具，要遍历保存在几百台服务器上的数百份日志文件，来搜寻某个特定的错误，其困难可想而知。

所以一般需要使用基于文件复制或者 syslog 的技术，来制定中心化日志解决方案。在无服务器架构中，日志必须存放于中心服务器，以便于在函数和容器关闭后还能够保存并分析其数据。

以 AWS Lambda 为例，作为一套中心化的日志管理解决方案，ELK Stack用于采集和分析函数日志。ELK Stack（Elasticsearch、Logstash 和Kibana）不仅使DevOps团队具备了采集、储存和分析日志的能力，还可以据此构造出视图或者数字仪表盘，以突出显示重要信息，来为函数实现及功能提供决策上的依据。

由于能够提供清晰的应用程序状态视图，并能协助有关人员对相关故障点进行追根溯源，ELK Stack中的三大组件在许多 IT 组织得到了广泛应用。

2015 年岁末，AWS 推出了一项名为 Kinesis Firehose 的数据采集和传输解决方案，该方案允许用户从应用程序内的所有日志中采集数据，并将这些数据传输至 Amazon S3 或者 Redshift。

Elasticsearch 为原始数据建立索引并对这些数据进行分析，用户借此可以查询到任何重要的业务信息。Kibana 根据预定义的规则，将结果直观地呈现给用户，因此组织内的不同团队可以获得生产环境所需的特定视图。

在无服务器架构中，一套基础 EKK（Elasticsearch、Kibana 和 Kinesis）Stack 应该如下图所示：

作为替代方案，如果您不希望管理AWS 上的 Elasticsearch 和Kibana，可将Kinesis Firehose 构造的日志流传输到 Logz.io 的S3服务，实现Kinesis Firehose 同诸如 Logz.io 的这样的托管式 ELK 解决方案的结合。该项解决方案可向您提供全套的管理服务，您则无需关心Elasticsearch 伸缩、解析函数日志或者 保护Kibana 安全等管理任务。

3.结论

尽管减少了维护工作量、实现了可伸缩性规划、降低了服务器管理成本，但在调查系统故障、查找故障原因中引入无服务器应用程序，对于研发人员和运维开发人员来说仍是一项新挑战。日志显示了各函数和其容器的功能和二者间的关系。我们必须利用各种专用工具才能将所有信息从生产环境传输至研发团队，以帮助他们完成维护任务。

必须将无服务器日志的采集和对分析工具的流传输当作函数执行的一部分，只有这样我们才能在容器关闭后不会丢失数据。鉴于无服务器架构鼓励快速执行，日志采集任务也必须随之做到迅速及时。很多无服务器开源框架（主要是 AWS Lambda，也包括 Azure Functions）都深知这种复杂性，因此它们都带有日志采集解决方案。尽管如此，以上方案均不够简单，所以在无服务器构架中的日志处理技术依旧任重而道远。

原文链接：https://logz.io/blog/logging-serverless-architecture/

关于作者

丹尼尔·伯曼（Daniel Berman）是Logz.io的产品传播者。他热衷于日志分析、大数据、云计算、家庭，爱好跑步、利物浦足球俱乐部，以及写写关于颠覆性高科技东西的文章。在推特上@proudboffin关注他。