监控-监控介绍

1、监控系统概述

• 监控是运维团队眼睛的延伸。监控系统应当解决三个问题：“出问题了吗？”“哪里出了问题？”“是什么问题？”

1、监控系统有四大功能

• 数据采样：通过传感器(sensor)进行数据采样
• 数据存储：
  • 要存储两类数据：历史数据、趋势数据
• 数据展示：即可视化
• 报警：采集到的数据超出阈值

2、要监控的资源

• 硬件：
• cpu（负荷在90%以上，或95%以上就告警）
• 内存空间使用率（长期调用swaf空间，物理内存不够用）
• 软件：
  • 比如nginx进程是否正常，子进程数量是否是定义的数量
• 业务：
  • 并发在线数支撑率有多高
  • mysql数据库（每秒钟的查询数量、修改数量，每秒钟的事务数量）

3、被监控对象

• 主机、交换机、路由器、UPS

4、监控系统的四个阶段

• 监控系统有4个发展阶段，也是度量监控系统的方法，以及对监控改进的指南，可用于评估当前监控系统的成熟度级别以及可采用的改进步骤。
  • 第1级是组件监控，可以反映每个组件的状态并根据策略进行警报通知。
  • 第2级是对各层级进行监控，从各个层级、角度收集运行信息，包括各种指标度量值、输出日志、服务追踪信息等。
  • 第3级不仅查看所有的状态、事件和度量，还查看依赖关系并跟踪动态变更情况，数据用可视化工具展现，以实时洞察整个系统的总体运行情况。
  • 第4级是智能化，是更远大愿景的一部分，能够在发生故障之前发送警报，通过扩展或重路由服务来实现自我治愈、异常检测等。

• 当从监控成熟度第1级晋升到第2级，将获得对系统更深入的洞察力，将更好地理解服务的可用性和性能。
• 从第2级到第3级，将可以在整个IT系统中获得全栈的可见性，并精确地理解业务流程、应用程序和基础架构之间的依赖关系。无论是云计算、应用程序、还是基础设施，都可以采用更加主动的监控方法来支持数字企业的需求。
• 进入第4级时，将获得预测分析能力，这将帮助企业预测可能发生的问题、指出可能的原因，IT维护更智能、敏捷、高效。

2、什么是监控

• 从技术角度来看，监控（monitoring）是衡量和管理技术系统的工具和流程。
• 但监控的意义远不止于此，监控将系统和应用程序生成的指标转换为对应的业务价值。监控系统会将这些指标转换为衡量用户体验的依据：
  • 该依据为业务提供反馈，以确保为客户提供了所需的产品。
  • 同时该依据还提供了对技术的反馈，指出哪些组件不起作用或者导致服务质量下降。
• 一个监控系统有两个客户：
  • 技术
  • 业务

1、技术作为客户

• 监控系统的第一个客户是技术，这是你、你的团队以及其他管理和维护技术环境的同事（可能被称为运维工程师、DevOps或是SRE）需要面对的。

• 可以通过监控来了解技术环境的状态，还可以帮助检测、诊断和解决技术环境中的故障和问题（尤其是在影响用户之前）。
• 监控提供了大量的数据，帮助对关键的产品和技术进行决策，并衡量这些项目是否成功。
• 监控也是产品管理生命周期以及与内部客户关系的基础，有助于验证项目资金是否得到充分利用。

• 如果没有监控，那么最好的情况是没有问题发生，最糟糕的情况则是问题发生了但没有被发现。

2、业务作为客户

• 业务是监控系统的第二个客户。监控系统是为了支持业务，并确保业务持续开展。
• 监控提供的报告，使企业能够进行良好的产品和技术投资，还有助于企业衡量技术带来的价值。

3、监控的基础知识

• 监控是管理基础设施和业务的核心工具。
• 监控也是必需的，应该和应用程序一起构建和部署。没有监控，就将无法了解系统环境、进行诊断故障、制定容量计划，也无法向组织提供系统的性能、成本和状态等信息。

• Google服务层次结构图就是一个很好的阐述（如图1-1所示）。

• 监控没有那么容易实施，如果监控了错误的东西或者使用了错误的方式，那么监控系统的价值将大大降低。

1、开发前设计监控指标

