prometheus-监控基础理论-1

监控概论

理论来源： 1、监控概论基础， prometheus监控实战一书

一、监控系统基础

业务逻辑 --> 应用程序 --> 操作系统 --> 监控框架

        找准服务监控的内容–例如：监控业务事务的内容或速率、而不是监控它运行的web服务器的运行时间， 你会获得两种好处： 如果服务因配置错误、程序bug或受损而导致内容不正确，能够及时看到；而如果内容因底层web服务而出现错误，你同样也会知道。

        而对于运维工程师来讲其相关岗位三大核心技能主要包括，故障管理、变更管理和资源管理，其中故障管理，也是所谓的SRE当中一个非常重要的地方，因为SRE的全称叫做，站点可靠性工程师，从某种意义上来讲，它的主要核心职能之一主要就在于提前发现问题，甚至是能够基于某种趋势、数据或者某种服务的运行状态提前发现问题，而后将故障扼杀于萌芽之中

        当然，这其中也包括一些有针对性的，有目的性的设计来完成，因为站点可靠性工程师的最核心目标是评估站点的可靠性有多高，MTTR的概念：称之为平均无故障时间和平均修复时间，其实说白了就是我们要衡量一个站点的可靠性有多高，它应该是用平均无故障时间+平均修复时间的；

        而平均修复时间要想能够降低，首先第一关键任务就是在第一时间能知道发生了问题，而后我们又能快速的定位问题，剩下的就是解决问题了，而能够让我们第一时间发现问题的最为重要的工具其实就是监控系统，因为我们不可能每时每刻不停的不间断的监视着我们系统运行的每一个角落；
        那么这个时候，监控系统就出现了，它通过所谓或主动、或被动、或黑盒、或白盒等方式在我们系统上的多个位置通过下探针或者是加传感器的方式等，能够实现向外暴露自己内部运行状态的相关数据，从而能够被我们的统一的集中式的中央监控系统，把这些数据收集过来，加以分析存储展示等相关功能；

1.1、监控分类

        当我们系统复杂到可能有N个主机来支撑平台系统的运行，那么相对于主机级就有很多对应的资源使用状态或者消耗状态，那我们便需要知道比如CPU、Memory、Disk等等基础资源利用率

• 事后监控
• 机械式监控：比如只监控CPU、内存、磁盘
• 不够准确的监控： 监控页面，运行时间
• 静态监控：如固定的CPU使用率
• 不频繁的监控， 每隔10-20分钟 ，应频繁的监控应用程序，以获取如下好处
  • 识别故障或异常
  • 满足响应时间预期， 在用户报告故障之前找着问题
  • 提供更细颗粒度的数据，以识生能的问题和趋势
• 缺少自动化或自服务， 尽可能使监控系统的实施和部署自动化;
  • 应该由配置管理进行部署
  • 主机和服务的配置 应该通过自动发现或自助提交来进行，这样可以自动监控新的应用程序，而不需要人为添加
  • 添加检测应该很简单，并且基于插件模式，开发人员应该能够把它放置到库中，而不必自己配置它
  • 数据和可视化应该是自服务的，每个需要查看监控输出的人都应该能够查询和可视化这些内容

1.1.1、监控手段

	所以对于这么一个复杂的系统，有这么多的角角落落需要进行监控，那很显然，我们指望人工的去通过Top之类的命令来做监控，显然是不大现实的，所以这个时候，就有了各种各样的辅助监控方式，比如上述提到的黑盒监控，也可以通过探针的方式进行监控，这个探针指的实际就是不断的去刺探对应的服务工作状态是否正常；
    1.  通过一些被动的方式监控服务器的网络流量之类的，来抓去服务器流量当中，有多少正常报文有多少非正常报文
    2. 以主机为例，在操作系统上部署一个监控代理应用程序，帮助我们采集一些指标数据，这个程序不断的请求主机中内核中所暴露的各种太状态信息，比如，CPU的对列、内核空间占用比例、用户空间占用比例、中断占用比例、空闲比例等等；

	但对于现代应用而言一些平台自带的监控代理程序是不一定能满足我们的需求的，他们通常就自带了能够暴露自己运行状态的接口，而如果我们需要的但没法采集的就可以使用黑盒的方式从外部使用所谓的探针进行监控，或者我们在外部加一个专门的代理去抽取对应的应用程序的指标数据；以Redis为例，Redis所提供的redis info这样的接口暴露了当前Redis所有的指标接口，那像这种我们也可以借助于一个专门的应用程序将这些数据周期性的读出来，然后兼容到我们对应到监控系统上去也是可以的；

