从事云服务的监控，算起来已经有三年了。这个时间说起来也不短，足以让自己静下心来，好好想想这一专业之中的一些概念性的问题，从而帮助我在这一方向上继续深耕提供更加清晰的指引。
在监控领域，好多概念都会混杂着一起用，比如Monitoring, Alert, Metrics。 有时候一套监控系统，也会被说成是报警系统。 如果要把这几个概念说清出，还真需要费一些口舌。 这里我推荐下面那篇对这几个概念做了清晰介绍的博文，从真实的工作场景很好的解释了几个概念的差别。
- Metrics，中文度量，指的是IT系统资源使用及其行为所观察到的以及收集到的原始测量 (Metrics represent the raw measurements of resource usage or behavior that can be observed and collected throughout your systems.)。 通过这些度量，我们应该可以知道系统的健康状况，也可以理解资源以及行为变化的趋势，以及基于系统做出的变化会带来的影响。
有些Metrics也许非常原始，比如很多都来自于操作系统，也有来自于一个功能模块提供的高级别的指标。 指标本身可能是用来说明容量状况，也可能用来观察某个组件的忙闲状况。
我们常见的Metrics有磁盘空间，cpu 负载， 内存使用量等等。这些都可以通过操作系统提供，非常简单。对于一些自己研发的组件， 我们可能还要主动添加代码或者接口用来暴露Metrics。
对于Metrics的重要性其实毋庸多言。 它让我们能够对目标系统加以分析和聚合，从而让我们理解变化的趋势，规避未来可能出现的错误，提高系统的稳定性。
说完 Metrics， 那么说说 Monitoring -监控。
- Monitoring，指的一套收集、聚合以及分析 Metrics 从而提高服务组件特性以及行为的可知性的过程。作为监控系统， 则有责任存储、聚合、可视化并且对越界数据做出自动的响应。
一般说 Metrics 和 Monitoring 的区别，就如同 数据 和 信息 的区别。前者更加原始，而后者对操作人员更有指导意义，是处理过后的数据。
监控系统一般肩负了很多责任。
- 收集和存储数据。虽然当前数据非常重要，但是通过和历史数据的对比则更加重要，更有帮助，所以存储历史数据就变得尤为重要。
- 数据可视化。 只有很好的通过视觉展现数据，人们才能更好地理解并使用它，否则数据的使用效率会非常低，也非常难以对运维做出快速的帮助。
- 组织并建立数据的相关性。 正是因为监控平台拥有多个数据来源，所以如何让不同来源的数据产生更多的价值也是监控平台可以贡献的点。
- 定义规则并触发报警。
什么是 Alerting 报警呢？
- Alerting, 指的是监控系统中针对指标变化做出的响应模块。报警规则的定义一定包含两个部分， 第一是基于指标定义的阈值，第二就是当指标超出可接受范围时所要采取的行为。
这里不要把报警和通知相等同。虽然报警系统很多时候都是通知相关人员上线处理，但也可以是一段自动扩容脚本，比如当cpu负载过高时自动申请新的cpu处理计算。 不过无论如何，报警系统的主要功能还是为了引起人们的注意，所以即使有自动恢复机制，报警模块仍旧需要以一定方式将系统状况告知系统管理者。
什么信息是我们需要关注的呢？
- 主机指标
- 应用指标
- 网络及连接性指标
- 集群指标
- 外部依赖指标
如何评价Metrics， Monitoring以及Alerting System的质量呢？
- 独立性。 监控系统本身不应该对被观测的系统有过多的侵入性。完全隔断几乎不可能，毕竟总是需要作用在目标上才能发现问题，但是尽量保持独立性，尽量少的影响其他系统是一个好的监控系统的基本准则。
- 可靠性以及可信赖。 这点至关重要。 监控系统本身的可靠性体现在日复一日的操作当中， 而不可靠的报警会直接影响到用户对监控系统的信任。
- 简单的总结以及详细视图。总览的视图可以让人们一眼就看到问题所在，而方便的进入详细视图则
- 有效利用历史数据。 丰富的历史数据对监控系统来说是非常有价值的，可以基于时间线做很好的趋势分析，模式匹配等等，但是也需要合理的考虑存储的成本以及平台的性能，所以需要一定的机制归档旧数据。 另外也要有便利的方式将旧数据加载到当前平台。
- 能对不同数据源做关联。
- 能很容易的接入新的数据和基础设施。
- 灵活及强大的报警机制。
Reference: An Introduction to Metrics, Monitoring, and Alerting