绝大部分通用的术语： （a）监控（monitoring）：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等 （b）白盒监控（white-box monitoring）：依靠系统内部暴露的一些性能指标进行监控。包括日志分析、Java虚拟机提供的监控接口，或者一个列出内部统计数据的HTTP接口进行监控。 （c）黑盒监控（black-box monitoring）：通过测试某种外部用户可见的系统行为进行监控。 （d）监控台页面（dashboard）：提供某个服务核心指标一览服务的应用程序（一般是基于Web的）。该应用程序可能会提供过滤功能（filter）、选择功能（selector）等，但是最主要的功能是用来显示系统最重要的指标。该程序同时可以显示相应团队的一些信息，包括目前工单的数量、高优先级的Bug列表、目前的on-call工程师和最近进行的生产发布等。 （e）警报（alert）：目标对象是某个人发向某个系统地址的一个通知。目的地可以包括工单系统、E-mail地址，或者某个传呼机。相应的，这些警报被分类为：工单、E-mail警报，以及紧急警报（page）。 （f）根源问题（root cause）：指系统（软件或流程）中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不会再以同样的方式发生。 （g）节点或者机器（node/machine）：这里的两个术语是可以互换的：指在物理机、虚拟机，或者容器内运行的某个实例。 （h）推送（push）：关于某个服务正在运行的软件或者其配置文件的任何改动。 某个单独的物理机器上可能有多个服务需要监控，这些服务可能具有如下特点: （a）相互关联的服务：例如Web服务器与对应的缓存服务器。 （b）不相关的服务，它们仅仅共享硬件：例如代码仓库和把文件存放在代码仓库中的配置管理系统的主进程。 为什么要监控: （a）分析长期趋势 （b）构建监控台页面 （c）临时性的回溯分析（也就是在线调试） 监控系统应该解决两个问题：什么东西出故障了，以及为什么出故障。 “什么东西出故障了”即为现象（symptom）:“为什么”则代表了原因（可能只是中间原因，并不是根源问题） 黑盒监控与白盒监控最简单的区别是： （a）黑盒监控是面向现象的，代表了目前正在发生的—而非预测会发生的—问题，即“系统现在有故障”。 （b）白盒监控则大量依赖对系统内部信息的检测，如系统日志、抓取提供指标信息的HTTP节点等。白盒监控系统因此可以检测到即将发生的问题及那些重试所掩盖的问题等。 4个黄金指标: （a）延迟：服务处理某个请求所需要的时间。这里区分成功请求和失败请求很重要。 （b）流量：使用系统中的某个高层次的指标针对系统负载需求所进行的度量。对Web服务器来说，该指标通常是每秒HTTP请求数量，同时可能按请求类型分类（静态请求与动态请求）。 （c）错误请求失败的速率，要么是显式失败（例如HTTP 500），要么是隐式失败（例如HTTP 200 回复中包含了错误内容），或者是策略原因导致的失败（例如，如果要求回复在1s内发出，任何超过1s的请求就都是失败请求）。 （d）饱和度：服务容量有多“满”。通常是系统中目前最为受限的某种资源的某个具体指标的度量。很多系统在达到100% 利用率之前性能会严重下降。 关于长尾问题 区分平均值的“慢”和长尾值的“慢”的一个最简单办法是将请求按延迟分组计数（可以用来制作直方图）：延迟为0～10ms之间的请求数量有多少，30～100ms之间，100～300ms之间等。将直方图的边界定义为指数型增长（这个例子中倍数约为3）是直观展现请求分布的最好方式。 每秒收集CPU负载信息可能会产生一些有意思的数据，但是这种高频率收集、存储、分析可能成本很高。如果我们的监控目标需要高精度数据，但是却不需要极低的延迟，可以通过一些内部采样机制外部汇总的方式降低成本。 指标的收集和汇总，加上警报系统与监控台系统，作为一个相对独立的系统运行是比较好的。 当为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报： （a）该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障？ （b）是否可以忽略这条警报？什么情况可能会导致用户忽略这条警报，如何避免？ （c）是否可以忽略这条警报？什么情况可能会导致用户忽略这条警报，如何避免？ （d）收到警报后，是否要进行某个操作？是否需要立即执行该操作，还是可以等到第二天早上再进行？该操作是否可以被安全地自动化？该操作的效果是长期的，还是短期的？ （e）是否也会有其他人收到相关的紧急警报，这些紧急警报是否是不必要的？ 应对紧急警报上的一些深层次的理念： （a）每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。 （b）每个紧急警报都应该是可以具体操作的。 （c）每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。 （d）每个紧急警报都应该是关于某个新问题的，不应该彼此重叠。 如果某个紧急警报满足上述四点，那么不论是从白盒监控系统还是黑盒监控系统发出都一样。最好多花一些时间监控现象，而不是原因。针对“原因”来说，应该只监控那些非常确定的和非常明确的原因。 关于监控系统的设计决策应该充分考虑到长期目标。今天发出的每个紧急警报都会占用优化系统的时间，所以经常会牺牲一些短期内的可用性和性能问题，以换取未来系统性能的整体提升。 一些团队成员想要实现某种“hack”从而为真正的修复方案争取时间，而另外一些成员则担心实现这个“hack”会使得真正的修复优先级无限降低。这种担心是正确的，确实这种打补丁的形式会造成无法维护的系统债务。
Processed:
0.013, SQL:
8
