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

本文获文章做者受权翻译，转载须要注明来自公众号EAWORLD。

做者：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关注他。

他的推特意址是：https://twitter.com/proudboffin

关于EAWorld

微服务，DevOps，元数据，企业架构原创技术分享，EAii（Enterprise Architecture Innovation Institute）企业架构创新研究院旗下官方微信公众号。

微信号：eaworld，长按二维码关注

8月-9月，PWorld系列技术趴还将继续上演。目前，9月24日将在上海举行PWorld MeetUP“微服务的编排、配置与12要素专场”已启动报名，戳“阅读原文”可直达报名页面，并了解更多详情~

PWorld软件架构&平台创新大会：由普元发起主办的全国顶级技术盛会，探讨“数字化时代的企业软件变化与创新”推动中国企业在数字化时代的成功转型，积极为CTO、CIO、架构师、技术经理、开发工程师等技术相关人员设计各项议题，演讲嘉宾从企业软件、人工智能、区块链、云计算、大数据、业务流程、移动开发等热门话题中，分享他们的技术看法和最佳实践。同时，PWorld在企业级技术会议里独开“交互式体验”先河、赋予参会者最大程度尊重，带给现场以及线上的听众以全新的参会体验。

本文分享自微信公众号 - EAWorld（eaworld）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。