• 在应用程序开发中，最好在构建程序之前确定想要监控的内容。但遗憾的是，有一种常见的反模式，即将监控和其他运维工作（比如安全性）视为应用程序的增值组件而非核心功能。
• 与安全性一样，监控也应该是应用程序的核心功能。
• 在为应用程序构建规范或用户描述时，务必把应用程序每个组件的监控指标考虑进来，千万不要等到项目结束或部署之前再做这件事情。

2、监控从应用服务开始

• 许多环境都会为所有应用程序建立货物崇拜（Cargo Cult）式的监控系统。即团队始终使用他们过去使用的检查机制，而不会为新系统或应用程序进行更新。
  • 一个常见的例子是监控每台主机上的CPU、内存和磁盘，但不监控可以指示主机上应用程序是否正常运行的关键指标。如果应用程序发生故障但没有被监控到，那么即使进行了监控，也要考虑监控是否合理了。
  • 货物崇拜编程（Cargo Cult Programming）是一种计算机程序设计中的反模式，其特征为不明就里地、仪式性地使用代码或程序架构。货物崇拜编程通常是程序员既没理解他要解决的bug、也没理解表面上的解决方案的典型表现。
• 根据服务价值设计自上而下的监控计划是一个很好的方式（如图1-2所示）。确定应用程序中交付价值的部分，并首先监控这部分，然后逐级递减。

 

 

• 从业务逻辑和业务输出开始，再到应用程序逻辑，最后到基础设施。
  • 这并不意味着要忽视对基础设施或操作系统指标的收集——它们在诊断和容量规划中有价值，但是您不太可能使用它们来报告应用程序的价值。
• 如果无法从业务指标开始，则可试着从靠近用户侧的地方开始监控。因为他们才是最终的客户，他们的体验是推动业务发展的动力，了解他们的体验并发现他们何时遇到问题本身就很有价值。

3、监控服务的正确性

• 一个常见的反模式是虽然监控了主机上的服务状态，但不监控其正确性。例如，通过检查HTTP 200响应代码来监视一个web应用程序是否正在运行，它只能说明应用程序正在响应请求，但并不能说明返回的数据是正确的。
• 更好的方法是监控服务的正确性。例如，监控业务事务的内容或速率，而不是web服务器正常运行的时间。这样做有两个好处：
  • 如果服务因配置错误、程序bug或受损而导致内容不正确，可以及时的被监控发现。
  • 如果内容因底层Web服务而出现错误，也可以被及时的发现。

4、静态阈值

• 另一种反模式是使用静态阈值。例如，如果主机的CPU使用率超过80％就发出警报。这种检查通常是一个布尔值或者一段时间内的静态阈值，它们通常会匹配特定的结果或范围，这种模式没有考虑到大多数复杂系统的动态性。阈值被匹配或突破可能很重要，也可能是由异常事件触发的，甚至可能是自然增长的结果。

• 静态阈值几乎总是错误的。数据库性能分析供应商VividCortex的首席执行官Baron Schwartz对此评论道：它们比坏掉的时钟更糟糕，至少坏掉的时钟每天还会有两次准的时候。
• 阈值对于任何给定的系统都是错误的，因为所有的系统都略有不同。而且阈值在任何给定的时刻也都是错误的，因为系统的状态是在不断变化的。
• 为了更好地监控，我们需要查看数据窗口，而不是静态的时间点，需要使用更智能的技术来分析指标和阈值。

5、监控周期

• 对于许多监控工具来说，设定监控周期都是一个挑战，一般默认检查周期会设置一个较大的值。例如，每隔5～15分钟检查一次。这通常会导致检查之间发生的关键事件丢失。你应该检查周期应该足够小，这样做有以下好处：
  • 识别故障或异常。
  • 满足响应时间预期--你绝对希望在用户报告故障之前找到问题。
  • 提供更细颗粒度的数据，以识别性能的问题和趋势。
• 一定要记住，存储足够多的历史数据，可以有效地帮助识别性能的问题和趋势。在很多情况下，这可能只需要数天或数周的数据--但如果丢弃了这些数据，则可能无法识别出趋势或发现重复出现的问题。

6、自动化或自服务

• 监控系统很差或者没能正确实施的常见原因是它很难实现。
  • 如果你让应用程序开发人员觉得监控应用程序、收集数据或可视化很难完成，那么他们可能就不会去做这些事。
  • 如果监控的基础设施是手动维护的，或者过于复杂，那么由此产生的问题将导致你花费更多的时间来修复和维护监控系统。
