监控

这个分类涵盖什么

在客户向您说明之前，就知道有东西坏了：可用性检查、错误跟踪、指标、日志、链路追踪，以及把人叫醒的告警。

产品跨度很大：从只对一个URL发起探测的单项检查，到接入基础设施产生的一切数据的平台。两者之间的差距，主要在于数据量和价格。

分析客户行为属于数据分析。应用运行在哪里，则是托管与云。

从外部开始

最有用的第一笔采购也最简单：一项从多个地点加载您网站、并在它失效时通知您的检查。

外部检查能发现内部仪表盘漏掉的故障，包括过期的证书、损坏的解析记录，以及没人通知过的防火墙变更。它们很便宜，对许多小团队来说，覆盖了最重要的大部分内容。

错误跟踪排在第二位。了解哪些异常触达了真实用户、频率如何、从哪个版本开始，能把含糊的反馈变成一次修复。归并的质量是这里产品之间的分水岭，因为一个产生四千条近乎相同告警的工具，产生的只是噪音。

四类数据

• 可用性检查：来自外部，针对客户实际使用的路径。
• 错误：经过归并，附带版本和用户上下文。
• 指标：数值型，保存成本低，用于趋势和阈值。
• 日志：细致而昂贵，用于还原发生了什么。
• 链路追踪：展示一个请求跨越多个服务的过程，用于找出时间花在哪里。

多数团队立刻需要前两项，不久之后需要指标，其余的则在系统复杂到靠猜已经行不通时再上。

数据保留是悄悄存在的约束。要把今天与上个月同一天对比，就需要一个月的数据，而入门方案往往只保留一周。

告警是个设计问题

没人处理的告警，会训练所有人忽略下一条，而这个习惯正是故障变长的原因。

针对用户的体验告警，而不是针对每个内部阈值。页面加载缓慢是重要的。处理器单独达到百分之八十，通常不重要。

每条告警都需要三样东西：负责人、文档化的处置动作，以及负责人睡着时也能触达的通道。通不过这个检验的，应该是仪表盘上的一项，而不是一条通知。

然后定期复查。告警会不断累积，条件会发生变化，每季度清理一次，是最便宜的可靠性工作。

成本，以及账单为何毫无预兆地增长

定价按主机、用户、接入的数据量或事件数，而按数据量计价是意外多发的地方。

一个日志输出过于冗长的服务，就能在您的流量持平时让账单翻倍。采样、在源头过滤，以及缩短详细数据的保留期，是常见的控制手段，所以请在需要之前，先问清楚产品提供什么。

自定义指标值得单独问一句，因为它们常常按唯一时间序列计费，一个选得不好的标签就能生出成千上万条。请要求设置消费上限，而不是只发告警，其余的情况可以看定价页面不会告诉您的事。

自己运行

开源实现功能强大，许可证免费。运维成本却是实在的：存储、数据保留、升级，以及为监控系统本身值班的人。

最后一点最值得掂量。自托管的监控体系，往往与它所监控的对象在同一次故障中一起失效，而那恰恰是您最需要它的时候。

从小处起步，又不把自己困住

第一套监控配置应当平淡无奇，一个下午就能搞定。

对关键路径设两项外部检查，把错误跟踪接入应用，再设一条能找到真人的告警通道。这就覆盖了一个小产品第一年里会遇到的大多数故障。

当您开始追问“为什么慢”而不是“有没有坏”时，再加指标。当系统的活动部件多到仅凭日志已无法一眼看出答案时，再加链路追踪。

值得早做的一个决定，是数据在哪里采集、采用什么格式。依据开放标准编写的埋点，日后可以指向不同的后端，而依据某家厂商的库编写的埋点，则会成为永远不换的理由。

写下一份记录，说明每条告警的含义以及由谁响应。凌晨三点的时候，这一页比任何仪表盘都更有价值。