监控基础概念（一）

目录

前言

一、常用监控简介

1、cacti

2、Nagios

3、Zabbix

4、Prometheus

5、apen-Falcaon

二、监控系统背景和基础概念

1、监控系统"三代”

2、基础概念

3、TSDB、target、时序数据

4、运维监控平台设计思路

三、prometheus监控体系

1、监控体系

2、google提出的监控四个黄金指标

四、Prometheus简介

1、Prometheus特点

2、使用场景

3、prometheus时序数据

4、prometheus数据来源

5、prometheus抓取指标数据的三种途径

6、prometheus生态组件

五、prometheus架构图介绍

六、prometheus数据模型

1、键（指标）值、标签基本概念

2、prometheus每一份样本数据所包含的内容

3、指标（metric）类型

4、项目job和targets/实例instance

5、prometheusQL（数据查询语言也是时序数据库使用语言)

总结

---

前言

无监控，不运维。

一、常用监控简介

1、cacti

Cacti(英文含义为仙人掌〉是一套基于 PHP、MySQL、SNMP和 RRDtool开发的网络流量监测、及图形分析工具。

它通过snmpget来获取数据，使用RRDTool绘图，但使用者无须了解RRDTool复杂的参数。它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。

Cacti通过添加模板，使不同设备的监控添加具有可复用性，并且具备可自定义绘图的功能，具有强大的运算能力（数据的叠加功能)。

2、Nagios

Nagios是一款开源的免费网络监视工具，能有效监控windows、Linux和Unix的主机状态，交换机路由器等网络设备打印机等。在系统或服务状态异常时发出邮件或短信报警第一时间通知网站运维人员，在状态恢复后发出正常的邮件或短信通知。

nagios主要的特征是监控告警，最强大的就是告警功能，可支持多种告警方式，但缺点是没有强大的数据收集机制，并且数据出图也很简陋，当监控的主机越来越多时，添加主机也非常麻烦，配置文件都是基于文本配置的，不支持web方式管理和配置,这样很容易出错,不宜维护。

3、Zabbix

zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数，保证服务器系统的安全运营;并提供强大的通知机制，让系统运维人员快速定位/解决存在的各种问题。

zabbix由2部分构成：abbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix、agent、ping、端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux，Solaris，HP-UX，AIX,Free BSD , Open BSD,os x等平台上。

zabbix解决了cacti没有告警的不足，也解决了nagios不能通过web配置的缺点，同时还支持分布式部署，这使得它迅速流行起来，zabbix也成为目前中小企业监控最流行的运维监控平台。

◆◆◆zabbix中的一些监控方式：

①agent代理：专门的代理服务方式进行监控，专属的协议，装有zabbix-agent的主机就可以被zabix-server监控，主动或被动的方式，把数据给到server进行处理。

②ssh/telent：linux主机支持ssh/telent协议

③snmp：网络设备路由器、交换机不能安装第三方程序(agent），使用简单网络协议。大多数的路由器设备支持SNMP协议

④ipmi：通过ipmi接口进行监控，我们可以通过标准的ipmi硬件接口，监控被监控对象的物理特征，被广泛使用服务监控中，包括采集cpu温度，风扇转速，主板温度，及远程开关机情况等等。而且ipmi独立于硬件和操作系统，无论是cpu，bios还是os出现故障，都不会影响ipmi的工作，因为ipmi的硬件设备BMC( bashboard management controller）是独立的板卡，独立供电。

◆◆◆zabbix核心组件介绍：

①Server:Zabbix:软件实现监控的核心程序，主要功能是与zabbix proxies和Aents进行交互、触发器计算、发送告警通知;并将数据集中保存。与prometheus的类似可以保存收集到的数据，但是prometheus告警需要使用alter manager组件

②Database storage :存储配置信息以及收集到的数据

③web Interface:Zabbix的GUI接口，通常与server运行在同一台机器上

④Proxy:可选组件，常用于分布式监控环境中，一个帮助zabbix Server收集数据,分担zabbix Server的负载的程序

⑤Agent:部署在被监控主机上，负责收集数据发送给server

4、Prometheus

borgmon (伯格监控系统) 对应克隆的版本就是prometheus(go语言开发)。borg.kubernetes，k8s是borg衍生出来一个开源的一个资源管理器，所以prometheus 特别适合K8S 的架构上，作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提交和7200个拉取请求。

◆◆◆Prometheus和zabbix之间的区别：

zabbix它消耗的资源比较多，如果监控的主机非常多时（服务器数量超过500台)，可能会出现监控超时、告警超时、告警系统单点故障等现象，不过也有很多解决办法，比如提高硬件性能、改变zabbix监控模式等。

5、apen-Falcaon

apen-Falcaon是小米开源的企业级监控工具，用Go语言开发，包括小米、滴滴、美团等在内的互联网公司都在使用它，是一款灵活、可拓展并且高性能的监控方案。

二、监控系统背景和基础概念

1、监控系统"三代”

第一代：以监控网络设备、网络流量为主的时代，代表协议(SNMP，监控交换机、路由、网关、操作系统等)，以上的系统/设备需要内置对SNMP协议的支持。

SNMP:网络管理协议，在监控手段、技术的不断迭代的过程中，虽然可以使用、兼容SNMP协议，但很多技术都"抛弃"了内置对SNMP协议的兼容。

第二代（当今)：zabbix prometheus cacti nagios open-falcaon 等等。通常具备：数据采集、存储、告警+展示/可视化等基本功能。