1.1.2、监控系统

	当我们在系统上安装了各种各样的探针(监控代理应用程序)，那么随后我们就应该将这些探针所抓去的数据将他们收集到一个统一的位置进行统一分析，统一存储
	通常情况下，我们就应该在平台整体的核心系统外部，部署一个所谓的监控系统程序，而上述说到的这些技术手段，主要就是让我们的监控服务器，与之进行通信，并获取到对应系统之上的某个特定测量纬度，向上述所提到的，CPU空闲比例，CPU消耗在内核当中的比例，这些都是测量纬度，我们期望知道它在哪个属性上，到底有什么样的状态变动，而每一个测量纬度，我们通常称之为一个指标(Metric)；
	而我们对应的监控系统就要对每一个系统之上的指标进行采集，而后将采集到到数据纳入到当前监控系统之中，我们要想第一时间知道我们的系统是否发生故障了、是否异常了、是否超出阈值了等等，那么很显然，我们需要持续的监控着被监控对象才行，持续得去获取对方之上特定指标数据，才可以；
	而这个持续，它不是我们理解的这种连续性的，它实际上是一种**离散性的持续**，离散性持续就是周期性的去采集数据，正常情况下应该有哪些监控系统上的哪些被监控指标，我们就需要在我们的监控系统上指明要监控哪个主机，这一个主机叫做一个监控对象，但是在这个对象上可能有很多很多的指标需要采集，一个主机并非一个指标，而且更何况一个主机之上除了系统级指标之外，很有可能还有基础设施类的应用指标，业务类应用指标等；
	这些每一个指标我们都得采集，所以每一个主机之上，都有可能多达上百个指标，甚至更多，而这种在一个较大规模的系统当中，很显然，指标数量多大上万是很正常的，而这种周期性的采集，就意味着需要针对这多达上万个甚至是数万个数十万个指标要不停的按照固定的频率进行采集；

1.2、监控机制

1.2.1、探针和内省

• 探针： 是在应用程序的外部，它查询应用程序的外部物证：监听端口是否有响应并返回正确的数据或状态码。探针监控的一个例子是执行ICMP检查并确认可以收到响应。
  • 探针监控对了解应用程序的外部通常很有用，特别是如果应用程序是由第三方提供，并且没有深入了解其内部操作的时候，从外部查看应用 程序以了解某些网络、安全性或可用性问题通常有很有帮助
• 内省： 主要查看应用程序内部的内容。**应用程序经过检测，并返回其状态、内部组件，或者事务和事件性能的度量，**这些数据可准确显示应用程序的运行方式，而不仅是其可用性或其表面行为、内省监控可以直接将事件、日志和批标发送到监控工具，也可以将信息发送给状态或健康检查接口，然后由监控工具收集。
  • 内省方法提供了应用程序实际运行的状态，它允许你传达比探针监控更丰富且更多的有关应用程序状态上下文的信息，是提供你和业务所需的监控信息的更好方式

1.2.2、推送和拉取

• 拉取： 提取或检查远程应用程序–例如包含指标的端点，或是探针监控使用ICMP进行检查
• 推送：应用程序发送事件给监控系统接收
• 拉取是服务端直接获取客户端数据，推送则是由客户端主动向服务端发送数据

1.3、指标

正确使用指标可以提供基础设施的动态实时信息，帮助管理和做出有关系统的最佳决策

1.3.1、什么是指标

        指标是软件或硬件组件属性的度量，为了使指标有价值，我们会跟踪其状态，通常记录一段时间的数据点，这些数据点称为 观察点，它通常包括 值、时间戳，有时也涵盖描述观察点的一系列属性(源或标签)，观察的集合称为时间序列

1.3.2、指标类型

• 测量型： 这种类型是上下增减的数字，本质上是特定度量的快照，常见的监控指标如CPU、磁盘使用率和内存属于这个类型，对业务指标来说则是网站上的客户数量；
• 计数型： 随着时间增加而不会减少的数字，虽然它们永远不会减少，但有时将其重置为零并再次开始递增，应用程序和基础设施的计数型示例包括系统正常运行时间、设备收发包的字节数或登陆次数， 而业务的示例可能是 一个月内的销售数量或应用程序收到的订单数量
• 直方图： 是对观察点进行采样的指标类型，可以展现数据集的频率分布，直方图可以很好的展现时间序列数据，尤其是数据的可视化（如应用程序的延时)

1.4、监控方法论

• USE方法： 侧重于主机监控

• google的四个黄金法则，专注于应用程序级监控

        监控方法的指导原则可以让咱们缩小范围并专注于所收集到的海量时间序列中的特定指标，结合上面两种方法可以获取一个相当全面的环境视图，帮助解决大部分故障

1.4.1、USE方法

        USE是使用率、饱和度和错误的缩写，USE方法建议创建服务器分析清单，以便快速识别问题，利用从环境中收集的数据，对照清单来确定常见的性能问题；

