• 监控不是一个单一问题，无法通过某一个工具来解决

  + 如果想在代码级别分析并监控应用程序，你可能需要 APM 工具，或者自行测量应用程序（例如，通过 StatsD）。
  + 如果需要监控云基础设施的性能，你需要寻找现代化的服务器监控解决方案。
  + 如果需要监控生成树拓扑结构的变化或路由变更，你需要寻找专注于网络的工具。
  

  1. 合并提供相同信息的工具

  2. 不要害怕引入专用工具

     团队希望使用能够解决问题的工具，而不是以“整合工具”之名被迫使用不能满足其需求的工具

• 盲目崇拜更成功的团队以及公司的工具和程序

  团队需要花很多时间去理解为什么一个工具或程序是有效的。工具是工作方式、假设、文化和社会规范的表现。这些规范不太可能直接适用于你的团队。

监控本身与被监控对象息息相关，不了解被监控对象就无法为其创建监控体系， 因此监控不是一份工作，而是一项技能，并且是团队中每位成员都需要在一定程度上掌握的技能

  在监控过程中，请坚持让每个人都对监控负责。DevOps 运动的一个核心宗旨就是让所有人而不只是运营团队对产品负责。
  网络工程师最了解应该监控网络中的哪个部分以及热点的分布。
  软件工程师比任何人都了解应用程序，所以应该将他们放在最合适的位置上，以便为应用程序设计最好的监控。

• 确保监控的首要地位，只有部署好监控的产品才具备上线条件
• 可以有专人创建监控工具，但监控本身不由其负责。

如何判断自己是否已经成为这种反模式的受害者呢？可以通过以下几种迹象来判断。

+ 虽然你记录系统负载、CPU 使用率和内存利用率这样的指标，但是服务还是在你不知道原因的情况下停止运行。
+ 你习惯性地忽略告警信息，因为它们多数时候是误报。
+ 你每隔 5 分钟或者更短的时间就要检查系统的指标。
+ 你没有存储历史指标数据（说的就是你，Nagios）。

这个反模式通常和上一个反模式（监控岗位化）一同出现。因为配置监控的人员没有完全理解系统的工作原理，所以他们经常只配置最简单和最容易的检查项

• 弄清正常运行的真正含义

• 系统资源类的告警不是很有用

      如果 MySQL 总是使用全部的 CPU，但是响 应时间在可接受范围内，那其实没有问题。
      这就是为什么与 CPU 和内存使用率这样的低级别指标相比，了解“正常运行”的含义要有用得多。
  
      当然，并不是说这些指标没有用。操作系统指标对于诊断和性能分析至关重要，因为它们能让你在可能影响性能的底层系统行为中发现波动和趋势。
      但在大多数情况下，它们并不意味着真正有问题
  

• 增加收集指标数据的频率

      在一个复杂的系统（比如现在运行的这个）中，几分钟甚至几秒钟内就能发生很多事。
      考虑这样一个例子：假设不管什么原因，两个服务之间每 30 秒出现一次延迟高峰。
      如果每 5 分钟收集一次指标数据的话，你就会错过这个事件。
      收集指标的频率至少应是每 60 秒一次。如果系统的流量高，就应该选择更高的频率，例如每 30 秒甚至每 10 秒收集一次。
  

  在我曾经任职过的一个团队中，运行着一个遗留的 PHP 应用程序。这个应用程序有一大堆写得糟糕
  又难以理解的代码。当程序总是出故障时，团队通常的反应就是添加更多的监控，而不管故障是什
  么。不幸的是，虽然这个响应乍一看似乎是正确的，但几乎对解决真正的问题没有任何帮助。这是一
  个糟糕的程序。

  避免把监控当作拐杖。虽然监视对于提醒你注意问题非常有用，但是别忘了重要的是解决问题。如果
  发现自己面对的是一个问题层出的服务，而你总是往服务中添加更多的监控，那么你应该停下来，把
  精力用于提升服务的稳定性和弹性。更多的监控无法修复有故障的系统，也不会改善现有情形。

  操作手册常常是自动化程度不足的一个表现。
  如果操作手册仅仅是一个执行步骤列表（“运行这条命令，检查那个信息，运行另一条命令”）， 那么你需要更多的自动化。
  如果操作手册中引用的告警可以通过简单地执行一系列步骤来解决，那么考虑自动化那些步骤，并让监控工具在给你发出告警之前执行它们。

  可组合监控是现代监控设计的第一种模式。原则很简单：使用多个专门的工具并且将它们松散地组合
  在一起以形成一个监控“平台”。这种模式和你熟悉的很多一体化工具（特别是其中的代表 Nagios）
  正好相反。可组合监控可以视为 UNIX 理念的一种实践。

   编写专注于一件事并能将其做好的程序；编写互相协作的程序。

   ——Doug McIlroy