• 应尽可能使监控系统的实施和部署自动化：
  • 应该由配置管理进行部署。
  • 主机和服务的配置应该通过自动发现或自助提交来进行，这样可以自动监控新的应用程序，而不需要人为添加。
  • 添加检测应该很简单，并且是基于插件模式，开发人员应该能够把它放置到库中，而不是必须自己配置它。
  • 数据和可视化应该是自服务。每个需要查看监控输出的人都应该能够查询和可视化这些内容。（这并不是说你不应该为人们构建仪表板，而是如果他们想要更多，他们就不应该问你。）

7、监控模式总结

• 一个良好的监控系统应该能提供以下内容：
  • 全局视角，从最高层（业务）依次展开。
  • 协助故障诊断。
  • 作为基础设施、应用程序开发和业务人员的信息源。
• 同时它也应该是：
  • 内置于应用程序设计、开发和部署的生命周期中。
  • 尽可能自动化，并提供自服务。

4、监控机制

• 监控的方法是多种多样的，实际上，你可以说从单元测试到检查清单（checklist）的所有事情都是监控的某种形式。
• 但是传统上，监控的定义侧重于检查和测量应用程序的状态。

1、探针和内省

• 监控应用程序主要有两种方法：探针（probing）和内省（introspection）。
  • 有些人将探针和内省分别称为黑盒监控和白盒监控。
• 探针监控是在应用程序的外部，它查询应用程序的外部特征：监听端口是否有响应并返回正确的数据或状态码。例如，执行ICMP检查并确认可以收到响应。Nagios就是一个主要基于探针监控的监控系统。
• 内省监控主要查看应用程序内部的内容。对应用程序进行检测，并返回其状态、内部组件状态或者事务和事件性能的度量值。这些数据可准确显示应用程序的运行方式，而不仅是其可用性或其表面行为。内省监控可以直接将事件、日志和指标发送到监控工具，也可以将信息发送给状态或健康检查接口，然后由监控工具收集。

• 内省方法提供了应用程序实际运行的状态，它提供比探针监控更丰富且更多的有关应用程序状态的信息，是能提供信息的更好方式。
• 这并不是说探针监控没有作用了，了解应用程序的外部状态通常很有用，特别是如果应用程序由第三方提供，并且你没有深入了解其内部操作的时候。从外部查看应用程序以了解某些网络、安全性或可用性问题通常也很有用。

• 通常建议对安全网络进行探针监控以发现问题，然后使用内省监控进行报告和诊断。

2、拉取和推送

• 目前有两种执行监控检查的方式：拉取（pull）和推送（push）。

• 基于拉取的监控方式会抓取或检查远程应用程序。例如，包含指标的端点，或是使用ICMP进行的检查。
• 基于推送的监控方式中，应用程序发送事件给监控系统接收。

3、监控数据的类型

• 监控工具可以收集各种不同类型的数据，这些数据主要有两种形式：
  • 指标：大多数现代监控工具都非常依赖指标来帮助我们了解系统的情况。指标存储为时间序列数据，用于记录应用程序的状态。
  • 日志：日志是从应用程序发出的（通常是文本的）事件。虽然有助于让你知道发生了什么，但它们通常对故障诊断和调查最有帮助。

5、指标

• 指标是所有监控系统中最直观的部分。因此，有时候我们并没有投入足够的时间去理解我们在收集什么，为什么要收集，以及如何使用这些指标。

• 很多监控系统的重点都是故障检测，即检测是否发生了特定的系统事件或状态（这是Nagios的风格）。当收到有关特定系统事件的通知时，通常会查看收集到的指标，以找出发生的事件及其原因。在这个思路下，指标被视为故障检测的副产品或者补充。
• Prometheus改变了“指标作为补充”的观念，指标变成了监控工作流程中最重要的部分。Prometheus颠覆了以故障检测为中心的模型，指标用来反映环境的状态、可用性以及性能。

• 正确地使用指标可以提供基础设施的动态实时信息，帮助你管理和做出有关系统的最佳决策。此外，通过指标做异常检测和模式分析，有可能在故障或问题发生之前，或者是特定系统事件导致系统瘫痪之前就有所察觉。

5.1、什么是指标

• 由于指标对监控系统至关重要，因此我们要了解到底什么是指标，以及如何使用这些指标。了解不同类型的指标、数据和可视化在监控系统中有什么作用。
• 指标是软件或硬件组件属性的度量。
  • 为了使指标有价值，我们会跟踪其状态，通常记录一段时间内的数据点，这些数据点称为观测值（observation）。
  • 观察值通常包括值、时间戳，有时也涵盖描述观测值的一系列属性（如源或标签）。
  • 观察值的集合称为时间序列。