USE方法可以概括为： 针对每个资源，检查使用率、饱和度和错误，

• 资源： 系统组件： 如CPU、磁盘等
• 使用率： 资源忙于工作的平均时间，它通常用随时间变化的百分比表示
• **饱和度：**资源排队工作的指标，无法再处理额度的工作，通常用队列长度表示
• 错误： 资源错误事件的计数

我们将这些定义结合起来创建一份资源清单，并采用一种方法来监控每个要素：使用率、饱和度和错误，那它们是如何起作用的？

• 从CPU开始：
  • CPU使用率随时间的百分比
  • CPU饱和度，等待CPU的进程数
  • 错误，通常对CPU资源不太有影响
• 内存：
  • 内存使用率随时间的百分比
  • 内存饱和度，通过监控swap测量
  • 错误，通常不太关键，但也可以捕获

1.4.2、google的四个黄金法则

        来自google的SRE手册，它们采用与USE类似的方法，指定要监控的一系列通用指标类型，此方法的指标类型主要关注的不是系统级的时间序列数据，更多是针对应用程序或面向用户的部分

• 延迟： 服务请求所花费用时间
• 流量： 针对系统，例如，每秒HTTP的请求，或数据库系统的事务
• 错误：请求失败的速率，如500，错误内容或无效内容，也可要求响应超过30秒的请求视为错误
• 饱和度： 应用程序有多“满", 或者受限的资源，如内存或IO

1.5、时序数据库

    当指标采集到我们的监控系统之后，如果用户不看，那么数据就消失了，因此，为了能够让用户对这些曾经采集到的数据在这个采集点时间过后再查看，那我们应该将采集的每一个指标的每一个时间点的数据，我们称之为样本数据，都要给它存储下来，才能确保采集时间点过去之后还能看的效果，需要注意的是，这儿的数据我们要针对数据指标来讲，它的数据一定是按照时间顺序生成了很多数据，这样的数据，我们通常称之为时间序列数据(TSDATA)；
	通常这种数据它的存储格式一般都是类似追加的方式来进行数据存储，所以这种存储时序数据的专门的高性能存储系统，就被称之为TSDB，即时间序列数据库，它也是NoSQL系统中的一类，他们都是非关系型数据库；
	当然，这儿我们使用关系型数据库也可以，只不过对于关系型数据库的每一次写入，都是有很高的系统性能开销的，比如我们要查逐渐冲突、唯一键冲突之类的，因而对于较大规模的系统来讲，如果使用关系型数据库存监控数据库的话，很快对应的后端存储系统就会成为系统平静瓶颈；
    像Zabbix就是使用关系型数据库来存储数据的，所以Zabbix在遇到系统规模到一定的时候一定会遇到各种各样的问题，我们必须得对后段数据库系统做性能优化或者进行各种优化措施才能解决相关问题的；
    对于Zabbix来讲，它出现的时间还是很早的，曾经一度也是市面上主流的监控系统，但是随着业务规模的发展，它已经显得有点那么一点不合时宜了，但是对应的系统规模没有到那么大的规模场景当中，Zabbix依然是很好的选择，因为无论是文档、还是成熟度，甚至是稳定性，Zabbix既然是无可比拟的；
    当应用发展到以分布式为核心特性，甚至是以微服务为主导的现代应用架构下的时候，Zabbix无论是对于动态的监控模式的支持不是特别理想，还有它采用传统的关系型数据库作为后端存储，都已经成为了一个弊端了；

1.5.1、样本

        监控系统要将每一个对应的指标数据，都周期性的采集过来，而这些数据副本我们要存下来才能在过后被我们的系统管理人员所分析和利用，而这些数据我们就称之为历史数据，因为他们是过去采集的历史样本；

1.5.2、聚合

	在大多数场景下而言，对于单个指标来讲采集的数据它对我们对意义和作用不大，比如说，我们采集出来我们CPU在内核空间的使用比例，单单仅仅这一个指标，通常来讲，它的可参考价值真的不是特别大，单个指标的参考价值，一般不会特别大；
    这个就意味着，我们需要将这单个指标的历史数据给它聚合起来，做统一分析，才能发现其中内在的问题，但是传统的聚合方式对于监控系统可能并不一定能够让我们真正发现潜在问题所在，也可能被误导，我们监控在一个时间序列上采集了很多很多相关的数据，然后想知道平均的趋势大概有多大，以为我们的系统没有问题，但是事实上，很有可能出现异常值存储，只不过这个异常值被平均下来了，就类似人均收入一样，虽然说上海人均收入1万，但是依然有很多人哪些7千以下的工资；
    所以在聚合上，我们就应该有方差、标准差、中位数、百分位数等等等等，来进行做辅助分析，这样子才能更好的去揭示，我们对应的系统是否存在问题，如果没有这样的聚合分析的话，我们想去找到实际的问题所在可能是个不太实际的问题；
    所以聚合对于监控系统来讲是一个至关重要的操作，那也就意味着我们的数据存下来，不光要存历史数据，还要存趋势数据，所谓趋势数据就是经过聚合分析之后的数据，这个聚合分析就是在原来的数据样本之上，我们还有额外存储一些数据，存储的就是聚合分析的结果；