可组合监控的一个好处是可以灵活替换某个部分，而不用改造整个平台。

一个监控服务有以下 5 个基本方面 ：

• 数据采集
• 数据存储
• 可视化
• 分析和报告
• 告警

这5个方面可以作为评估一套监控的指标体系。

有太多的地方需要部署监控，但是有一个最适合开始的地方：用户。 添加监控的最佳地点首先是用户和应用程序交互的点。

• 服务是否正常
• 延时是否正常

• 机会成本并不低
• 不专业

• 监控需要时间来逐步完善
• 随着需求的变化以及行业的演进，一般每隔两三年就要重构一次监控。

• 告警分两种，一种需要立即行动（事件），一种仅供参考（信息）。

作者总结了6 条实践：

• 不同的告警通知渠道；
• 撰写运行手册；
• 慎用静态的阀值
• 精简告警；
• 设定维护周期；
• 尝试故障自愈。

• 修正假警报

• 提高系统弹性和稳定性

  1 在人们待命值班期间，只要不是在救火，就尝试把提高系统的弹性和稳定性作为他们的职责。
  2 根据在上一周待命值班工作中收集的信息，在接下来的每周迭代计划会/小组会议上制定关于提高系统弹性和稳定性的明确计划。
  

• 强烈建议让软件工程师也加入待命轮值

  1. 如果软件工程师意识到了待命值班带来的烦恼，并且他们自己也是轮值的一员，就会激励他们开发出更好的软件。
  2. 把软件工程师和运维工程师放在一起会在某种程度上产生共鸣，而且他们也不愿意让真正理解和喜欢的人失望。
  

• 待命值班补偿

  对于待命值班人员，我还会考虑以下两件与补偿相关的事情。
  
  1 在待命轮值结束时立即给予员工一天的带薪假期。待命值班非常伤脑筋，一天的恢复时间是员工应得的。
  2 对于团队的待命轮值工作要给予额外的薪水。在医疗行业待命轮值会收到额外的薪水是标准惯例，金额范围从护士每小时额外两美元到神经外科医生每天额外2000美元不等。
  
  待命值班会对生活产生很多消极影响，包括睡眠质量变差、陪伴家人的时间减少，等等。 对行业中最糟糕的部分给予额外的补偿是基本的公平。
  

• 技术界最受欢迎的事件管理框架是 ITIL

      关于事件管理的角色，一个常见的反模式是遵照公司或团队的日常层级架构来组织。
      例如，团队经理经常充当事件指挥官。但是，事件管理的角色其实没有必要按照日常的团队角色 来分配，
      相对于让团队经理充当事件指挥官，我更鼓励让他充当通信联络人，而让团队中的一名工程师扮演事件指挥官。
      这样做往往更合适，因为经理可以保护团队不受外界干扰，并将决定权交给最适合评估风险和权衡利弊的人。
  

• 警惕责备文化

      我注意到事后分析过程中有一个很不好的习惯：责备文化。如果你曾经工作过的团队，人们因为失误
      受到惩罚或感觉自己被迫对问题域负责，那么你可能处于一种责备文化中。
    
      如果人们害怕因犯错误而受到惩罚或羞辱，他们就会把失误隐藏起来或低调处理。如果事件发生后你
      所做的就是责怪某个人，那你永远也无法修复深层次的根本问题。
  

从高管或创始人的角度来看，我们可以很轻松地总结他们的关注点。

