Prometheus监控+(动静)连接节点(故事的结局总是这样，花开两朵，天各一方。)

一、常用监控简介

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

它通过snmpget来获取数据，使用RRD"ocl绘图，但使用者无须了解RDPocl复杂的参数。它提供了非常强大的数据和用户管理功能，可以指定每一个用户能查看树状结构、主机设备以及任何一张图，还可以与LDAP

结合进行用户认证，同时也能自定义模板，在历史数据的展示监控方面，其功能相当不错。Cacti

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

2、Nagios

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

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

3、Zabbix

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

zabbix由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix

agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux， Solaris，H-UX，AIX，Free BSD,OpenBSD,os x等平台上。

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

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

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

ssh/telent: linux主机支持ssh/telent协议

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

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

zabbix核心组件介绍

zabbix

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

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

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

Proxy:可选组件，常用于分布式监控环境中，一个帮助zabbix Server收集数据，分担zabbix Server的负载的程序Agent:部署在被监控主机上，负责收集数据发送给server

4、PrometheusIborg. kubernetes

borgmon(监控系统)对应克隆的版本:prometheus(go语言)所以prometheus特别适合K8S 的架构上

而作为一个数据监控解决方案，它由一个大型社区支持，有来自700多家公司的6300个贡献者，13500个代码提交和7200个拉取请求

Prometheus具有以下特性:

1.多维的数据模型(基于时间序列的Key、 value键值对)

2.灵活的查询和聚合语言PromQL

3.提供本地存储和分布式存储

4.通过基于HTTP和HTTPs的Pull模型采集时间序列数据（pull数据的推送，时间序列:每段时间点的数据值指标，持续性的产生。横轴标识时间，纵轴为数据值，一段时间内数值的动态变化，所有的点连线形成大盘式的折线图)

5.可利用Pushgateway (Prometheus的可选中间件）实现Push模式

6.可通过动态服务发现或静态配置发现目标机器（通过consul自动发现和收缩)支持多种图表和数据大盘

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

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

1.数据收集模块

2.数据提取模块(prometheus-TSDB 查询语言是PromQL)

3.监控告警模块―（布尔值表达式判断是否需要告警Promg (cPu使用率)>80%)

町以细化为6层

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

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

第四层:告警规则配置层告警规则设置、告警伐值设置

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

第二层:数据展示层―数据生成曲线图展示（对时序数据的动态展示)第一层:数据收集层多渠道监控数据

三、prometheus监控体系(一)监控体系:

系统层监控(需要监控的数据)

1.cPU、Load、Memory、swap、disk i/o、process等

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

中间件及基础设施类监控

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

2.wEB服务器容器: tomcat

3.数据库/缓存数据库:MySQI、PostgresQL、MogoDB、es、 redisredis监控内容:

redis所在服务器的系统层监控redis 服务状态

RDB AOF日志监控

日志—>如果是哨兵模式—>哨兵共享集群信息，产生的日志—>直接包含的其他节点哨兵信息及redis信息

key的数量

key被命中的数据/次数

最大连接数——》redis 和系统:系统: ulimit -a

redis:redis-cli登陆—》config get maxclients查看最大连接

应用层监控

用于衡量应用程序代码状态和性能#监控的分类#:黑盒监控,白盒监控PS:

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

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

业务层监控

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

四、prometheus使用场景

1.Prometheus特点:

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

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

在多维上灵活且强大的查询语句（ PromQL)

不依赖分布式储存，支持单主节点工作通过基于HTTP的pull方式采集时序数据

可以通过push gateway进行时序列数据库推送(pushing>可以通过服务发现或静态配置去获取要采集的目标服务器多种可视化图表及仪表盘支持

2.使用场景

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

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

3.不适合的场景

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

五、prometheus时序数据

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

1.数据来源:

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

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

2.收集数据:

监控概念:白盒监控、黑盒监控

白盒监控:自省方式，被监控端内部，可以自己生成指标，只要等待监控系统来采集时提供出去即可

黑盒监控:对于被监控系统没有侵入性，对其没有直接"影响"，这种类似于基于探针机制进行监控（snmp协议)

Prometheus支持通过三种类型的途径从目标上"抓取（Scrape)"指标数据（基于白盒监控);

Exporters—>工作在被监控端，周期性的抓取数据并转换为pro兼容格式等待prometheus来收集，自己并不推送

