Python 高手编程系列五百五十八：监控系统与应用指标

对于监控性能而言，可供选择的工具数量可能非常多。如果你的期望很高，那么你可
能需要同时使用几种工具。
无论使用哪种技术栈，Munin（http://munin-monitoring.org）都是许多组织最常用的工
具之一。它是一个分析资源趋势的好工具，即使是没有额外配置的默认安装也提供了大量
有用的信息。它的安装包括两个主要组件。
● Munin 主机，从其他节点收集指标并提供指标图形。
● 在被监视主机上安装的 Munin 节点，用于收集本地指标并将其发送到 Munin 主机。
主机、节点和大多数插件都是用 Perl 编写的。也有其他语言编写的节点实现：
munin-node-c 是用 C 编写的（https://github.com/munin-monitoring/munin-c），munin- node-
python 是用 Python 编写的（https://github.com/agroszer/munin-node-python）。Munin 的contrib 仓库提供了许多可用的插件。也就是说，它对大多数流行的数据库和系统服务都
提供了开箱即用的支持。甚至还有用于监控流行的 Python Web 服务器（例如 uWSGI 和
Gunicorn）的插件。
Munin 的主要缺点是它将图形作为静态图像，实际的绘图配置包含在特定的插件配置
中。这不利于创建灵活的监控仪表板，也不利于在同一个图形中对比不同来源的指标值。
但这是我们为它简单的安装和功能的多样所需要付出的代价。编写你自己的插件非常简单。
有一个 munin-python 包（http://python-munin.readthedocs.org/en/latest/），可以帮助你用
Python 编写 Munin 插件。
不幸的是，Munin 的架构假设在每台负责收集指标的主机上总是有一个独立的监控守护
进程，这可能并不是监控自定义应用的性能指标的最佳解决方案。编写自己的 Munin 插件的
确非常简单，但前提是监控进程能够以某种方式报告其性能统计。如果你想要收集某个自定
义应用指标，那么可能需要将其聚集并保存在某个临时存储中，最终上报给一个自定义的
Munin 插件。这使得创建自定义指标变得更加复杂，因此你可能会考虑其他解决方案。
另一种常用的解决方案可以使收集自定义指标变得特别简单，它就是 StatsD
（https://github.com/etsy/statsd）。它是一个用 Node.js 编写的网络守护进程，可以监听各种统
计信息，例如计数器、计时器和计量器。由于基于 UDP 的简单协议，它的集成非常简单。
使用名为 statsd 的 Python 包也可以很容易地向 StatsD 守护进程发送指标，如下所示：

import statsd
c = statsd.StatsClient(‘localhost’, 8125)
c.incr(‘foo’) # 增加’foo’计数器 。
c.timing(‘stats.timed’, 320) # 记录 320ms 的’stats.timed’ 。
由于 UDP 是无连接的（connectionless），它对应用代码的性能开销很低，所以它很适
合跟踪并测量应用代码内的自定义事件。
不幸的是，StatsD 只是指标收集守护进程，所以它不提供任何报告功能。你需要能够
处理来自 StatsD 的数据的其他进程，以便查看实际的指标图形。最常见的选择是 Graphite
（http://graphite.readthedocs.org）。它主要完成以下两件事情。
● 保存数值型的时间序列数据。
● 根据需要呈现这个数据的图形。
Graphite 让你能够保存高度可定制的图形预设。你还可以将许多图形分组到不同的主
题仪表板中。与 Munin 类似，图形被渲染为静态图像，但也有 JSON API 允许其他前端来
读取图形数据并用其他方式来渲染。与 Graphite 集成的一个很棒的仪表板插件是 Grafana
（http://grafana.org）。它很值得尝试一下，因为它比普通的 Graphite 仪表板具有更好的可用
性。Grafana 提供的图形是完全交互式的，也更易于管理。
不幸的是，Graphite 是一个有点复杂的项目。它不是整体的服务，而是由下列 3 个单
独的组件组成。
● Carbon：使用 Twisted 编写的守护进程，用于监听时间序列数据。
● whisper：简单的数据库，用于保存时间序列数据。
● graphite webapp：Django web 应用，根据需求将图形渲染为静态图像（使用 Cairo
库）或 JSON 数据。
在与 StatsD 项目一起使用时，statsd 守护进程将其数据发送给 carbon 守护进程。
这使得完整的解决方案变成各种应用的复杂堆积，其中每个应用都使用完全不同的技术来
编写。此外，没有可用的预配置图形、插件和仪表板，因此你需要自己配置一切。这在开
始时包括很多工作，很容易遗漏一些重要的事情。因此，即使你决定用 Graphite 作为核心
监控服务，使用 Munin 作为监控备用可能也是个好主意。
处理应用日志
虽然像 Sentry 这样的解决方案通常比保存在文件中的普通文本输出更加强大，但日志永
远不会消失。将一些信息写入标准输出或文件是应用可以做的最简单的事情之一，这一点不
应该被低估。有这样一种风险：raven 发送到 Sentry 的消息将无法送达。网络可能会出现故
障。Sentry 的存储可能会耗尽或者可能无法处理传入的负载。你的应用可能会在发送任何消
息之前崩溃（例如出现分段错误）。这些只是几种可能的情况。不太可能的是，你的应用将
无法记录将被写入文件系统的消息。这仍然是可能的，但我们应该诚实一点。如果你遇到这
种日志记录出现故障的情况，那么你很可能有许多比缺失的日志消息更重要的问题。
记住，日志不仅是关于错误的。许多开发人员曾经只将日志作为数据来源，这些数据
在调试问题时非常有用，也可以用于执行某种取证。当然，很少有人尝试用日志来生成应
用指标或者做一些统计分析。但日志的用途可能要更多。它甚至可以作为产品实现的核心。
Amazon 有一篇文章讲到了用日志构建产品的一个很好的例子，里面介绍了一个实时竞价服
务的示例架构，其中一切都围绕着访问日志收集和处理。参见 https://aws.amazon.com/blogs/
aws/real-time-ad-impression-bids-using-dynamodb/。