第三代（大厂)：基于data驱动、ai驱动datavops aivops，(立体监控)

需要了解在立体监控系统支撑下对系统运行状态的分析、监控、反馈到系统展示；

业务运行过程中不稳定是常态、稳定(区间范围)是特殊的表现形式，大多数系统不是自治的，所以即使使用控制起来进行系统管理，但随着时间推移，依然无发保证持续性的自治。所以做为使用者而言，通过监控来了解系统的运行特性，来做对应的处理决策是相当重要的。监控细致化划分，会划分为事前监控、事中监控、事后监控。

例如：

设定:磁盘使用率来看(80%)

事前监控（运行状态，趋势分析)：当我门系统的磁盘负载从10%~30%呈现了一种并发式的增长速率，通过机器学习、监控预判、预测到未来2个小时-3个

小时期间，会直接飙到80%+ ，就会进行告警。

事后监控：固定死了80%，没超过80%不会告警，仅当超过时，才会告警。

2、基础概念

以监控系统的主体而言，使用/管理者所关注的被监控"系统”(端）的相关组件，例如路由器、交换机、网关、应用、基础设施服务、业务特征等，以上对象必须允许在基础设施层，例如物理主机、vm、container，那么我们就需要对这些基础设施层中关键的，伴随时间变化而变化的数据，进行采集分析，而此类数据称之为【指标】

①、指标数据采集到之后，作为"点状数据"，而此类点状数据称之为【样本数据】

②、而此类【样本数据】做为事后的分析(趋势分析)，如果我们所需要监控的目标特别多，那么我们就需要存储大量数据。

③、在持续存储性能表现上必须要【TSDB数据库】，那么接下来对此类样本数据进行分析，明确系统运行状态、特性，来预测、判断未来的某一时间、时刻是否会出现问题是我们的目的。

④、同时为了结果的可观测及清晰性，我们会做一些【可视化】处理分析功能，所以需要控制台（例如grafana)(目前的形式,可视化与低代码趋势) 过滤手段:PromOL（数据过滤语句)

⑤、我们也需要有一个守护进程，实时监测特定的样本序列、指标时间序列是否有异常状态,而通常此类异常状态的判断会以一种【布尔值表达式】的方式来做为判断依据即:需要基于数据分析后的条件判断，来判断是否是异常状态。

⑥、满足布尔值表达式的要求（true）的指标我们认为时异常指标，而此时我们就可以通过触发一种"媒介”(media)，把异常信息通知给用户，例如钉钉、webchat、短信、邮件等等此为

小结：指标数据采集—》样本数据存储—》可视化展示—》指标数据过滤—》异常指标判断—》告警通知——》用户

3、TSDB、target、时序数据

◆TSDB： pro通过采集的样本以时间序列的方式保存在内存（TSDB时序数据库）中并定时保存到硬盘（持久化)

◆target：主要指可输出、产生指标数据的组件/对象，包括但不限于主机、应用、服务、K8S ingress(逻辑组件)等。即能正常输出指标数据的对象称为target或网络端点（表现形式，例如:192.168.80.4:9100,192.168.80.4:8500)。

