监控的大部分通用的术语：
监控(monitoring)
收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型， 错误的数量和类型，以及处理用时，应用服务器的存活时间等。
白盒监控(white-box monitoring)
依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监 控接口，或者一个列出内部统计数据的HTTP接口进行监控。
黑盒监控(black-box monitoring)
通过测试某种外部用户可见的系统行为进行监控。
监控台页面(dashboard)
提供某个服务核心指标一览服务的应用程序(一般是基于Web的)。该应用程序可能会提供过滤功能(filter)、选择功能(selector)等，但是最主要的功能是用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息，包括目前工单的 数量、高优先级的Bug列表、目前的on-call工程师和最近进行的生产发布等。
警报(alert)
目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、 E-mail地址，或者某个传呼机。相应的，这些警报被分类为：工单、E-mail警报41, 以及紧急警报(page)。
根源问题(root cause)
指系统(软件或流程)中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题 不会再以同样的方式发生。某一个故障情况可能同时具有多个根源问题：例如，有可能自动化程度不够，软件在异常输入下崩溃，以及对生成配置文件的脚本测试不足等。这里每一个因素都是一个根源问题，并且每一个都需要被修复。
节点或者机器(node/machine)
这里的两个术语是可以互换的：指在物理机、虚拟机，或者容器内运行的某个实例。 某个单独的物理机器上可能有多个服务需要监控，这些服务可能具有如下特点。
●相互关联的服务：例如Web服务器与对应的缓存服务器。
●不相关的服务，它们仅仅共享硬件：例如代码仓库和把文件存放在代码仓库中 的配置管理系统的主进程。例如Puppet(https://puppetlabs.com/puppet/puppet- open-source)和Chef(Configuration Management System Software - Chef Infra | Chef)。
推送(push)
关于某个服务正在运行的软件或者其配置文件的任何改动。
要对监控系统设置合理预期
现象与原因
黑盒监控与白盒监控
黑盒监控与白盒监控最简单的区别是：黑盒监控是面向现象的，代表了目前正在发生的而非预测会发生的问题，即“系统现在有故障”。白盒监控则大量依赖对系统内部信息的检测，如系统日志、抓取提供指标信息的HTTP节点等。白盒监控系统因此可以检测到即将发生的问题及那些重试所掩盖的问题等。
注意，在一个多层系统中，某一个服务的现象是另外一个服务的原因。例如，数据库性能问题。数据库读操作很缓慢是数据库SRE检测到的一个现象。然而，对前端 SRE来说，他们看到的是网站缓慢，数据库读操作的缓慢则是原因。因此，白盒监控有 时是面向现象的，有时是面向原因的，这取决于白盒系统所提供的信息。
当收集用于调试的遥测数据时，白盒监控是必不可少的。如果Web服务器看起来在那些依赖数据库的请求上很慢时，我们需要同时知道Web服务器检测到的数据库速度与数据库自己检测到的速度。否则，无法区分出到底是数据库问题还是Web服务器与数据库服 务器之间的网络问题。
黑盒监控可以保证系统只在某个问题目前正在发生，并且造成了某个现象时才会发出紧急警报。另外一方面，针对那些还没有发生，但是即将发生的问题，黑盒监控通常是没用的。
监控的4个黄金指标
监控系统的4个黄金指标分别是延迟、流量、错误和饱和度。如果我们只能监控用户可见系统的4个指标，那么就应该监控这4个。
设计监控系统
设计监控系统时一定要追求简化
●那些最能反映真实故障的规则应该越简单越好，可预测性强，非常可靠。
●那些不常用的数据收集、汇总，以及警报配置应该定时删除(某些SRE团队的标准是一个季度没有用到一次即将其删除)。
●收集到的信息，但是没有暴露给任何监控台，或者被任何警报规则使用的应该定 时删除。
当为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报：
●该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发 生或者已经发生的用户可见故障?
●是否可以忽略这条警报?什么情况可能会导致用户忽略这条警报，如何避免?
●这条警报是否确实显示了用户正在受到影响?是否存在用户没有受到影响也可以 触发这条规则的情况?例如测试环境和系统维护状态下发出的警报是否应该被过滤掉。
●收到警报后，是否要进行某个操作?是否需要立即执行该操作，还是可以等到第 二天早上再进行?该操作是否可以被安全地自动化?该操作的效果是长期的，还 是短期的?
●是否也会有其他人收到相关的紧急警报，这些紧急警报是否是不必要的?
以上这些问题其实反映了在应对紧急警报上的一些深层次的理念：
●每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。
●每个紧急警报都应该是可以具体操作的。
●每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要 一个固定的机械动作，那么它就不应该成为紧急警报。
●每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。
从这种角度出发，我们可以得出以下结论：如果某个紧急警报满足上述四点，那么不论 是从白盒监控系统还是黑盒监控系统发出都一样。最好多花一些时间监控现象，而不是原因。针对“原因”来说，应该只监控那些非常确定的和非常明确的原因。
监控系统的长期维护
在现代生产环境中，监控系统需要跟随不断演变的软件一起变化，软件经常重构，负载 特性和性能目标也经常变化。现在的某个不常见的、自动化比较困难的警报可能很快就 会变成一个经常触发、需要一个临时的脚本来应对的问题。这时，某个人应该去寻找和 消除背后的根源问题：如果这种解决办法不可行，那么这条警报的应对就必须要完全自 动化。
关于监控系统的设计决策应该充分考虑到长期目标。今天发出的每个紧急警报都会占用优化系统的时间，所以经常会牺牲一些短期内的可用性和性能问题，以换取未来系统性能的整体提升
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
