Python 高手编程系列二百五十七：代码检测与监控

在编写完一个应用并将其部署到目标执行环境之后，我们的工作并没有结束。有可能
编写一个应用并在部署之后不需要进一步的维护，但是可能性很小。在现实中，我们需要确保正确地观察其错误和性能。
为了确保我们的产品按预期工作，我们需要正确地处理应用日志，并监控必要的应用
指标。这通常包括以下几个。
● 监控 Web 应用访问日志中的各种 HTTP 状态码。
● 进程日志集合，其中可能包含有关运行错误和各种警告的信息。
● 在运行应用的远程主机上监控系统资源（CPU 负载、内存和网络流量）。
● 监控作为业务绩效指标（客户获取、收入等）的应用级性能和指标。
幸运的是，有许多免费工具可用于检测你的代码并监控其性能。其中大多数都很容易
集成。
记录错误——sentry/raven
无论你的应用测试多么严格，真相都是令人痛苦的。你的代码最终都会在某刻出现故
障。可能出现任何问题——预料之外的异常、资源耗尽、某个后端服务崩溃、网络故障或
者只是外部库中的问题。通过适当的监控可以预测并阻止某些可能的问题（例如资源耗尽），
但无论你如何努力，总有一些事情可以穿过你的防御。
你能做的就是为这种情况做好充分准备，并确保没有将错误忽视掉。在大多数情况下，
任何意外的故障情况都会导致应用引发意外，并通过日志系统记录下来。它可能是
stdout、sderr、文件或你配置用于日志记录的任何输出。这可能会导致应用退出并给出
某个系统退出码，也可能不会，这取决于你的实现。
当然，你可以仅依赖于保存在文件中的这些日志来查找并监控应用错误。不幸的是，
观察文本日志中的错误是相当痛苦的，并且不能很好地推广到比在开发中运行代码更复杂
的情况。你最终不得不使用一些专为日志收集和分析而设计的服务。正确的日志处理非常
重要，我们稍后会解释其原因，但是它不能很好地跟踪和调试生产环境错误。原因很简单。
最常见的错误日志形式就是 Python 堆栈跟踪（stack trace）。如果你仅使用它，那么很快就
会意识到，它对于找出问题的根本原因是不够的——特别是发生未知模式的错误或在特定
负载条件下的错误时。
你真正需要的是尽可能多的关于错误发生的上下文信息。在生产环境中保存错误的完
整历史记录也是非常有用的，你可以很方便地浏览和搜索。提供这种功能的最常用工具之
一是 Sentry（https://getsentry.com）。它是一项久经考验的服务，用于跟踪异常并收集崩溃
报告。它是开源的，用 Python 编写，最初是作为后端 Web 开发人员的工具。现在它已经超
越了最初的目标，并且支持更多种语言，包括 PHP、Ruby 和 JavaScript，但仍是大多数 Python
Web 开发人员最常用的工具。
Sentry 提供付费的软件即服务模式，但它是开源的，所以你可以在你自己的基础设施
上免费托管它。提供与 Sentry 集成的库是 raven（可以在 PyPI 上找到）。如果你还没有使
用过它，想要测试但没有自己的 Sentry 服务器，那么你可以在 Sentry 的预置服务网站上轻
松注册免费试用。一旦你访问了 Sentry 服务器并创建一个新的项目，你将会得到一个叫作
DSN 的字符串，DSN 表示数据源名称（Data Source Name）。这个 DSN 字符串是将你的应
用与 sentry 集成所需要的最少配置设置。它包含协议、证书、服务器位置和你的组织/项目
标识符，其形式如下所示：
‘{PROTOCOL}😕/{PUBLIC_KEY}:{SECRET_KEY}@{HOST}/{PATH}{PROJECT_ID}’
一旦你有了 DSN，那么集成是相当简单的，如下所示：
from raven import Client
client = Client(‘https://:@app.getsentry.com/’)
try:
1 / 0
except ZeroDivisionError:
client.captureException()
Raven 与最流行的 Python 框架（例如 Django、Flask、Celery 和 Pyramid）都有许多集
成，使得集成更加简单。这些集成将自动提供针对给定框架的额外上下文。如果你选择的
web 框架没有专门的支持，那么 raven 包提供了通用的 WSGI 中间件，可以与任何基于
WSGI 的 Web 服务器兼容，如下所示：
from raven import Client
from raven.middleware import Sentry

注意：application 是之前定义过的某个 WSGI 应用对象

application = Sentry(
application,
Client(‘https://:@app.getsentry.com/’)
)
另一个值得注意的集成是能够跟踪通过 Python 内置 logging 模块记录的消息。启用
这种支持只需要添加几行代码，如下所示：
from raven.handlers.logging import SentryHandler
from raven.conf import setup_logging
client = Client(‘https://:@app.getsentry.com/’)
handler = SentryHandler(client)
setup_logging(handler)
捕获 logging 消息可能会有一些不太明显的警告，因此如果你对这一功能感兴趣，
请务必阅读有关这一主题的官方文档。这应该可以让你避免不愉快的意外。
最后还有一点，就是运行你自己的 Sentry 可以省钱。“天下没有免费的午餐”，你最终
将支付额外的基础设施费用，而 Sentry 只是另一项需要维护的服务。维护=额外工作=成本！
随着应用的增长，异常数量也会增多，所以你不得不在扩展产品的同时扩展 Sentry。幸运
的是，这是一项鲁棒性非常好的项目，但如果负载过高的话则不具有任何价值。此外，让
Sentry 时刻为灾难性故障情况做好准备是一项真正的挑战，这种情况可能每秒发送上千份
崩溃报告。所以你必须判断哪种选项对你来说更便宜，以及你是否拥有足够的资源和才智
来自己完成所有这些事情。当然，如果你的组织中的安全策略拒绝向第三方发送任何数据，
那么就不存在这样的进退两难。如果是这样的话，只需将其托管在你自己的基础设施上。
当然会有成本，但它是完全值得付出的。