◆时序数据：一段时间内通过《重复》测量而获得的观测值的集合，并且可将这些观测值绘制与图形之上，以数据轴（纵轴〉和时间轴（横轴）来表示随着时间流逝而产生的"渐变"变化（类似与股票)。即能随着时间流逝，而能不断采集到的点数据称为时序数据，时序数据库不属于sql数据库也并不是nosql数据库。

即时间序列数据：按照事件推移，在某一个时间刻度，同一个样本数据采集的时间不会绝对的一致，会随机延迟或提前一点进行采集。

4、运维监控平台设计思路

监控的三个核心：数据收集模块、数据提取模块、监控告警模块。

可以细化为6层

第六层:用户展示管理层   同一用户管理、集中监控、集中维护

第五层:告警事件生成层   实时记录告警事件、形成分析图表（趋势分析、可视化)

第四层:告警规则配置层   告警规则设置、告警伐值设置（定义布尔值表达式，筛选异常状态）

第三层:数据提取层       定时采集数据到监控模块

第二层:数据展示层       数据生成曲线图展示（对时序数据的动态展示)

第一层:数据收集层       多渠道监控数据（网络，硬件，应用，数据，物理环境）

三、prometheus监控体系

1、监控体系

①系统层监控（需要监控的数据)

CPU、Load、Memory、swap、disk i/o、process等；

网络监控:网络设备、工作负载、网络延迟、丢包率等。

②中间件及基础设施类监控端监控（移动APP、特定程序等)

消息中间件:kafka、RocketMQ、等消息代理等；

WEB服务器容器:tomcat、php、weblogic等；

数据库/缓存数据库:MysQL、PostgresQL、MogoDB、es、redis等。

例如redis监控内容:

redis所在服务器的系统层、监控redis 服务状态、以及RDB AOF日志监控；日志—>如果是哨兵模式—>哨兵共享集群信息，产生的日志—>直接包含的其他节点哨兵信息及redis信息，此时redis作为中间件；还监控key的数量、key被命中的数据/次数，最大连接数（可以使用ulimit -a查看系统连接数；redis：redis-cli登陆数据库——config get maxclients  查看redis最大连接数）等。

③应用层监控

用于衡量应用程序代码状态和性能。

应用层监控分为黑盒监控和白盒监控( promtheus)。

白盒监控：自省指标，等待被下载。

黑盒指标：基于探针的监控方式，不会主动干预、影响数据。

④业务层监控

用于衡量应用程序的价值，如电商业务的销售量，ops、dau日活、转化率等，业务接口:登入数量，注册数、订单量、搜索量和支付量。

2、google提出的监控四个黄金指标

①延迟：服务请求时长；区分失败与成功的请求 code !="200"请求失败的数据。

②流量：应用服务容量需求，如每秒处理HTTP请求或数据库系统的事务数量。

③错误：请求失败的速率、衡量错误发送的情况。例如:HTTP 500。

④饱和度：资源使用情况、负载情况。例如5大负载等资源。

四、Prometheus简介

谷歌的内部大型集群系统borg，是kubernetes的前身。其监控系统是borgmon，而prometheus是其克隆版，所以非常契合k8s的监控对容器非常适用。Prometheus本身为一种时序数据库(TSDB)，还是开源的监控、报警、时间序列、数据库的组合。他是设计用于进行目标(target）监控的关键组件。

官网: https://prometheus.io/docs/concepts/data_model/

1、Prometheus特点

①自定义多维数据模型（时序列数据由metric名和一组key/value标签组成)；

②非常高效的储存，平均一个采样数据占大约3.5.bytes左右，320万的时间序列，每30秒采样，默认保持60天，消耗磁盘大概228G；

③在多维上灵活且强大的查询语句和聚合语言( PromQL)；

④提供本地存储、不依赖分布式储存，支持单主节点工作；

⑤通过基于HTTP的pull方式采集时序数据；

