前段时间看一个小伙伴的系统设计。他从系统的设计目标开始讲：第一，完成核心业务功能；第二，有监控；第三，出现问题能追溯…… 刚讲到这里就被我叫停了：真正投入实用的任何一个软件系统，监控和可追溯都应该是基础要求，这是常识，怎么好意思和“完成核心业务功能”列在一起？但是转念一想，或许对很多人来说，这也算不上“常识”，它们固然很重要，但
学校里根本没教这些内容
，怪不得大家。
况且，我自己也在监控上吃过很多的亏，深一脚浅一脚走过来，才会懂得这种“常识”。为了避免大家少走弯路，我来讲讲关于监控的几个基础问题吧。
监控是系统设计的必备要求
谈到监控，通常是广义的“监控”，它包含“监控”（monitor）和“报警”（Alert）。按照Effective Monitoring and Alerting这本书的解释，二者的定义如下：
监控
：其作用是对既有系统维持认知，并衡量系统中的数据流转和状态改变。目的在于发现异常，在排障过程中提供帮助。
报警
：报警系统应当具有这样的能力，能侦测到显著的状态变化对应的事件，并将事件告知操作和维护人员。
如果我们承认，软件工程不只是“开发软件的工程”，合格的软件开发人员必须关心软件运行情况，对软件的全生命周期负责，那么我们就应当承认，监控和报警是内嵌在软件开发中的，是系统设计的底限要求。运行再迅速、功能再强大的系统，没有监控和报警（以下简称监控），都是残缺的。
有很多开发人员也在一定程度上懂得监控的重要性，但他们并不重视，因为现成的监控系统很多，搭起来接入就好了。这样的态度是不对的，这样的设计是不合格的。按照上文的定义，合格的监控必须能持续提供对于既有系统运行状态的认知，而系统“运行状态”往往并不是现成监控系统、监控项所能覆盖的，因为“系统”并不能还原为一堆零件。
比如说，如果你开发的是某种存储系统，单纯衡量CPU占用率、磁盘占用率、网络吞吐率，而忽略了每秒上传文件数、平均文件大小、平均存储事件、失败重试次数等等，那么你是无法建立对于存储“系统”的认知的。
所以，尽管有现成的监控系统可以帮一些忙，但更重要的是，在系统设计之初就问自己几个问题：如果要了解我的系统的运行状态，应当借助哪些指标？这些指标如何统计，以什么方式和频率统计？…… 如果开发人员不能很好地回答这些问题，最终开发出来的产品很可能会有问题，而且很可能是“莫名其妙”的问题，极难排查。
监控必须有足够存在感
我遇到过好几次这样的情况：系统上线了，监控也上线了，平时根本没有人看。甚至出现问题了，问对应人员平时运行情况是怎么样的，也拿不到满意答复，因为平时根本不关心。大家想的是：反正系统也上线了，也有监控了，就交给对应的人去关心就好了。结果监控系统成了僵尸，对真正应当关心监控信息的人来说，它没有什么存在感。
这样造成的直接后果是：排查问题的成本极高。因为设计数据统计和提供机制的与真正观察数据的是两拨人，而出现问题之后，又必须双方协同解决。毕竟，有产品意识的开发人员本来就少，有意愿又有能力把监控信息和监控系统设计到“傻瓜都能看懂”的开发人员就更稀少了。很多时候，监控系统里的数据不准还是其次，单纯一个不知所云的统计项就能让人完全抓瞎，根本谈不上有效监控、迅速定位。
之所以出现这种问题，通常都是因为监控系统缺乏存在感，平时没有人去关心。也就是说，光有监控系统是不够的，还应当让关心监控的人关心监控信息，给予足够的重视。
当然，如果应该关心的人有很好的职业素养，或者有上级明确的压力，这个问题不难解决，但很多时候这样的前提并不存在，应该怎么办？
其实已经有不少办法，最常见的就是变被动为主动，让监控主动来刷存在感。很多软件开发团队会专门安排几块屏幕放在大家都能看到的地方，上面实时显示系统的各种监控数据。这样的存在感会大大提升，总有人在路过或者放松的时候去留意它，有问题也会及时发现。即便“不是自己的问题”，也更愿意报告出来，提醒对应的人。比起那种“被动等待用户登录查看”的监控系统，这样的做法效果要好成千上万倍。
我有时还会推荐另一种“变被动为主动”的做法，就是让监控系统用邮件主动发监控的日报、周报。邮件这种形式有几个好处：第一，相比电话和短信，它对接收人的干扰比较小；第二，阅读时间比较自由，上线班路上花三五分钟看看邮件，就可以了解大致的情况；第三，既然是邮件，内容肯定会脱敏，避免在服务器端进行复杂的账号设置；第四，邮件天生是多副本的，查询历史数据的时候可以避免因为历史数据问题而扯皮。
