您编写的应用程序执行大量代码，并且以一种基本上不可见的方式执行。那么您如何知道：代码是否正在运行？是否正常工作？谁在使用它以及如何使用它？可观察性是查看数据以告诉您代码在做什么的能力。在本文中，主要关注分布式系统中的服务器代码。这并不是说客户端应用程序代码的可观察性不重要，只是客户端通常不是用Python编写的。并不是说可观察性对数据科学不重要，而是数据科学中的可观察性工具（主要是Juptyter和FastFeedback）不同。为什么可观察性很重要那么，为什么可观察性很重要？可观察性是软件开发生命周期(SDLC)的关键部分。交付应用程序并不是结束，它只是新周期的开始。在这个周期中，第一阶段是确认这个新版本是否正常工作。否则，可能需要回滚。哪些功能工作正常？哪些功能有细微的错误？你需要知道发生了什么才能知道下一步该做什么。这些东西有时无法以奇怪的方式正常工作。无论是天灾、底层基础设施出现问题，还是应用程序进入怪异状态，这些东西都可能随时因任何原因停止工作。在标准SDLC之外，您需要知道一切都在运行。如果没有，关键是要有办法知道为什么它不起作用。反馈可观察性的第一部分是获得反馈。当代码提供有关它正在做什么的信息时，反馈可以在很多方面提供帮助。在模拟或测试环境中，反馈有助于发现问题，更重要的是，可以更快地对问题进行分类。这改进了验证步骤中的工具和通信。在进行金丝雀部署或更改功能标志时，反馈很重要，您需要知道是继续、等待更长时间还是回滚。监控有时您会怀疑某些事情不太对劲。也许依赖服务有问题，或者社交网站有问题炸毁你的网站。也许相关系统中有复杂的操作，您希望确保您的系统能够完美地处理它们。在这些情况下，您希望将来自可观察性系统的数据集成到仪表板中。在编写应用程序时，这些仪表板需要成为设计标准的一部分。只有当您的应用程序可以与这些仪表板共享数据时，它们才会显示这些数据。警报盯着控制面板超过15分钟就像看着油漆变干。没有人应该受到这种折磨。对于这种任务，我们有一个警报系统。警报系统将可观察性数据与预期数据进行比较，并在它们不匹配时发送通知。全面深入地了解时间管理超出了本文的范围。但是，从两个方面来看，可观察应用程序是警报友好的：它们具有足够和足够好的数据，并且它们发出的警报质量很高。警报具有足够的数据，或者收件人可以随时使用，以帮助追踪来源。高质量的警报具有三个特征：更少的误报：如果有警报，则一定有问题。更少的假阴性：如果有问题，就会发出警报。及时性：快速发出警报以减少恢复时间。这三个特征是相互冲突的。您可以通过提高监控标准来减少误报，但代价是增加漏报。您还可以通过降低监控阈值来减少误报，但会增加误报。通过收集更多数据，您还可以以牺牲及时性为代价来减少误报和漏报。同时改善所有三个参数更加困难。这需要高质量的可观测性数据。更高质量的数据可以同时改善所有三个特征。有些人喜欢用打印来嘲笑调试的方法。但在大多数软件无法在您的本机上运行的世界中，您所能做的就是打印和调试。日志记录是打印调试的一种形式。尽管存在许多缺点，Python日志库还是提供了标准化的日志记录。更重要的是，这意味着您可以使用这些库来记录日志记录。应用程序负责配置日志记录的完成方式。具有讽刺意味的是，经过多年的应用程序负责配置日志记录，情况越来越不是这样了。在现代容器编排环境中，现代应用程序记录stderr和stdout，并信任编排系统适当地处理日志记录。但是，您不应该依赖库，或者更确切地说，不应该依赖其他任何地方。如果您希望操作员知道发生了什么，请使用日志记录而不是打印。日志级别日志记录最重要的特性之一是日志级别。不同的日志级别允许您合理地过滤和拆分日志。但这只有在日志级别保持一致的情况下才能做到。最后，您应该在整个应用程序中保持日志级别一致。选择不兼容语义的库可以通过应用程序级别的适当配置来追溯修复，只需使用Python中最重要的通用样式：getLogger(__name-_)。大多数合理的图书馆都会遵循这个约定。过滤器可以在发出之前就地修改日志对象。您可以将过滤器附加到处理程序，该处理程序按名称修改消息以具有适当的级别。importloggingLOGGER=logging.getLogger(__name__)考虑到这一点，您现在必须明确日志级别语义。有很多选项，但这些是我的最爱：错误：发送即时警告。应用程序处于需要操作员注意的状态。（这意味着包括严重和错误）警告：我喜欢称这些为“营业时间警报”。在这种情况下，应该在一个工作日内有人关注。信息：这是在正常工作流程中发出的。这是为了帮助人们在怀疑有问题时了解应用程序正在做什么。调试：默认情况下，这不应出现在生产中。在模拟环境或开发环境下，可以发也可以不发。如果需要更多信息，也可以在生产环境中专门打开它。在任何情况下，您都不应在日志中包含个人身份信息(PII)或密码。无论日志级别如何，例如级别更改、激活的调试级别等，都是如此。日志聚合系统很少是PII安全的，尤其是随着PII法规的不断发展（HIPAA、GDPR等）。日志聚合现代系统几乎总是分布式的。冗余、可扩展性，有时管辖权需要更多的水平分布。微服务意味着垂直分布。登录每台机器查看日志是不现实的。出于合法控制的原因，允许开发人员登录机器会给他们更多的特权，这不是一个好主意。所有日志都应发送到聚合器。有一些商业解决方案，你可以配置一个ELK堆栈，也可以使用其他数据库（SQL或no-SQL）。作为一个真正低技术含量的解决方案，您可以将日志写入文件，然后将它们发送到对象存储。解决方案有很多，但最重要的是选择一个并将所有内容结合在一起。记录查询在将所有内容记录到一个地方之后，就会有很多日志。具体的聚合器可以定义查询的编写方式，但无论是从存储中搜索还是编写NoSQL查询，记录查询以匹配源和详细信息都是有用的。指标获取指标获取是一种服务器拉取模型。指标服务器定期连接到应用程序并提取指标。最终，这意味着服务器需要连接并找到所有相关的应用程序服务器。使用Prometheus标准化如果您的指标聚合器是Prometheus，那么Prometheus格式可用作端点。但是，即使聚合器不是Prometheus，它也很有用。几乎所有系统都包含一个普罗米修斯端点兼容的垫片。使用客户端Python库使用Prometheus填充您的应用程序，这将使它可以被大多数指标聚合器抓取。当Prometheus发现服务器时，它希望找到一个指标端点。这通常是应用程序路由的一部分，通常在/metrics路径下。无论Web应用程序的平台如何，如果您可以在端点下运行自定义类型的自定义字节流，Prometheus就可以对其进行爬取。对于大多数流行的框架，总是有一个中间件插件或类似的东西来收集延迟和错误率等指标。通常这还不够。您需要收集自定义应用程序数据：例如，每个端点的缓存命中/未命中率、数据库延迟等。使用计数器Prometheus支持多种数据类型。一个重要而巧妙的类型是计数器。计数器总是在前进-但有一个警告。重置应用程序时，计数器将重置为零。计数器中的这些“持续时间”通过将计数器“创建时间”作为元数据发送来管理。Prometheus知道不要比较两个不同年龄的计数器。使用仪表值仪表值要简单得多：它们测量瞬时值。用它们来衡量上升和下降的事物：例如总分配内存大小、缓存大小等。使用枚举值枚举值对于整个应用程序状态很有用，尽管它们可以以更细粒度的方式收集。例如，如果您正在使用功能门控框架，一个具有多个状态（例如，使用中、关闭、阻止等）的功能，枚举可能会更有用。分析分析不同于指标，因为它们对应于一系列事件。例如，在Web服务器中，事件是外部请求和结果工作。特别是，在事件完成之前不能发送事件分析。事件包含特定指标：延迟、数量和对其他服务的可能请求的详细信息等。结构化日志现在一个可能的选择是构建日志。发送事件仅发送具有正确格式负载的日志。可以从日志聚合器请求此数据，然后对其进行解析，并将其放入可以查看的合适系统中。错误跟踪您可以使用日志记录来跟踪错误，也可以使用分析来跟踪错误。但是专用的错误系统仍然是值得的。针对错误优化的系统可以发送更多错误，因为毕竟错误仍然很少见。这样它就可以发送正确的数据，并且利用这些数据，它可以做更聪明的事情。Python中的错误跟踪系统通常与一般异常处理相关联，然后收集数据并将其发送到专门的错误聚合器。使用Sentry在很多情况下，自己运行Sentry是正确的做法。当错误发生时，就意味着出现了问题。可靠地删除敏感数据是不可能的，因为有时敏感数据会被发送到不应该发送的地方。通常，这种工作量不是很大：异常不会经常发生。最后，系统不需要高质量和高可靠性的备份。昨天的错误应该已经修复了，希望如果没有，你仍然会找到它！快速、安全、可重复：具有这三者的可观察系统开发得更快，因为它们会给你反馈。它们运行起来也更安全，因为它们会在出现问题时更早地通知您。最后，可观察性还有助于围绕它构建可重??复的流程，因为存在反馈循环。可观察性可以让您了解您的应用程序。更好地了解他们是成功的一半。不砍柴建造所有可观察的层，很难磨刀。总感觉像是在浪费工作，或者更像是“可以，但不要着急”。以后可以这样做吗？也许吧，但不应该。建立正确的可观察性可以加快所有后续开发阶段：测试、监控，甚至培训新人。在像科技行业这样动荡的行业中，减少培训新人的工作量绝对是值得的。事实上，可观察性很重要，所以尽早写出来，以便始终保持。反过来，它将帮助您维护您的软件。