⑥可以通过push gateway进行时序列数据库推送(pushing）；

⑦可以通过服务发现或静态配置去获取要采集的目标服务器（server discover）；

⑧多种可视化图表及仪表盘支持。

2、使用场景

◆◆◆适用场景

Prometheus可以很好地记录任何纯数字时间序列。它既适用于以机器为中心的监视，也适用于高度动态的面向服务体系结构的监视。在微服务世界中，它对多维数据收集和查询的支持有特别的优势(云原生，k8s)。

Prometheus是为可靠性而设计的，它是您在中断期间要使用的系统，可让您快速诊断问题。每个Pronetheus服务器都是独立的，而不依赖于网络存储或其他远程服务。当基础结构的其他部分损坏时，您可以依靠它，并且无需设置广泛的基础结构即可使用它。

◆◆◆不适合的场景

普罗米修斯重视可靠性。即使在故障情况下，您始终可以查看有关系统的可用统计信息。如果您需要100%的准确性（例如按请求计费)，则Prometheus并不是一个不错的选择，因为所收集的数据可能不会足够详细和完整。在这种情况下，最好使用其他系统来收集和分析数据以进行计费，并使用Prometheus进行其余的监视。

3、prometheus时序数据

时序数据，是在一段时间内通过重复测量(measurement）而获得的观测值的集合将这些观测值绘制于图形之上，它会有一个数据轴和一个时间轴，服务器指标数据、应用程序性能监控数据、网络数据等也都是时序数据。

4、prometheus数据来源

prometheus基于HTTP call (http/https请求），从配置文件中指定的网络端点(endpoint/IP:端口)上周期性获取指标数据。

很多环境、被监控对象，本身是没有直接响应/处理http请求的功能，promethens-exporter则可以在被监控端收集所需的数据，收集过来之后，还会做标准化，把这些数据转化为prometheus可识别，可使用的数据（兼容格式)

5、prometheus抓取指标数据的三种途径

prometheus采用白盒监控，支持通过三种途径从目标抓取(scrape）指标数据，以下为pro典型的采集数据的方式：

①、exporters：指标暴露器，（当服务不支持pro格式，借助于exporter来响应给prometheus，工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送)。

②、instumentation：测量系统(被监控端)，指的是应用程序内置本身兼容pro采集格式的指标暴露器。指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取。

③、push gateway：短期、批处理任务，本身此类业务不会产生指标数据，同时难于使用exporter来获取指标数据的任务；push gateway 将以push的方式将短期的业务指标数据，收集到网关处，然后定期crontab推送给pro-server。

注意：Prometheus获取方式，同其它TSDB相比有一个非常典型的特性：它主动从各Target上拉取(pull)数据，而非等待被监控端的推送(push)。

两个获取方式各有优劣，其中，Pull模型的优势在于：集中控制，有利于将配置集在Prometheus server上完成，包括指标及采取速率等;

Prometheus的根本目标在于在target上预先完成聚合的聚合型数据的收集，而非一款由事件驱动的存储系统通过targets(标识的是具体的被监控端)。比如配置文件中的targets : [ ‘localhost:9090’]。

6、prometheus生态组件

prometheus生态圈中包含了多个组件，其中部分组件可选

①Prometheus server：服务端，收集和储存时间序列数据。通过scraping以刮擦的方式去获取数据放入storge (TSDB时序数据库），制定Rules/Alerts:告警规则，service discovery是自动发现需要监控的节点。

②client Library：客户端库，目的在于为那些期望原生提供Instrumentation功能的应用程序提供便捷的开发途径;

③Push Gateway：接收那些通常由短期作业生成的指标数据的网关，并支持由Prometheus Server进行指标拉取操作;

④Exporters：指标暴露器。用于暴露现有应用程序或服务（不支持Instrumentation)的指标给Prometheus Server）。

⑤Alertmanager：由告警规则对接，从Prometheus Server接收到"告警通知"后，通过去重、分组、路由等预处理功能后以高效向用户完成告警信息发送。

⑥Data Visualization (Dashboards)：与TSDB对接并且展示数据库中的数据，Prometheus web UI (Prometheusserver内建)，及Grafana等。

⑦service Discovery：动态发现待监控的Target，从而完成监控配置的重要组件，在容器化环境中尤为有用;该组件目前由PropetheusServer内建支持。

⑧Prometheus scrape：数据采集器

◆◆◆注：Exporters、alerts、Prometheus server介绍

⑴、Exporters介绍

node-exporter组件，因为prometheus抓取数据是通过http的方式调用的，假如抓取的数据是操作系统的资源负载情况，而linux操作系统内核是没有内置任何http协议的，并不支持直接通过http方式进行，所以需要在每个被监控端安装node-exporter，由其向内核中拿取各种状态信息，然后再通过prometheus兼容的指标格式暴露给prometheus

对于那些未内建Instrumentation，且也不便于自行添加该类组件以暴露指标数据的应用程序来说，常用的办法是于待监控的目标应用程序外部运行一个独立指标暴露程序，该类型的程序即统称为Exporter。

PS:Prometheus站点上提供了大量的Exporter，如果是docker技术跑多个服务就要使用docker-exportes监控系统环境，而idocker容器内部服务的监控需要使用cAdvisor容器

⑵、alerts（告警）介绍

抓取异常值，异常值并不是说服务器的报警只是根据用户自定义的规则标准，prometheus通过告警机制发现和发送警示。

alter负责:告警只是prometheus基于用户提供的"告警规则"周期计算生成，好的监控可以事先预告报警、并提前处理的功能alter接受服务端发送来的告警指示，基于用户定义的告警路由（route)向告警接收人（receivers）发送告警信息（可由用户定义)