Instrumentation—>指被监控对象内部自身有数据收集、监控的功能，只需要prometheus直接去获取

Pushgateway ——>短周期5s—10s的数据收集

3.prometheus(获取方式)

Prometheus同其它rsDB相比有一个非常典型的特性:它主动从各Target.上拉取(pull)数据，而非等待被监控端的推送(push)

两个获取方式各有优劣，其中，Pull模型的优势在于:

集中控制:有利于将配置集在Prometheus server上完成，包括指标及采取速率等;

Prometheus的根本目标在于收集在rarget上预先完成聚合的聚合型数据，而非一款由事件驱动的存储系统通过targets (标识的是具体的被监控端)

比如配置文件中的targets: [ 'localhost : 9090']

exporter收集了200行数括cpu使用率{ code='cpu0'}cpu使用率{ code='cpul'}cpu使用率{ code='cpu2' }#####

schme { "http" }

HOST { "192.168.226.128"}Port { "9100"}

PATH{ " / usr / local/ nginx/"}

需求是输出完整的URL

_sdhme_host_port_path { "http://192.168.226.128:9100/usr/local/nginx" }

六、prometheus生态组件

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

1.prometheus-server:

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

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

2.pushgateway (短期周期任务)

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

3.exporters (常规任务-守护进程)

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

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

4.service discovery:原生支持k8s的服务发现，支持consul、DNS等

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

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

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

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

7.data visualization: prometheus web ui (prometheus-server内建），也可以便用grafana

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

9.ui表达式浏览器（调试)

 

七、安装prometheus

第一步准备

 

第二步解压

 

第三步进入目录，执行脚本

 

第四步查看端口

 

第五步浏览器登入

 

第六步查看状态

 

第七步查看内置数据

 

 

八、prometheus数据模型（什么是标签、什么是指标、什么是样本)-概述

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

其中的""键"成为指标(metric)，通常意味着cpu速率、内存使用率或分区空闲比例等

向一指标可能适配到多个目标或设备、因而它使用"标签"作为元数据，从而为metric添加更多的信息描述维度例如三台设备，在同一时刻，都会产生例如1分组cPu负载的数据，他们都公使用相同的指标(metric)，而此时一个指标，如何表示时间序列?

比如:三个node节点都公有相同的指标（例如cpu0的负载那么就公使用相同的指标名称)

使用指标:标签=标签值的格式来表乐，例如: local1 (host=node1, host=node2 )

metric icpu指标):

示例:

cpu_usage{ core-" 1 ',ip-"192.168.226.128" 14.04

key cpu0 labels （元数据） 样本

1

2

prometheus每一份样本数据都包含了:

时序列标识:key+lables

当前时间序列的样本值value这些标签可以作为过滤器进行指标过滤及聚合运算，如何从上万的数据过滤出关键有限的时间序列，同时从有限的时间序列在特定范围的样本那就需要手动编写出时间序列的样本表达式来过滤出我们需求的样本数据

(一）指标类型

默认都是以双精度浮点型数据（服务端无数据量类型数据)

counter :计数器单调递增

gauge :仪表盘:有起伏特征的histogram:直方图:

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

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

计算样本分位值:分位数有助于了解符合特定标准的数据个数，例如评估响应时间超过1秒的请求比例，若超过20%则进行告警等 summary，摘要，histogram的扩展类型，它是直接由监控端自行聚合计算出分位数，同时

将计算结果响应给prometheus server的样本采集请求，因而，其分位数计算是由监控端完成

(二）作业job和实例targets/instance

job:能够接收prometheus server数据scrape

targets每一个可以被监控的系统，成为targets多个相同的targets的集合（类）称为jobinstance:实例与targets （类似)

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

(三) prometheusQL（数据查询语言也是时序数据库使用语言)支持两种向量，同时内置提供了一组用于数据处理的函数

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

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

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

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

 

九、prometheus连接节点小实验