• 客户能不能正常使用应用程序/服务？
• 公司是在盈利么？
• 公司是在壮大、萎缩还是停滞不前？
• 利润有多少？是在提高、降低还是维持现状？
• 客户满意吗？

以下是企业主用来回答这些问题的常用指标。

月度经常性收入

衡量来自客户的月度经常性收入。

每位客户收入

衡量每位客户的总收入，通常以年度为基础。

付费客户数

净推荐值

衡量用户/客户满意度。

    净推荐值（NPS）要求用户从 1 到 10 打分，10 分是最好的（也称为李克特量表），说明他们向其他人推荐服务/应用程序的可能性有多大。
    有了足够多的回复，就可以知道用户对服务/应用程序的满意程度。
    净推荐值还可以在更细粒度的级别上使用，例如，在含有最近解析的服务台票据的跟进电子邮件中。

客户终生价值（LTV）

衡量客户在整个生命周期内的总价值。

每位客户成本

衡量服务客户的成本。

客户撷取成本（CAC）

衡量获得一位客户/用户的成本。

客户流失

衡量有多少用户离开了应用程序/服务。

    一定程度的用户流失是不可避免的，这是做生意的自然规律，但是高用户流失率可能表明应用程序出现了问题，无论是从产品角度（应用程序不是很好）、 性能角度（应用程序太慢）还是成本角度（应用程序太贵）来考虑。
    流失率很大程度上取决于业务性质，所以最好是和自己过去的服务比较，而不是和其他公司的服务比较。

活跃用户数

衡量应用程序/服务的活跃用户。

     活跃用户可能很难定义，而且这种衡量在很大程度上取决于业务性质。
     此指标通常是对多个指标，比如日活跃用户（DAU）、周活跃用户（WAU）和月活跃用户（MAU），进行跟踪。

资金消耗率

一个衡量公司整体开销的标准。

运转率

运转率通常与资金消耗率联系在一起，用于衡量一家公司在当前支出水平下资金耗尽的时间，通常按月计算。

总体有效市场（TAM）

衡量一个特定市场有多大。

    它基本上是一个估计值，通过确定将某个产品卖给市场上的所有人所能产生的总价值（以美元计）来得出。这取决于公司如何定义其市场。

毛利率

去除销售成本（COGS）后利润的衡量方法。

• 通过与产品经理和工程师团队沟通来进行指标关联。
• 画出程序模块的功能，从模块功能出发确定要检测的指标。

#+: Reddit业务KPI与技术指标绑定

浏览器本身获取了大量的指标数据。

  市面上有很多工具打着 APM 工具的旗号，其思路是在应用程序中添加一个 agent 程序或者类
  库，从而允许它们获得关于应用程序的性能、慢查询以及瀑布图等各种信息。这是一个令人信
  服的说辞，而且也没有错，因为这些工具会做以上所有事情而且常常会超出这些范围。

  问题就在于这些工具的背后并没有关于应用程序的任何上下文信息或业务逻辑。尽管你看到漂
  亮的瀑布图上显示了在特定的查询上花费的时间，但它实际上并没有告诉你关于这一关键工作
  流路径的延迟信息，或者关于这个应用程序是做什么的所需的任何上下文信息。

• 部署开始时间
• 部署结束时间
• 部署了什么版本的构建
• 谁触发了部署

参见 https://codeascraft.com/2011/02/15/measure-anything-measure-everything/

例如， 通过叠加部署事件和错误率，可以发现部署与错误之间的关系。

  应用程序中的一个 HTTP 端点会显示该应用程序的健康状态，有时候还会包含一些关于应用程序的基本信息（例如部署版本、依赖关系的状态等）。
  通过端点可以获取应用程序健康情况和状态信息。

日志能比指标包含更多的上下文语境

• 设置什么日志级别？
• 写入磁盘还是网络？
• 对于每一个进来的请求，使用一个唯一的请求 ID

  对于如何使用这些指标，我的建议是为你拥有的每个系统自动记录它们，但是不要在它们上面设置告警（除非你有充分的理由）

CPU

指标数据源于 /proc/stat

内存（去除buffer 和 Cache 的值）