ps:在数据查询，告警规则里面会使用到promQL语句

⑶、prometheus server

内建了数据样本采集器，可以通过配置文件定义，告诉Prometheus到哪个监控对象中采集指标数据，prometheus采集过后，会存储在自己内建的TSDB数据库中，提供了promQL，支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alter来发送报警信息，还支持对接外置的ui工具(grafana)来展示数据，prometheus自带的web展示图像信息比较简单。

采集、抓取数据是其自身的功能。但一般来自于export/instrumentation

(指标数据的暴露)来完成，或者是服务自身的，内建的测量系统来完成。

从每个target中会采集出很多指标，那么每个指标会暴露很多样本数据点，而这些数据点pro都需要存储而这些指标会以固定时间间隔生成很多样本数据点，而如何标示这些样本数据点，则是数据模型学习的意义

五、prometheus架构图介绍

①prometheus-server

retrieval(获取数据pull/discover） ，TSDB存储，HTPserver

控制台接口，内建了数据样本采集器，可以通过配置文件定义，告诉prometheus到那个监控对象中采集指标数据，prometheus采集过后，会存储在自己内建的TSDB数据库中(默认为2个月时间))，提供了prompL支持查询和过滤操作，同时支持自定义规则来作为告警规则，持续分析一场指标，一旦发生，通知给alerter来发送告警信息，还支持对接外置的UI工具(grafana）来展示数据

②pushgateway (短期周期任务)

允许短暂和批量作业将其指标暴露给普罗米修斯，由于这些类型的作业可能存在时间不足而被删除，因此他们可以将其指标推送到pushgateway，然后pushgateway将这些指标暴露给Prometheus-server端，主要用于业务数据汇报

③exporters (常规任务—守护进程)

专门采集一些web服务，nginx，mysgl服务。因为不适合直接通过nttp的方式采集数据，所以需要通过exporter采集数据（下载mysqgl_exporter，采集mysql数据指标）cadvisor: docker数据收集工具(docker也有自己内置的监控收集方式)

exporter和instrumtations，负责专门服务数据的收集然后暴露出来等待promtheus收集

④service discovery:原生支持k8s的服务发现，支持consul、DNs等

⑤prometheus内置TSDB数据库作为存储（时序数据的储存，promtheus的TsDB数据库默认保存15天，可以自行调整)

ps:时间序列数据库（时序数据库）主要用于指处理代表签（按照时间的顺序变化，既时间序列化）的数据，带时间标签的数据也成为时间序列数据，这是一种特殊类型的数据库，一般不会保存长时间的数据（与mysql相比）。

数据保存时间storge.tsdb.retention=90d参数中修改即可（或启动时间指定)

⑥alertmanagr: prometheus可以生成告警信息，但是不能直接提供告警，需要使用一个外置的组件altermanager来进行告警，emailetctif优势在于，收敛、支持静默、去重、可以防止告警信息的轰炸

⑦data visualization: prometheus web ui (prometheus-server内建，表达式浏览器），也可以使用grafana

⑧PrmoQL (告警规则编写)，通常告警规则的文件指定输出到展示界面（grafana

⑨ui表达式浏览器（调试)