(一）准备工作

关闭防火墙及安全机制，修改主机名

hostnamectl set-hostname prometheus

#其他主机分别设置server1.2.3

systemctl stop firewalld

systemctl disable firewalld

setenforce 0

vim /etc/selinux /config

SELINUX=disabled

vim /etc/reslove.conf

nameserver 114.114.114.114

#时间同步

ntpdate ntp1.aliyun . com

第一步准备（加时间同步）

第二步解压

第三步执行

第四步去浏览器查看

第五步工作节点部署

 

第六步执行

 

第七步加入节点，再次执行

 

 

第八步查看界面是否添加节点

 

表达式浏览器常规使用

在prometheusUI控制台上可以进行数据过滤####简单的用法:

#CPU使用总量

node cpu_seconds_total r#进阶1:

计算过去5分钟内的cPU使用速率

PromQL: irate (node_cpu_seconds_total {mode="idle" } [ 5m])解析:

irate:速率计算数(灵敏度非常高的)

node_cpu_seconds_total:node节点cPU使用总量mode="idle"空闲指标

5m:过去的5分钟内，所有cPU空闲数的样本值，每个数值做速率运算#进阶2:

每台主机CPU在5分组内的平均使用率

PromQL: (1- avg (irate (node_cpu_seconds_total{mode='idle' } [5m] ) ) by (instance) )* 100

解析avg :平均值

avg (irate (node_cpu_seconds total{mode='idle' } [5m] ):可以理解为cPt空闲量的百分比by (instance):表示的是所有节点

(1- avg (irate (node_cpu_seconds_total{mode='idle' } [5m] ) ) by (instance))* 100:CPI

5分钟内的平均使用率

其他常用的指标:

1、查询1分钟平均负载超过主机cPu数量两倍的时间序列

node_load1 > on (instance) 2 * count (node_cpu_seconds_total{mode=' idle' }) by(instance)

2、内存使用率

node_ memory_MemTotal_bytes

node_ memory_MemFree_bytes

node_memory_Buffers _bytes

node memory_cached_bytes

计算使用率:

可用空间:以上后三个指标之和

己用空间:总空间减去可用空间

使用率:己用空间除以总空间

十、部署service discovery服务发现(一)相关概念

1、Prometheus指标抓取的生命周期

发现->配置-> relabel(配置定义/服务自身执行）->指标数据抓取->metrics relabel(自定义)Prometheus的服务发现

#默认: static_config :静态配置形式的服务发现

基于文件的服务'发现;

基于DNS的服务发现;

基于API的服务发现:Kubernetes、Consul、Azure、重新标记target重新打标

metric重新打标基于K8S的服务发现

2、prometheus 服务发现机制

Prometheus server的数据抓取工作于Pull模型，因而，它必需要事先知道各Target的位置，然后才能从相应的Exporter或Instrumentation中抓取数据

对于小型的系统环境来说，通过static_configs指定各Target便能解决问题，这也是最简单的配置方法;每个Targets用一个网络端点(ip:port）进行标识;

对于中大型的系统环境或具有较强动态性的云计算环境来说，静态配置显然难以适用;

因此，Prometheus为此专门设计了一组服务发现机制，以便于能够基于服务注册中心（服务总线）自动发现、检测、分类可被监控的各rarget，以更新发生了变动的Target指标抓取的生命周期

在每个scrape_interval期间，Prometheus都会检查执行的作业(Job) ;这些作业首先会根据Job上指定的发现配置生成target列表，此即服务发现过程;服务发现会返回一个Target列表

其中包含一组称为元数据的标签，这些标签都以"meta_"为前缀;

2、prometheus 服务发现制（小加分项)

1.Prometheus Server的数据抓取工作于Pull模型，因而，它必需要事先知道各Targets

的位置，然后才能从相应的Exporter或Instrumentation中抓取数据

2.对于小型的系统环境来说，通过static_configs指定各Target便能解决问题，这也是最简单的配置方法;每个Targets用一个网络端点(ip:port）进行标识;

3.对于中大型的系统环境或具有较强动态性的云计算环境来说，静态配置显然难以适用;

因此，Prometheus为此专门设计了一组服务发现机制，以便于能够基于服务注册中心（服务总线）自动发现、检测、分类可被监控的备rarget，以及更新发生了变动的Target指标抓取的生命周期

4.在每个scrape_interval期间，Prometheus都会检查执行的作业(Job) ;这些作业首先会根据

Job上指定的发现配置生成target列表，此即服务发现过程;服务发现会返回一个Target列表，其中包含一组称为元数据的标签，这些标签都以*meta_"为前缀;

5.服务发现还会根据目标配置来设置其它标签，这些标签带有""前缀和后缀，b包括"scheme"、 "address"和" metrics path_"，分别保存有target支持使用协议(http或https，默认为http) 、 target的地址及指标的URI路径（默认为/metrics) ;

6.若URI路径中存在任何参数，则它们的前缀会设置为" param"这些目标列表和标签会返回给Prometheus，其中的一些标签也可以配置中被覆盖;

配置标签会在抓取的生命周期中被重复利用以生成其他标签，例如，指标上的instance标签的默认值就来自于address标签的值;

7.对于发现的各目标，Prometheus提供了可以重新标记（relabel)目标的机会，它定义在job配置段的relabel_config配置中，常用于实现如下功能

以上.的7条—》详细版的prometheus 工作的生命周期

###将来自服务发现的元数据标签中的信息附加到指标的标签上

###过滤目标

动态发现

①基于文件服务发现

192.168.153.10

基于文件的服务发现仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式。prometheus server定期从文件中加载target信息(pro-server pull指标发现机制-job_name

获取我要pull的对象target)文件可以只用json和yaml格式，它含有定义的target列表，以及可选的标签信息，以下第一配置，能够将prometheus默认的静态配置转换为基于文件的服务发现时所需的配置;（rometheus会周期性的读取、重载此文件中的配置，从而达到动态发现、更新的操作)

[root@prometheus files_sd]# cat prometheus.yml

# my global config

# Author: MageEdu <mage@magedu.com>

# Repo: http://gitlab.magedu.com/MageEdu/prometheus-configs/

global:

scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.

evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.

# scrape_timeout is set to the global default (10s).

 

# Alertmanager configuration

alerting:

alertmanagers:

- static_configs:

- targets:

# - alertmanager:9093

 

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.

rule_files:

# - "first_rules.yml"

# - "second_rules.yml"

 

# A scrape configuration containing exactly one endpoint to scrape:

# Here it's Prometheus itself.

scrape_configs:

# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.

- job_name: 'prometheus'

 

# metrics_path defaults to '/metrics'

# scheme defaults to 'http'.

 

file_sd_configs:

- files:

- targets/prometheus_*.yaml

refresh_interval: 2m

 

# All nodes

- job_name: 'nodes'

file_sd_configs:

- files:

- targets/nodes_*.yaml

refresh_interval: 2m

 

[root@prometheus targets]# cat nodes_centos.yaml

- targets:

- 192.168.153.20:9100

- 192.168.153.30:9100

labels:

app: node-exporter

job: node

[root@prometheus targets]# cat prometheus_server.yaml

- targets:

- 192.168.153.10:9090

labels:

app: prometheus

job: prometheus

指定yml文件启动

 

[root@prometheus prometheus-2.27.1.linux-amd64]# ./prometheus --config.file=./files_sd/prometheus.yml

总结

1.指标类型

计数器：单调递增

仪表盘：起伏特征

直方图：平均数或分位值

sumamary(统计数据)

2.作业job和实例targets/instance

①job：能够接收prometheus server数据scrape ；两种job：“mysql_nodes" “mysql_master_slave”，每一种job会分开进行拉取数据以及展示数据

②指标（配置文件/promql) : targets 与 instance区别：都代表了被监控端可以吐出监控数据的被监控端这个对象，tagers偏向于表示一个集合，instance偏向于表示具体的一个可提供监控数据的对象

PromQL : 指标 {标签1=标签值1，......标签N=标签值N} 样本（值）

3.prometheusQL两种向量

①即时向量：表示的是一个时间刻度

②时间范围向量：表示的是一组时间区间

③即时向量选择器：在指定的时间戳上的数值（称之为即时向量样本）

④范围向量选择器：在一组时间区间内的0或1或多个数值（范围向量样本）

支持多种即时向量组合形式，不支持多种时间范围向量组合形式

4.prometheus的配置文件

①global：全局配置 ②altermanager ：告警模块 ③rules ④scrape（服务发现）

5.prometheus架构模型（工作流程）

scrape收集数据方式：①exporter ②自建/内建指标 ③pushgateway

服务发现：①基于fd文件 ②基于DNS——>SRV记录 ③基于consul——>自动发现，同时利用prometheus的自身周期扫描配置文件更新项并加载的特性，实现动态更新 ④基于k8s服务发现