聊聊监控（二）：谁为代码负责以及常见的监控痛点

『聊聊监控』系列文章翻译自Baron的博客，如作者所说，希望你在阅读该系列文章之后，可以在系统中应用这些最佳实践，并为你的应用构建一个高度可监控的架构，用小成本实现极佳的系统能见度。

在上一篇文章中，作者聊到了监控指标的取舍以及监控的意义。本文是系列文章的第二篇。

随便在你的应用里面找出一个服务。谁为它的线上表现负责？这个负责人是否就是编写它的那个人？

DevOps有一个核心理念，那就是编写代码的人要为它们在线上的运行负责。这个理念非常适合微服务架构的软件，而实现这个理念就意味着我们必须要监控它们在线上运行的情况。

本系列文章无意深入探讨这个理念。然而我想要指出一个影响性能和可靠性的常见问题，那就是反馈循环的缺乏（或反馈系统被打断）。如果开发者不负责线上环境的运维，则他们写代码的时候就不会太多考虑运维友好的问题。就是这么简单。不负责运维的他们，不知道系统能够承受什么，不知道怎样的日志信息是有用的而哪些是没用的。可运维性是一项功能，不使用这个功能就不知道该怎样把这个功能做好。

如果你认可这个观点，那么事情就变得很明显：生产环境上运行的每一个服务都需要监控并记录日志，监控的度量和日志事件需要对需要他们的人可见。这些应用和系统的度量应该是透明的、可查询的，而且其代码实现应该做到部署代码的同时就将监控服务相关的内容也一起部署。

接下来我将讨论我在一些定制软件和现成软件中见到的有关可监控性的问题，以及这些软件对于监控方面的设计思路。我针对定制应用列出了下面这些内容，当然它们也适用于服务器软件的开发。

日志级别

对于我们想要的细粒度以及日志信息的准确度而言，日志的级别似乎总是不够用。一条日志应该是INFO、TRACE还是DEBUG？如果这是个用于WARN的DEBUG呢？所谓的日志级别是否是一个严谨的线性序列？我们也经常在上述通用的日志级别之外创建的更多定制化的日志级别。我个人的观点是，日志信息只需要分成两类：一，有助于代码debug的；二，有助于运维操作的。

状态与配置纠缠不清

很多系统在状态变量以及配置变量之间没有做出严格的区分。状态变量是对系统状态的表达，而配置变量是向系统输入的内容。比如在MySQL和Redis中，获取系统状态的命令会同时返回状态变量和配置变量，而两种变量都混在一起。这种“大杂烩”经常会造成不便，我们不得不另外写一段代码或者编写白名单/黑名单来把两种变量分离出来。

向后不兼容

如果你在某次更新中改变了一个度量的含义（或维度），那么在理想的情况下，应该保持之前的行为不变，同时引入一个平行的替代方法。否则的话，会给很多其他的系统带来麻烦。比如在MySQL中，SHOW STATUS命令就进行过一次变更，更新后该命令默认包含连接计数，而之前的全局计数则是通过另一个命令来获取。这一次更改给很多系统带来了麻烦。还有一次，MySQL把一个“Questions”状态变量的含义改了，新的“Queries”变量取代了之前的“Questions”变量。这等于是一次变量重命名，结果造成了很多混乱。不要做这种事。

不完全可见

还是拿MySQL来做反面教材。MySQL从很早之前开始就有一个SHOW VARIABLES命令用于显示变量。然后，很多命令行选项都使用了完全相同的变量名。有些变量被正确的显示了，有些则没有，有些则是被显示了但是名字完全不对。

核心指标（KPI）匮乏

分析性能问题需要的关键指标其实并不多。系统利用率、延时、队列长度是最关键的信息，而这些信息可以从少数几个指标中获取。比如，Linux下的/proc/diskstats指标通过一些队列理论的分析就可以得到其他有用的数值。有一个令人惊讶的事实是，很多系统都没有提供检测上述关键度量的途径，因为构建这些系统的人对于监控并没有清晰的认知。比如，PostgreSQL为事务设计了标准的性能度量功能，却没有为语句（statements）进行同样的设计，所以如果你想知道服务器每秒在处理多少查询（queries/statements），则不得不采取更加复杂的办法。这种基础度量的缺失是一个很严重的问题。