copy from http://www.madblog.cn/posts/e77168f6653bb6b9.html

监控

• 收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和数据，错误的数量和类型，以及处理用时，应用服务器的存活时间等。

  白盒监控

• 依靠系统内部暴露的一些性能指标进行监控。包括日志分析、java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。

  黑盒监控

• 通过测试某种外部用户课件的系统行为进行监控。

  监控台页面

• 提供某个服务核心指标一览服务的应用程序;

• 该程序提供：主要是真是指标，也额外包含一些过滤、选择等功能;

• 也可以显示相应团队的一些信息：

  • 目前工单的数量
  • 高优先级的Bug列表
  • 目前的on-call工程师和最近进行的生产发布

    警报

• 目标对象是某个人发现某个系统地址的一个通知

• 通知类型可包括：
  • 工单系统
  • E-mail地址
  • 传呼机

• 警报类型分类：

  • 工单
  • E-mail警报（warn）
  • 紧急警报（page）

    监控的目的

• 分析长期趋势

  • 数据库数量
  • 增长速度
  • 月活用户增长趋势
• 跨时间范围比较，或者观察不同组之间的区别
• 预测即将发生的问题，发出警告

• 报警某项出现了故障，需要有人立即修复

  对监控设置一些合理预期

• 简单快速的监控系统 +高效的分析工具；

• 监控系统规则越简单越好，应该非常容易理解；
• 监控规则可以检测某个非常简单、具体，但是严重的异常情况；
• 减少监控的复杂依赖关系：
  • 最好多花一些时间监控现象，而不是原因；针对原因，应该只监控那些非常确定的和非常明确的原因；
• 能解决长尾问题；

• 度量指标采用合理的精度。

  监控控制台四个黄金指标

• 延迟

  • 处理某个请求所需要的时间
• 流量
  • 使用系统中的某个高层次的指标针对系统负载需求所进行的度量
• 错误
  • 请求失败的速率

• 饱和度

  • 服务器容量有都“满”
  • 需要有预测报警，例如在几小时之后会填满硬盘

    ``上述理念进行整合

• 以上理念整合起来，可能就会比较复杂了，可以通过以下规则进行精简，目的还是要追求满足监控目的情况下的简单，高效

  • 该规则是否能检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生的或已经发生的用户可见故障
  • 是否可以忽略这条警报？什么情况下可能会导致用户忽略这条警报，如何避免？
  • 这条警报是否确实显示了用户正在受到影响？是否存在用户没有受到影响也可以触发这条规则的情况？例如测试环境或系统维护状态下发出的警报是否应该被过滤掉？
  • 收到报警后，是否要进行某个操作？是否要立即执行，还是等到第二天早晨执行？该操作是否可以被安全的自动化？该操作的效果是长期的，还是短期的？

• 以上这些问题，反映了应对报警的一些层次的理念：

  • 每当收到紧急警报试，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”的效应；
  • 每个紧急警报都应该是可以具体操作的；
  • 每个紧急警报的回复都应该需要某种智力分析过程，如果某个紧急警报只是需要一个固定的机械动作，那么太久不应该成为紧急的警报；
  • 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠；

    总结

• 健康的监控系统应该是非常简单、易于理解的；

• 紧急报警应该关注于现象；
• 监控的技术栈层面越高，监控现象越容易；
• 对于所有报警都通过e-mail等发送，很容易变成噪声。我们应该更倾向于构建一个良好的监控台页面，直接显示所有的非紧急异常情况；
• 长远来看，要建立一个成功的on-call轮值体系，以及构建一个稳定的产品需要选择那些正在发生和即将发生的问题来进行报警，设置一个可以实际达到的合理目标，保证监控系统可以支持快速的定位与检测。