• 时间序列数据的典型示例就是网站访问或点击量。我们定期收集网站的点击量，我们还可以收集诸如访问源、命中哪个服务器或其他各种信息等。

• 通常以一个固定的时间间隔收集数据，该时间间隔被称为颗粒度（granularity）或分辨率（resolution），取值可以从1秒到5分钟，甚至是60分钟或更长。
• 选择适合指标的颗粒度至关重要。
  • 若颗粒度太大，则很容易错过某些细节。例如，以5分钟为间隔对CPU或内存使用情况进行采样，这几乎不可能识别出数据中的异常情况。
  • 如果颗粒度太小，则需要存储和分析大量数据。

• 时间序列数据是这些观察值按时间顺序排列的集合。
• 时间序列指标通常被可视化为二维图形，其中x轴是时间，y轴是具体的数据值（如图1-3所示）。通常，你会在y轴上看到多个数据值——例如，来自多个主机的CPU使用率值，或者成功和失败的事务。

• 图形非常有用，它们提供了相对容易理解的关键数据的可视化展示，比使用列表形式更加直观有效。图形还展示了任何历史时间的情况，包括什么时候发生了变化，发生什么。

5.2、指标类型

1、测量型

• 测量型（gauge），是一个上下增减的数字，本质上是特定度量的快照。
• 常见的测量型监控指标有CPU、内存和磁盘使用率等。对于业务来说，可能是网站上的客户数量（如图1-4所示）。

2、计数型

• 计数型（counter）是随着时间增加而不会减少的数字。虽然它们永远不会减少，但有时可以将其重置为零并再次开始递增。

• 应用程序和基础设施常见的计数型指标有系统正常运行时间、设备收发包的字节数和登录次数等。对于业务来说，可能是一个月内的销售数量或应用程序收到的订单数量（如图1-5所示）。
• 在图1-5的示例中，就是一个计数型指标在一段时间内的递增。

• 计数型指标的优势是可以使用它们计算变化率。可以用t+1时刻的值减去t时刻的值，得到两个值之间的变化率。
• 通过两个值之间的变化率，可以得到许多有用的信息，例如登录次数是一个比较有用的指标，可以通过计算变化率来查看每秒的登录次数，这应该有助于确定站点流行的时间段。

5.3、统计指标

• 通常来说，单个指标的价值很小，往往需要联合并可视化多个指标，这需要应用一些数学变换。例如，将统计函数应用于指标或指标组，一些可能应用的常见函数包括：
  • 计数：计算特定时间间隔内的观测值的数量。
  • 求和：将特定时间间隔内所有观测值进行累加。
  • 平均值：提供特定时间间隔内所有值的平均值。
  • 中间数：数值的几何中点，正好50％的数值位于它前面，而另外50％则位于它后面。
  • 百分位数：占总数特定百分比的观测值。
  • 标准差：显示指标分布中与平均值的标准差，这可以测量出数据集的差异程度。标准差为0表示数据都等于平均值，较高的标准差意味着数据分布的范围很广。
  • 变化率：显示时间序列中数据之间的变化程度。

5.4、指标聚合

• 最典型的指标聚合就是在一张图上显示多个指标，这样更容易观察指标的发展趋势，例如所有应用程序服务器磁盘空间的使用情况。（如图1-7所示）。
• 单一指标和聚合指标的组合可以提供最佳的健康状况视图：前者用于深入研究特定问题，后者用于查看高级状态。

6、监控方法

• 两种监控方法：
  • Brendan Gregg的USE或者 Utilization Saturation and Errors Method方法，专注于主机级监控。
  • Google的四个黄金指标，主要用于应用程序级监控。
• 监控方法提供的指导原则，可以帮你缩小范围并专注于所收集的海量时间序列中的特定指标。
• 两个监控方法，一个侧重于主机级性能，一个侧重于应用程序级性能，结合使用可以获得一个相当全面的监控系统，帮助你解决任何问题。

6.1、USE方法

• USE（Utilization Saturation and Errors Method）是由Brendan Gregg开发的，他是Netflix的核心和性能工程师。该方法为服务器指标创建一个清单，以便快速识别问题。（使用收集的数据和清单对照来确定常见的性能问题）
• USE方法可以总结为：对于每一种资源，检查利用率、饱和度和错误。
  • USE方法监控那些高使用率或饱和度的资源是最有效的。