1.6、预警系统

    但即便如此，就算有一个很漂亮的展示接口，我们也需要用户看才能知道问题所在，如果我们正在家里休息，对应的服务突然大规模长时间的异常，所以对应的，我们还需要对周期性的监控下来的数据进行特定的判定；
    比如我们使用一个布尔表达式，来判定对应的监控指标，每个采样点的数据，是否超过来阈值，一旦进入异常阶段，当然，一进入异常就通知用户，也没有这个必要，因而，为了避免这种误报的可能性，报警系统应该有一个状态值；
    比如，当突然一个对应的指标本来是正常的，突然间出现异常了，超出阈值很多，那么这个时候，我们可能会认为系统可能出现故障了，但这个状态变化，叫做软状态，我们一般不应该第一时间就开始通知用户的；
    我们应该是等这个值，持续一段时间依然一直居高不下，一直超出阈值，那么这个时候，我们这个时候就应该将软状态变成硬状态，然后通知用户，而这种通知，我们通常叫做告警；
    说白了就是发生通知信息给用户，在Zabbix里面，它还设计了一些高级的玩法，比如这个告警信息，发送一个小时之后依然没能得到解决，那就升级发送，发送给领导，过了一个小时候还没解决就再升级，就发送给公司的领导了，因为它可能会认为这个影响面越来越大，级别越来越高，必须引起更多的人注意才行，我们称之为告警升级；

1.7、总结

一个良好的监控系统应该能提供以下内容：

• 全局视角，从最高层（业务）依次展开
• 协助故障诊断
• 作为基础设施、应用程序开发和业务人员的信息源

同样的它应该是：

• 内置于应用程序设计、开发和部署的生命周期中
• 尽可能自动化，并提供自服务

    大体上一个监控系统的主要组成部分主要有几个，第一，采集，被监控端要有监控代理/数据接口，监控代理\数据接口也罢，它也未必能够应用所有场景，所以也可能有所谓的探针监控还有黑盒监控；
    对于传统对网络设备来讲，比如要监控一个交换机，要监控交换机很难在交换机里面安装一个应用程序，它恐怕自己也未必能使用什么高级的方式向外暴露接口，而用的都是所谓的SNMP，简单网络管理协议，这是一个非常传统的，在七八十年代，让我们能够监控网络设备内部的工作状态的相关的接口，大多数网络设备都有，到今天来看，显得很粗陋，但是它也确实是这些网络上不可多得的接口，毕竟很多的网络是把更多的资源拿来去实现数据报文 处理的，而不应该拿来去做这些应用方面的操作，所以这个时候可能我们需要使用所谓的SNMP的这种机制去完成数据采集的，等等；

    第二，存储，我们的指标数据还需要存储，存储可能里面还需要一个分析引擎，可能还需要自带上一些很多聚合函数，甚至是一些趋势分析函数，做一些简单的线性回归分析，做一些预测等等，对于存储有的用SQL存，比较有代表性的，如Zabbix所使用的，MySQL，有的使用NoSQL存，而NoSQL当中比较流行的就是时序数据库，可以查看 db-engines.com ，查看主流数据库排名情况，其实Prometheus本身是一种时序存储和系统，只不过这个时序存储系统有一个数据抓取器；

    第三，展示，展示通常就是用非常直观的数据展示面板来帮我们展示像柱状图、雷达图、线状图，像Zabiix内建了有Zabbix的Web，像Prometheus内建了PromQL表达式，只不过它内建的图形非常的丑陋，因为市面上有专门的对接这种数据存储系统的展示工具，比如Grafana，它可以把Prometheus作为数据源来进行展示，它无非就是利用Prometheus内置的数据查询和分析接口，来查询、聚合之后来进行展示的，Grafana也可以把Zabbix作为它的数据源，其实Grafana支持的数据源有数十种之多；

    第四，告警，它无非就是把对应的指标数据的异常状态，而且是持续异常状态反馈给用户，就叫做告警，其实就是一种通知机制，所以我们需要有很多的媒介来进行通知，这里的媒介包括，能够触达到用户的联系方式都可以，比如邮箱、叮叮、微信、短信等等；