指标数据来源于 /proc/meminfo

swap

对较低空闲内存和不断提升的 swap 使用率的告警是内存压力升高的一个很好的标志。

OOMKiller 日志

在 syslog 中查找 "killed process"

网络

通过 ifconfig 和 ip 查看，网卡收取、发送、错误和丢弃的字节数

磁盘

通过 iostat 查看，iowait, await, %util, tpss

iowait

代表因为等待磁盘完成操作而造成的 CPU 空闲时间

await

是指从发出请求到获取磁盘服务响应所需的平均时间（以毫秒计）。这个数值既包括花费在队列中的时间也包括执行请求的时间。

%util

最容易被视为磁盘的使用饱和度。

tps

每秒传输量

负载

通过 uptime 查看，表示多少进程在等待CPU. 负载指标并不对应系统性能。服务器的负载指标很高，但性能良好，这种现象很常见

只需要知道证书还有多久会过期，能提前通知即可。

不建议在服务器上使用 SNMP。

• 难以增加功能
• 协议本身不安全
• 通过轮训收集指标，难以扩展和管理
• 有更好的替代品，例如基于推送模式的 collectd, Telegraf, Diamond

每秒请求数

黄金指标

HTTP响应码

5XX 表示服务器端错误

(no term)

连接数

(no term)

请求时间

• 连接数
• 对服务器繁忙程度的直接衡量
• 慢查询
• 主副本复制延迟
• IOPS

消息队列长度

队列上等待的消息数

消费率

从队列中消费信息的速率

逐出项数量

高逐出率是缓存过小的信号

(no term)

命中率

区域传输率

节点通过区域传输和主节点保持同，可能引发同步问题。

每秒查询数

负载情况

• 客户端与服务端之间的时间偏移量
• ntpstat 返回码不为0

• DHCP 服务器已发放的租赁
• DHCP 池是否有足够的租赁容量

出站邮件队列

有多少邮件正在等待被发送出去

发送和接收邮件的总量

有助于发现异常行为

(no term)

邮箱容量与使用率

难点在于定时任务中要在失败时记录错误日志，例如

run-backup.sh 2>&1 backup.log || echo "Job failed" > backup.log

• HTTP 响应
• sudo 使用
• SSH 登录
• cron 作业结果

• 带宽
• 吞吐率
• 延迟
• 包括诸如 Rx/Tx 错误、丢弃、CRC 错误、溢出、载波错误、重置和冲突等指标
• 一个指标与其通常测量值的偏差。最常应用于延迟测量

• trunk 端口的变更
• 因错误被禁用的端口
• 链接聚合接口变成绑定或非绑定状态

网络的配置变更需要被存储起来并通知他人

这里最有用的监控是针对动态路由协议（主要是 OSPF 和 BGP）的。要监控静态路由，最好是通过
监控底层链接和在路由上传递流量的能力（例如使用 iperf2）来实现，而不是监控路由是否存在。

当谈及 BGP 时，有很多你能够也应该监控的地方。

+ TCAM 表的大小与机架的内存有关。将这个表最大化可能是糟糕的一天的开始。早在 2014 年，一些 Cisco 设备的 TCAM 耗尽就印证了这一点，那次事件导致了很多大企业的服务中断。
+ BGP 对等更改。
+ BGP AS 路径更改（这对于某些对延迟非常敏感的公司尤其重要）。
+ BGP community 更改（由对等方发送和接收的前缀数量）。

• CPU
• 内存
• 开关栈、线路卡、管理卡和电源
• syslog 中的冷启动信息

由 Cisco 定义的网络流（flow）是一个共享 7 个通用值的单向数据包序列。

1 入口界面（SNMP ifIndex）。
2 源 IP 地址。
3 目标 IP 地址。
4 IP 协议。
5 UDP 或 TCP 的源端口，其他协议是 0。
6 UDP 或 TCP 的目标端口，对于 ICMP 是类型和代码，其他协议是 0。
7 服务的 IP 类型。

流监控非常适合跟踪高带宽活动或节点，或者在每个 IP、协议、应用程序或服务的基础上分析带宽利用率。