导语 | Serverless 环境给DevOps和开发团队带来了复杂性和可观察性方面的挑战。在分布式系统里，为这些现代环境建立可观察性策略是至关重要的，以便快速识别、排除故障和解决问题。本文由 Epsagon Director of Engineering Gal Bashan 在 Techo TVP 开发者峰会 ServerlessDays China 2021上的演讲《Observability in Serverless Environments》整理而成，带大家回顾可观察性、它的关键因素（指标、日志、跟踪、警报等），以及如何在微服务和无服务器中实现可观察性。
点击可观看精彩演讲视频
一、 监控与日志
大家好，我是Gal Bashan，是Epsagon的技术总监。Epsagon是一家初创公司，专注于现代分布式应用程序的可观测性，无论应用是建立在无服务器、微服务、Kubernetes、ECS还是类似的现代技术上，我们都想帮助你了解你的生产情况如何。在此之前，我在以色列国防军做了很多很酷的网络安全工作，这是我的推特和去日本旅行时的照片：
今天我想和大家讨论无服务器的可观测性和分布式环境。在无服务器之前的世界里——容器、机器和物理服务器的世界里，监控、记录和可观测性是如何产生的？然后，我想聊一下云的演进趋势，以及随着这些趋势的变化，都带来了哪些和可观测性相关的问题。接着，我们将讨论一下分布式跟踪，它是解决这些新问题的一个很好的解决方案。最后，我们将讨论监控的最佳实践，以及让你的无服务器系统具有可观测性的最佳实践。
那么让我们来谈谈传统的监控。回到无服务器被发明和重新被发明之前的日子，在出现任何类型的ECS或Docker之前，人们会基于实际的物理服务器来构建他们的应用程序。应用程序如何运行基本上是由这些服务器发出的不同指标定义的。比如消耗了多少CPU？使用了多少内存？服务器收到了多少请求等等？
因此，如果人们想知道应用程序如何运行，解决方案相对简单，只需在运行应用程序的机器中放置一个代理即可。然后，这个代理可以收集主机数据、不同的指标，将其报告给其他解决方案或本地解决方案，并将其显示给用户，这样我们就可以了解服务器的真实运行情况了。
然而，当故障和问题发生时，只有监控是不够的，人们需要故障排除的能力。仅依赖于这些监控指标是不够的，因为指标只会告诉你存在问题，但是你更希望知道如何解决这个问题。所以我们发明了另一种东西，那就是日志。 现在，你可以在应用程序中打印你想要的任何内容，如请求的上下文、与数据库的交互，或与应用程序有关的任何其他内容。然后，你可以在以后查看这些日志来了解应用发生错误时的实际运行情况，并掌握如何处理这个错误的方法。这意味着，如果我们在托管服务器上运行，我们要做的基本上就是设置另一个代理，让它收集所有日志，以便我们日后浏览。 人们对这个解决方案非常满意，因为这个系统相对简单，它有一个主要组件，所有代码都在里面。如果出现问题，指标会告诉我们，然后我们可以立刻进行故障排除，因为所有日志都在一个地方，所有和这个单体应用相关的日志都汇总在一起，我们可以浏览日志，了解正在发生的事情。
二、云计算带来的现代应用挑战
让我们从过去快进到现在。今天，我们的应用通常不会直接在物理服务器上运行，至少对于云原生的现代化应用来说是这样，我们更希望使用托管的解决方案，无论是无服务器、容器还是Kubernetes、ECS，甚至像Fargate这样的东西，都帮助我们将基础设施的管理负担转移给了云厂商，从而让我们能够专注于构建自己的业务逻辑。
原因是，让我们赚钱的、成为一家公司的东西，是真正可以给世界带来价值的业务逻辑，而不是处理服务器运维工作，也不是管理API网关的动态伸缩。作为一家公司或开发人员，我们的核心价值是为客户带来价值。因此，如果我们能够减少管理基础设施的这些工作，将可以进一步促进业务增长，让产品更加贴近我们的客户，然后，我们可以借助这些现代化的技术加速研发速度，更快地交付更好的产品。我想这也是为什么你们所有人今天都来参加 Serverless Days峰会的原因，因为你想了解如何利用无服务器技术——这项由不同云服务商提供的伟大的技术，以便构建更快、更好的解决方案。但是这种解决方案的问题在于，它们与我们构建的传统的应用程序非常不同，这类解决方案具有独特的特点，使它们更难进行故障排除和监控。概括来说，这些解决方案很难观测，很难让你真正了解应用程序在运行时都发生了什么，也无法让你有足够信心知晓问题发生和问题修复。
这其中有很多原因，如果你在考虑像AWS Lambda或ECS这样的解决方案，基本上会有数千个容器或无服务器功能，它们彼此交互，不管是同步还是异步的。因此，当你想要查看指标或日志时，仅查看特定组件的指标或日志是不够的，你需要把系统作为一个整体来看待，因为每个用户请求和数据都要经过系统很多不同的组件来处理。最重要的是，你可能不仅仅使用了一家云厂商的服务，例如，你可能在亚马逊上运行，使用AWS Lambda（很抱歉，我所有的例子都是基于亚马逊的，这只是我习惯使用的环境。当然，任何云都有类似的服务。），并且想要对应用程序进行故障排除，但是你的应用程序正在接受付款，使用Stripe（海外知名网络支付平台）作为第三方API来处理付款，那么，仅仅解决你自己的代码故障是不够的。
仅仅看Lambda中的代码、日志、监控指标等还远远不够，你需要能够对不同服务提供商的API调用情况进行故障排除，比如这个例子里的 Stripe，这样你才可以完全了解系统中发生了什么。即使是你的服务使用同一个云厂商或软件服务商，也会有类似的问题，因为很多代码不需要你自己构建。这原本是一件好事，因为你不需要重新构建一个队列系统，只需使用SQS（AwS 消息队列服务）即可，甚至你都不需要构建这种队列机制，直接使用Google PubSub即可。但问题是，这部分逻辑原本是你负责的，现在变为由云厂商负责，然后提供给你使用，但是如果你使用的方式有问题，或者云厂商的提供的用法有问题，你仍然需要保持警惕，因为这是你的应用程序的一部分，而不仅仅是一个外部服务依赖，这是支撑业务逻辑正常运行的核心组成部分。
例如，如果你正在处理大量数据，而你的Kafka流或Kinesis流（AwS流数据处理服务）停止工作，仅仅说“这不是我的问题，这是AWS的问题”，这还远远不够，因为你的应用程序正由此而受到影响。你必须尽快排除故障并了解这是根本原因，并尽你所能采取一切措施，以便更快地解决问题并把损失降到最低。
因此，在新的分布式环境中，我们现在面临着许多挑战，当一切都在我们的控制之下时，所有的东西都集中在一个地方时，就没有这样的挑战，指标和日志足以满足我们的需求。但现在我们需要一种新的解决方案，需要一种在现代化的架构中，将各个系统连接起来的方式。它将帮助我们获得可观测性和可见性，以便我们了解应用运行的实际情况。
三、分布式跟踪
这个解决方案就是分布式跟踪。我们希望使用跟踪来查看应用程序中的完整流程，那么怎么才能达成呢？ 解决方案相对简单，实际上，有很多专门用于此解决方案的开源工具。最初由Uber开发的Jaeger和Zipkin，我认为早在10年前甚至更久以前，他们就开始意识到这是分布式系统中的一个实际问题，他们想要提供一个很好的解决方案，最初是为公司内部提供解决方案，后来开源给了整个社区。从某种程度上来说，CNCF（云原生计算基金会）实际上决定采用类似的解决方案。在此之前，我们有OpenTracing，这是一个供应商中立的解决方案，还有之前的OpenCensation，另一个供应商中立的解决方案，也和分布式追踪有关。
今天，CNCF实际上正在开发分布式追踪的最新技术 OpenTelemeter，它被认为是OpenTracing和OpenCensus的结合体，为你提供API和SDK，以便以厂商中立的形式将分布式跟踪添加到你的应用程序中，OpenTelemeter 已经对接了多个云厂商。 因此，为了设置这个分布式跟踪系统，你需要两样东西。首先，你需要在代码中嵌入生成Trace数据的能力，你必须深入代码细节，然后进行标识，这个Lambda函数是由HTTP方法触发的；然后这个Lambda函数从时间X运行到时间Y，执行期间做了一个数据库操作，把一个文档存放Dynamo DB中，需要用类似的方式对所有代码进行分段处理。这是第一部分。
这些东西产生了Trace数据，然后它们被报告给了Tracing系统的后端，例如Jaeger和Zipkin就是Tracing系统的后端。然后，后端获取这些Trace数据之后，将它们关联起来，并提供一个UI来显示它们。例如，这是Jaeger UI，如果一切都设置正确，你可以在应用程序中看到不同服务的完整流程。
因此，你可以看到，前端正在发出几个请求，有一个Redis请求，并在之后又发起了其他请求，最后完全设置成功。但是一开始的时候其实很难设置，产生Trace数据是一件比较困难的事情。标识应用程序中正在进行的所有操作非常耗时，还可能导致大量人为错误。 另一件相对困难的事情是关联ID的注入和提取，基本上，你必须自己管理整个跟踪流程。因为分布式跟踪背后的技术逻辑，是在不同计算单元之间传播ID。这样当后端接收到所有不同的数据时，可以将所有内容关联到同一事件。
四、监控的最佳实践
现在，虽然通过使用比使用OpenTelemetry这样的SDK，注入和提取这些ID相对要容易一些，但仍然需要大量的手动工作，你必须更改代码才能做到这一点。所以我认为，我们要找到一种解决方案，可以和不同的云端环境、云端服务集成，可以自动识别不同的应用框架，自动生成大部分Trace数据。此外你还需要一个强大的UI来可视化轨迹，无论是火焰图形还是时间线。另外，在图表中，你希望能够看到应用程序内部使用了哪些资源。最后，也许还有很多重要的因素，因为你一定还希望这些解决方案提供更多的功能，比如监控预警等等。
所以我想说的是，当你达到成熟和大规模的时候，自己管理和开发这种后端可能会有很大的开销。因为这是无服务器峰会，我猜你们中的大多数人都不想关心基础设施，只关心交付商业价值。但你投入开发的东西可能与核心商业价值无关。当你的企业达到一定的规模时，我建议当你考虑分布式追踪的工具时，要进入购买模式，而不是进入维护模式，只是因为它需要大量的维护和在这个特定领域的大量专业知识才能正确完成，这样当你遇到异常或错误时，拥有有效监控和排障所需的所有数据。
简短地总结一下，我猜你们中的大多数人今天在这里是因为关心无服务器环境，如果你谈论的是无服务器思维，那么最好的做法可能是将重点放在你正在尝试交付的价值上，让不同供应商帮助你进行监控，这正是我们提供的价值。 希望你享受这次会议。如果有任何问题，请随时在推特上联系我，在我们的网站上联系Epsagon。希望你能有所收获，各位再见。
讲者简介
Gal Bashan
Epsagon的技术总监
Epsagon的技术总监，常驻以色列特拉维夫。他有网络安全的背景，逆向工程和网络分析的经验。在加入Epsagon之前，他在以色列国防军服役，是一个精英情报单位的成员。
推荐阅读
替代Docker，登上顶刊，这款开源沙箱牛在哪里？
如何优雅地把握 Serverless 和 Serverful 的平衡点？
微服务和 Serverless 如何强强联合？
Function Mesh：Serverless 在消息与流数据场景下的火花
? 错过了直播懊悔不已？本次峰会所有嘉宾的演讲视频回顾上线啦，点击「阅读原文」即可观看~
? 看视频不过瘾还想要干货PPT？关注本公众号，在后台回复关键词「serverless」即可获取！
