什么是黑/白监控
黑盒监控所描述的是监控外部用户可见的系统行为，主要关注的现象，重点在于对正在发生的故障进行监控告警，例如，某某网站打不开了，或者服务挂掉了，无法为用户提供服务。
白盒监控所描述的是监控内部暴露出来的关键指标，主要关注的原因，重点也是关注其发生的原因，例如服务挂掉了，是什么原因导致的呢，是内存溢出还是服务过载，这些是导致服务挂掉的原因。
两者区别是一个对外，通过外部现象、另一个对内，通过对内究其原因，两者监控维度也不相同：
- 监控维度不同，黑盒更偏向外侧，可以理解通过某个功能或者接口来观测其SLA，它并清楚其内部实现；而白盒更倾向于从内测监控，可理解从代码依赖关键中间信息 埋点信息、关键指标的Metrics，它是代码层面，从内部时间来监控整个系统。
- 面向对象不同，黑盒监控更多面向问题的现象，如某某服务挂了，功能不能用了，页面打不开了了；而白盒更加倾向于问题的本质，产生问题的原因，例如导致挂了的原因是内存溢出、还是大量Panic等等。
实际场景中的黑盒监控、一般可以细分为如下：
- 证书检测，检测证书是否有效、来确保用户是否可以正常访问。当下多数网站服务基本上都是使用的HTTPS，一旦证书出现了问题，则浏览器或者网络请求框架（httpclient）则认定该访问不安全，并组织用户访问。
- 端到端功能检测，一般情况下都通过自动化测试工具来进行检测，进而确认数据格式及数据是否正确。
- 端口探活，端口探活是利用通过看门狗来定期检测端口是否存活，来标记服务状态或者告警或挂掉之后的操作。
实际场景中的白盒监控，一般是通过下列数据维度，来进行白盒监控：
- 日志（Log）：通过日志记录可以了解程序运行的状态信息，包括异常信息等。
- 指标（Metrics）：通过数值指标的形式，可以帮助了解系统的内部资源走向趋势等情况。
- 链路追踪（Tracing）：通过链路追踪能了解到每一次程序运行的轨道，及轨道上的蛛丝马迹，便于对轨道行迹分析和优化。
监控的用途
如果我们对监控的用户，简简单单的以为只是监控有没有问题，如有问题就告警，说明对监控的理解还不够深入，这只是其中一部分，下面来一起看看监控的用途还有哪些。
分析长期趋势
通过白盒监控的指标（Metrics）收集，能够分析出去当前的数据量，用户量等等，及它们的增长趋势，通过分析长期趋势，来做出响应的动作，如数据量一旦过大，相比会影响查询的性能，或者流量的增长趋势是连续增长的话，那么需要评估当前的容量是否能够容纳这些流量。
指标对比
通过指标对比，一般是通过不同时间段的对比，实验组与对照组的对比等，来对比那一组性能更好或更能满足，如服务器扩容前或扩容后的对比，缓存的增加前后、优化前后的命令中率是否有更好的提升。
告警
通过发告警及时的讲故障通知，需要有人关注，如那个服务挂了，在什么时间点挂掉了，需要有人及时处理。
监控大盘
通过监控大盘能够清晰的表明有关服务的问题，通常会包括常见的4个黄金指标，分别是错误、延迟、流量和饱和度。如通过大盘可以看到某服务的错误率，或者当前服务的流量情况。
回溯分析
通过回溯分析来观察系统的运行状态，一般可以通过流量回访，或者放大来观测系统的运行状态，或者通过故障注入的方式来观测系统的运行状态。
黄金指标
无论业务系统如何复杂，监控指标如何眼花缭乱，但万变不离其宗，监控的目的无非是为了解服务运行状况、发现服务故障和帮助定位故障原因。为了达成这个目的，Google SRE总结的监控四个黄金指标对我们添加监控具有非常重要的指导意义，分别是错误、延迟、流量和饱和度。下面我们就这四个黄金指标分别展开说明，并给出一些监控项的采集实例。
四个黄金指标的指标信息基本上都可以分为两个维度来，一方面是基础（资源）指标监控，另一方面是业务指标监控。
- 基础（资源）指标监控：指的服务器或云主机的CPU、内存、磁盘资源的使用情况，一般情况下都是以集群方式提供服务，某台服务器出现该指标故障，并不代表该服务的无法运行。
- 业务指标监控：指的是业务系统内部的运行状态，或者业务相关指标，多数情况下通过基础指标监控和业务指标监控结合来看，更全面的了解系统的情况。
延迟（latency）
延迟指的是服务处理请求所需的时间，服务延迟的上升不仅仅体现在用户体验的下降，也有可能导致请求堆积并最终演变为整个业务系统的雪崩。实际场景中，更多关心的接口耗时，如某个由于数据库连接丢失或者其他后端问题造成的 HTTP 500 错误可能延迟很低。计算总体延迟时，如果将 500 回复的延迟也计算在内，可能会产生误导性的结果。但是慢错误要比快错误更糟，因此监控错误的延迟也是非常的重要。
延迟监控指标：
- 基础监控：IO等待、网络延迟
- 业务监控：接口、服务的平均耗时如TP90、TP99、TP999等、DB、缓存的慢查询
延迟在系统中还是非常常见的，另外也是十分关键的指标，白盒延迟指标往往真实反馈系统内部的延迟，对此建议对核心业务添加黑盒监控，监控该业务延迟指标。
值的注意的是：
- 区分成功请求的延迟和失败请求的延迟很重要
- 慢错误（响应时间长）比快错误（响应时间短）更糟糕
- 跟踪出错请求的延迟
流量（traffic）
使用系统中的某个高层次的指标对系统负载需求所进行的度量，通过流量来表象系统的负载情况，能够根据流量来判断当前服务的承载压力、请求量。对于 Web 服务器来说，该指标通常是每秒 HTTP 请求数量，同时可能按请求类型分类(静态请求与动态请求)；针对音频流媒体系统来说，这个指标可能是网络 I/O 速率，或者并发会话数量；针对键值对存储系统来说，指标可能是每秒交易数量，或每秒的读取操作数量。
流量监控指标：
- 基础监控：磁盘和网卡IO
- 业务监控：服务层面的QPS、PV和UV、各状态业务订单TPM、针对音频流媒体系统来说，这个指标可能是网络I/O速率，或者并发会话数量、针对键值对存储系统来说，指标可能是每秒交易数量，或每秒的读取操作数量
我们常说的容量规划，其实是流量规划，通过流量可得知当前系统的运行状态库，是否达到了它的负荷上限，通过监控流量相关的指标，可以得知我们业务的高峰期，流量的突增突降的情况，从而可以对系统进一步的了解。
错误（error）
错误是指当前系统发生的错误请求，请求失败的速率，要么是显示错误(HTTP 500)，要么是隐式错误(HTTP 200 回复中包含了错误内容)。可以通过错误请求个数计算出相应的错误率，通过错误率来反馈服务的运行状态。
错误可以分为两大类错误，一类是显示错误、另一类是隐士错误：
- 显示错误、指可以立即看出来的错误。比如在 HTTP 请求中，响应状态码出现 500，则可以认定为是显示错误。
- 隐式错误：指表面上显示完全正确，但是在数据中已经出现异常的错误。如 HTTP状态是200，但是接口内部还有业务本身自定义的状态码来判断是否正确。这类错误就是隐士错误，属于业务类。
错误监控指标：
- 基础监控：宕机、磁盘（坏盘或文件系统错误）、进程或端口挂掉、网络丢包
- 业务监控：错误日志、业务状态码、错误码走势
错误是在添加监控时首要关注的监控指标，更能反馈出业务的错误率，主要功能或接口、以及内部存在明显边界的功能模块和上游依赖模块，都应该添加端到端的监控。
饱和度（saturation）
饱和度通常是指某个资源的使用率。通常指的是我们通过容量的最大值和现在的使用量，来判断这个容量是否“满”了。某些程序，如果资源饱和度过高，可能会导致执行缓慢，甚至无法使用。如 CPU 使用率如果达到 100%，会出现执行缓慢；Dubbo 进行 RPC 调用时，如果线程池没有可用的线程数，则会使业务受到阻碍。内存溢出。
饱和度一般也会配合其他指标一起使用，比如在使用网络 I/O 时，网卡都是有流量上限的，我们通过流量上限值和当前网络 I/O 的使用情况，可以得知相应的饱和度。饱和度是衡量我们这个系统是否到达瓶颈的关键。如饱和度过高，这时候就需要考虑扩容、减少数据量或是其他降低饱和度的操作了。
饱和度监控指标：
- 基础监控：CPU使用率、I/O使用率、内存使用率、队列积压长度
- 业务监控：线程池使用率，连接池。
通常通过饱和度来度量服务的资源利用率是否达到极限，及流量增长趋势来进行容量规划，一般情况下饱和度不建议将利用率打满，否则一旦打满可能导致服务出现雪崩的情况。
监控指标定义
指标的含义和精度是不同的，不同的指标观测的精度是不同的，系统应当以不同指标的不同精度进行度量和观测
- 观察 1 分钟内的 CPU 平均值可能会错失导致长尾延迟过高的某种较长时间的 CPU 峰值现象。
- 对于一个每年停机时间小于 9 小时的 Web 服务来说(年度可用绿 99.9%)，每分钟检测 1 次或 2 次的监控频率可能过于频繁。
- 对目标可用率为 99.9%的某个服务每 1 分钟或者 2 分钟检查一次硬盘剩余空间可能也是没必要的。
- 观测近两周内流量增长趋势，可能比观测近一天内的流量增长趋势，更加明确。
监控系统设计
监控系统是从多个维度，多个视角监控，比如业务数据监控，系统资源监控，中间件监控，数据库监控等，监控是系统的眼睛，通过加入埋点、指标监控、数据监控，能及时发现系统出现的问题，及时介入处理，及时止损。
监控是在设计阶段就必须考虑监控，而不是在实施完毕之后补充。例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发 (Metrics Driven Development) 的理念。
监控也是提高整个平台可用性的一个重要手段，多平台进行多个维度的监控；模块在运行时候是透明的，以达到运行期白盒化。
立体化监控
立体化就是将故障分析和定位时涉及的所有的相关信息都要监控起来，共分为5层，具体各层和含义如下：
业务层
收集和分析业务层的访问量、成功率等指标。例如当系统被刷的时候，业务层能够一目了然的看出访问量会增加很多
应用服务层
应用服务层指的是以URI为维度的分析，可以看到某个URI的访问量、HTTP响应码分布、HTTP响应时间等指标。应用服务层与业务层并不是一 一对应的关系，一个业务可能对应多个应用服务层的URI，一个URI也可能对应多个业务层的业务。
接口调用层
接口调用层指的是系统依赖的外部系统接口，收集的信息包括访问情况，包括时延、错误码、次数等，当外部系统故障导致我们的业务故障时，通过接口调用层就能够快速的定位具体问题。
基础组件层
基础组件层指系统依赖的底层组件，例如容器、数据库、缓存、消息队列。不同的组件收集的信息不一样，例如数据库MySQL的监控指标包括连接数、请求数、查询行数、更新行数等，而缓存memcached包括使用率、踢出率、命中率等。
基础设施层
基础设施层指操作系统状态、网络状态，收集的信息包括cpu使用率、内存使用率、网卡流量、连接数等。
告警设计
如果没有实时报警，系统运行状态的不确定性会造成无法量化的灾难。因此监控系统指标如下：
- 实时性-要能够实现秒级监控
- 全面性-覆盖所有系统业务，确保无死角覆盖
- 实用性-预警分为多个级别，监控人员可以方便实用地根据预警严重程度做出精确的决策
- 多样性-预警方式提供推拉模式，包括短信，邮件，可视化界面，方便监控人员及时发现问题
- 收敛性-对于同样的告警，防止告警泛滥，能够对告警收敛，并根据收敛规则进一步根据告警重要程度升级告警。
监控设计原则
设计监控系统时一定要力求简单，而非简略。在选择需要监控什么的时，可以参考如下原则：
- 挑选最能反映真实故障的告警规则，这些规则应该足够简单、可预测性强、非常可靠
- 不常用的数据、聚合和告警规则应定期清理，例如一个季度都没有用到一次就立即删除
- 已收集但没有配置任何看板的指标，应定期清理
- 监控一体化平台，而非监控零散到各个平台
- 监控应是多维度，而不是单一维度
- 不允许没有监控的系统上线。
小结
监控是一门很重要的学问，监控系统设计对系统稳定性建设有着很重要的意义，监控是多维度立体化的监控，监控需要持续完善和更新的，同样是需要被治理的，防止监控腐化，好的监控是随着业务的变化而变化的，及时清理无用的监控指标，减少信息繁琐。
