监控运行实体：
无论对于系统监控抑或应用监控，监控应该在部署在任意可能出现问题的位置。
如driver、kernel、service、framework以及应用本身。
监控可以是异常处理代码中的一段日志，也可以是很长逻辑结果的一个校验。
可以是重要事件的记录，也可以是当前状态的记录。
可以运行在当前执行线程中，也可以是线程外甚至进程外。
如果能够在任意两行代码之间记录日志，我们便能够通过日志找到任意两行之间的问题。
综合性能的考虑，监控的目标是在尽可能少的记录的基础上尽可能多的推导出问题出现的原因。

监控与故障模式：
监控只能是对已知模式的监控，如何在不同层次上有效率的检查与处理故障是监控与故障管理需要思考的核心问题。
对于未知的问题有两种策略
1.尽可能的覆盖，运气好的话能够直接记录到故障的现场。
2.在问题发生后能根据记录大致判断故障位置，再使用覆盖法。
整体上看需要有机制能够支撑以上的策略，例如动态开关，单独打开单个设备日志的能力。
从故障理论来看，监控最小的层级是Fault，例如编码错误，设计错误以及需求错误，这些错误通常是不能被直接监控的。
一些编码错误类的Fault能够通过静态或者动态检查工具完成，如Address Sanitizer、Thread Sanitizer。
存在与代码中的Fault被激活后变成Error或者Exception，我们一般是在这个层级做监控。
如果Error或者Exception没有被正确的处理，则会最终变成失效。
我们希望能够直接处理Fault，事实上我们多数情况只能监控Error或者Failure。
举个例子，AOSP的ANR是一种对Failure的监控。Crash收对一种Error的监控。而Address Sanitizer是一种对Fault的监控。

常见模式的监控方法（参考书籍Patterns For Fault Tolerant Software第五章）：
1.故障关联（Fault Correlation）
通过一系列的故障关联组合推导出故障的原因
2.故障隔离 （Error Containment Barrier）
对检测的到的故障进行隔离，执行一系列的恢复操作如回滚，重启
3.事件完成校验 （Complete Parameter Checking）
在事件执行前后进行检查，校验其运行结果
4.系统事件监控 (System Monitor)
对流程中的序列进行校验，对于不符合预期的序列进行操作
5.heartbeat、acknowledgement以及watchdog
这里将这三个放在一起，是因为都是对时间内运行状态的预期。
6.恰当的阈值 (Realistic Threshold)
阈值是对过载的一种检查，这里用恰当是因为我们在设计时对系统的规划通常会随着发展而变化，如何或者恰当的阈值是值得探讨的问题。
7.状态检查 (Existing Metrics)
检查目前已经存在的指标是否满足要求或在正常范围内
8.日常维护 (Rotine Maintenance)
周期性执行检查以避免故障积累导致失效
9.日常审计 (Routine Audits)
审计日志或其他记录以保证历史执行正确
10.泄漏记录 (Leaky Bucket Counter)
一种自动对错误增加或减少的记录器，例如资源使用与释放

综上，我们可以看出，一个监控系统应该提供的通用工具有
0.对单点错误的统计
1.对事件完成度的检查
2.对事件序列完成度的检查
3.对事件执行时间的检查
4.对事件执行频次的检查
6.对系统中各模块的状态检查
7.对系统中各模块的日常维护，记录及审计
8.对以上事件的综合判断
9.对判断结果进行一系列的操作，以降低不可用的时间。