六、prometheus数据模型

1、键（指标）值、标签基本概念

prometheus仅用键值方式存储时序式的聚合数据，他不支持文本信息。

其中的"键"称为指标(metric)，通常意味着cpu速率、内存使用率或分区空闲比例等。同一指标可能适配到多个目标或设备、因而它使用“标签”作为元数据，从而为metric添加更多的信息描述维度。标签作用：用于区分相互有关联，或者相似的一组资源，(可根据标签定义我们需要管理或筛选的一个集合)。

比如：三个node节点都会有相同的指标（例如：cpu0的负载，那么其就会使用相同的指标名称)，所以我们可以使用“指标:标签=标签值”的格式来表示不同节点的时序数据。

例如: cpu_total {host=node1, host=node2}

metric ( cpu指标):

示例:

cpu_usage { core='1', ip='192.168.226.128:9100' } 14.04

key(指标)                 标签( lables)            样本数据（一个folat64 的浮点型数据表示当前样本的值)

{ core='1', ip='192.168.226.128'}：又称为标签过滤器/标签选择器

2、prometheus每一份样本数据所包含的内容

①时序列标识:key+lables

②当前时间序列的样本值value

③过滤数据样本的时间戳

④这些标签可以作为过滤器进行指标过滤及聚合运算，如何从上万的数据中过滤出关键有限的时间序列，那就需要手动编写出时间序列的样本表达式(PromQL）来过滤出我们需求的样本数据。

3、指标（metric）类型

默认都是以双精度浮点型数据，即服务端无数据量类型数据（类型是对客户端有意义的，从客户需求相关）。

①counter : 计数器单调递增

②gauge：仪表盘，有起伏特征的

③histogram：直方图（统计的概念，做分位数统计）

在一段时间范围内对数据采样的相关结果，并记入配置的bucket中，他可以存储更多的数据，包括样本值分布在每个bucket的数量，从而prometheus就可以使用内置函数进行计算:

计算样本平均值：以值得综合除以值的数量；

计算样本分位值：分位数有助于了解符合特定标准的数据个数，例如评估响应时间超过1秒的请求比例，若超过20%则进行告警等。

④summary（摘要、概要）：直方图（histogram）的扩展类型，它是直接由监控端自行聚合计算出分位数，同时将计算结果响应给prometheus server的样本采集请求，因而，其分位数计算是由监控端完成

4、项目job和targets/实例instance

①job：能够接收prometheus server数据scrape

②targets在这里指监控的目标对象，每一个可以被监控的系统，成为targets多个相同的targets的集合（类）称为job。target :标识的是一个URL:端点。

③instance实例与targetst相比，instance更趋近于一个具体可以提供监控数据的实例，而targets则更像一个对象、目标性质

5、prometheusQL（数据查询语言也是时序数据库使用语言)

支持两种向量，同时内置提供了一组用于数据处理的函数，来对样本数据进行基础的分析(Ai算法、机器学习、深度学习来分析、预测系统之后的运行走势)

①即时向量:最近以此时间戳上跟踪的数据指标（一个时间点上的所有数据)

即时向量选择器:返回0个1个或者多个时间序列上在给定时间戳上的各自的一个样本，该样本成为即时样本

②时间范围向量:指定时间范围内所有时间戳上的数据指标

范围向量选择器:返回0个1个或多个时间序列上在给定时间范围内的各自的一组样本(范围向量选择器无法用于绘图)

总结

Prometheus工作流程

第一步、通过三种抓取方式（exporter指标暴露器、instrumatation应用内置的指标暴露器、pushgatway短期任务/脚本数据方式）

第二步、采集到后，保存到内存中，在保存到TSDB-Prometheus数据库中

第三步、在通过内存，读取到展示到自带的ui表达式浏览器中

第四步、也是通过内存、产生的告警信息，通过promQL和布尔表达式，通过告警组件alertmanager，产生告路由，进行告警路由分组，发送通知（qq、微信、钉钉等，通过官网复制代码放到数据配置文件中就可）

第五步、通过kibana、grafana等展示工具展示出来

第六步、服务器通过服务发现的功能，自动增加和减少监控内容（基于文件、基于DNS、基于容器、基于consul注册机）