• use方法的清单中有以下术语：
  • 资源(resource)：系统的一个组件。在Gregg对模型的定义中，它是一个传统意义上的物理服务器组件，如CPU、磁盘等，但许多人也将软件资源包含在定义中。
  • 使用率(Utilization)：资源忙于工作的平均时间。它通常用随时间变化的百分比表示。
  • 饱和度(Saturation)：资源排队工作的指标，无法再处理额外的工作。通常用队列长度表示。
  • 错误数量(Errors)：资源错误事件的计数。
• 假设有一个严重的性能问题，可以根据清单检查每个被监控的资源的各个属性值。
  • 在这个示例中，将从CPU开始：
    • CPU使用率随时间的百分比。
    • CPU饱和度，等待CPU的进程数。
    • 错误事件数量，通常对CPU资源不太有影响。
  • 然后是内存：
    • 内存使用率随时间的百分比。
    • 内存饱和度，通过监控swap测量。
    • 错误事件数量，通常不太关键，但也可以捕获。
  • 其他组件以此类推，直到找到问题。

6.2、Google的四个黄金指标

• Google的四个黄金指标来自Google SRE手册，它们采用与USE类似的方法，指定一系列要监控的通用指标。
  • 延迟(Latency)：服务请求所花费的时间，需要区分成功请求和失败请求的延迟。例如，失败请求可能会以非常低的延迟返回错误结果。
  • 流量(Traffic)：针对系统，例如，每秒HTTP请求数，或者数据库系统的事务。
  • 错误率(Errors)：请求失败的比率，无论是显式失败(如HTTP 500错误)，隐式失败(如返回错误或无效的内容)，还是基于策略的失败(例如，如果规定超过30ms的失败被视为错误)。
  • 饱和度(Saturation)：应用程序有多“满”，或者受限的资源，如内存或I/O。也包括即将到来的饱和，例如快速填充磁盘。
• 黄金指标使用起来很简单。依次选择对应的高阶指标，然后为它们设置告警。如果其中一个指标出现问题，那么就会告警，然后你可以去诊断或解决问题。

7、警报和通知

• 告警和通知是监控工具的主要输出。

• 告警和通知的什么区别呢？
  • 告警：当发生某些事情时(例如，当指标值达到阈值时)将发出告警。然而，这并不意味着会通知给其他人。
  • 通知：接收到告警后，通知某人或某些人什么时候发生了什么事（通过发送电子邮件、发送短信等）
• 要建立一个出色的通知系统，需要考虑以下基础信息：
  • 哪些问题需要通知
  • 通知给哪些人
  • 如何通知他们
  • 多久通知他们一次
  • 何时停止通知以及何时升级通知给其他人
• 如果配置不当，导致通知过多，那么人们将无法对它们采取行动，甚至可能忽略掉它们。
• 我们都有这样的经历：收件箱收到了成千上万封来自监控系统通知邮件。我们会因为收到很多通知而出现告警疲劳，并且忽略它们（或者更糟糕的是，对通知邮件直接全部删除）。因此，可能会错过真正的重要通知。

• 最重要的是，需要考虑如何告诉接收通知的人。通常当出现问题或者有事件需要你关注时，通知是唯一的途径。它们需要简洁、清晰、准确，易于理解并且可操作。设计有价值、有意义的通知至关重要。
• 通知的内容重点关注几点：
  • 使通知清晰、准确、可操作。（请人工编写通知）
  • 为通知添加上下文。通知应包含组件的其他相关信息。
  • 仅发送有意义的通知。（例如，通知磁盘使用率已达到91％，但总容量是1GB还是1TB，是有很大区别的）

8、可视化

• 指标及其可视化通常很难解释。人们在查看可视化图像时，往往会幻想出并不存在的事物间的联系：从随机数据中找到有意义的模式。这通常会导致从相关性到因果关系的突然飞跃，而数据的颗粒度、表示数据的方式以及数据的规模可能会进一步加剧这种飞跃。

• 理想的可视化应该能够清晰地显示数据，突出重点而不仅是提高视觉效果。
• 可视化的构建规则：
  • 清晰地显示数据
  • 引发思考（而不是视觉效果）
  • 避免扭曲数据
  • 使数据集保持一致
  • 允许更改颗粒度而不影响理解

#                                                                                                                        #

被监控对象：主机、交换机、路由器、UPS