[系统运维]docker （九）promethues的服务发现和grafana

一、部署service discovery服务发现

（一）相关概念

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

发现->配置-> relabel（重打标签） -> 指标数据抓取 -> metrics relabel
			 隐藏敏感数据		 静态/动态发现方式		整合多个标签，来进行单个自定义指标数据的输出

Prometheus的服务发现（基于文件、DNS、consul、k8s等各种主流的服务发现总线）

默认的 static_config，动态获取target（监控端url）

① 基于文件的服务发现;
（定义一组资源“子”配置文件yaml格式 里面只存方需要采集的targets 信息，此种方式可以被pro动态获取到，而不需要重启）
② 基于DNS的服务发现;（SRV形式）
③ 基于API的服务发现:Kubernetes、Consul、Azure、重新标记
target重新打标
metric重新打标
④ 基于K8S的服务发现

2、prometheus 服务发现机制

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

② 对于小型的系统环境来说，通过static_configs指定各Target便能解决问题，这也是最简单的配置方法;每个Targets用一个网络端点(ip:port）进行标识;
③ 对于中大型的系统环境或具有较强动态性的云计算环境来说，静态配置显然难以适用;
因此，Prometheus为此专门设计了一组服务发现机制，以便于能够基于服务注册中心（服务总线）自动发现、检测、分类可被监控的各Target，以及更新发生了变动的Target指标抓取的生命周期
③ 在每个scrape_interval期间，Prometheus都会检查执行的作业(Job);这些作业首先会根据
Job上指定的发现配置生成target列表，此即服务发现过程;服务发现会返回一个Target列表，其中包含一组称为元数据的标签，这些标签都以" meta_"为前缀;

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

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

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

⑦ 对于发现的各目标，Prometheus提供了可以重新标记（relabel）目标的机会，它定义在job配置段的relabel_config配置中，常用于实现如下功能：
将来自服务发现的元数据标签中的信息附加到指标的标签上
过滤目标：
#之后便是数据抓取，以及指标返回的过程，抓取而来的指标在保存之前，还允许用户对指标重新打标过滤的方式
#它定义在job配置段的metric_relabel_configs配置中，常用于实现如下功能#册删除不必要的指标
#从指标中册删除敏感或者不需要的标签
#添加、编辑或者修改指标的标签值或标签格式

（二）静态配置发现

#修改prometheus服务器上的配置为文件，指定targets的端口，上篇文章配置过

- job_name: 'nodes'
  static_config:
  - targets:
    -192.168.100.22:9100
    -192.168.100.5:9100
    -192.168.100.6:9100

（三）动态发现

1.基于文件服务发现

192.168.100.21
基于文件的服务发现仅仅略优于静态配置的服务发现方式，它不依赖于任何平台或第三方服务，因而也是最为简单和通用的实现方式。
prometheus server定期从文件中加载target信息（pro-server pull指标发现机制-job_name 获取我要pull的对象target）文件可以只用json和yaml格式，它含有定义的target列表，以及可选的标签信息；以下第一配置，能够将prometheus默认的静态配置转换为基于文件的服务发现时所需的配置；（prometheus会周期性的读取、重载此文件中的配置，从而达到动态发现、更新的操作）

1）配置三个文件

在promethues端点

[root@prometheus ~]# cd /usr/local/prometheus-2.27.1/
[root@prometheus prometheus-2.27.1]# ls
console_libraries  data      LICENSE  prometheus      promtool
consoles           NOTICE   prometheus.yml
[root@prometheus prometheus-2.27.1]#
[root@prometheus prometheus-2.27.1]# mkdir ./file_sd
[root@prometheus prometheus-2.27.1]# ls
console_libraries  data      LICENSE  prometheus      promtool
consoles           file_sd  NOTICE   prometheus.yml
[root@prometheus prometheus-2.27.1]# cd file_sd/
[root@prometheus fils_sd]# vim 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 file_sd]# mkdir targets
[root@prometheus file_sd]# cd targets/
[root@prometheus targets]# cat node_centos.yaml     #设置上个promethues.yml中node_centos.yaml
- targets:
  - 192.168.100.22:9100
  - 192.168.100.5:9100
  - 192.168.100.6:9100
  labels:
    app: node-exporter
    job: node

[root@prometheus targets]# cat prometheus_server.yaml      #设置上个promethues.yuml中prometheus_server.yml文件
- targets:
  - 192.168.100.21:9090
  labels:
    app: prometheus
    job:  prometheus

[root@prometheus targets]# cd /usr/local/prometheus-2.27.1/file_sd/
[root@prometheus file_sd]# ls
prometheus.yml  targets
[root@prometheus file_sd]# tree .
.
├── prometheus.yml
└── targets
    ├── nodes_centos.yaml
    └── prometheus_server.yaml

1 directory, 3 files

2）关闭原有服务，再指定配置文件启动

promethues端：
killall -9 promethues

三个node节点：
killall -9 node_exporter

prometheus端点上
[root@prometheus file_sd]# cd /usr/local/prometheus-2.27.1
[root@prometheus file_sd]#./prometheus --config.file=./file_sd/prometheus.yml

node节点上
[root@node1 ~]# cd node_exporter-1.1.2.linux-amd64/
[root@node1 node_exporter-1.1.2.linux-amd64]# ls
LICENSE  node_exporter  NOTICE
[root@node1 node_exporter-1.1.2.linux-amd64]# ./node_exporter

注意在node节点开启服务

cd node_exporter-1.1.2.linux-amd64/
./node_exporter

注意：
killall prometheus
netstat -nautp | grep prometheus

3）文件发现的作用

如果增加node或者prometheus服务端节点只需更改nodes_centos.yaml prometheus_server.yaml两个文件添加地址就行，不需要停止服务

2、基于DNS自动发现（仅作了解）

基于DNS的服务发现针对一组DNS域名进行定期查询，以发现待监控的目标，查询时使用的DNS服务器的客户端/etc/resolv.conf文件指定;
该发现机制依赖于A、AAAA和SRV资源记录，且仅支持该类方法，
尚不支持RFC6763中的高级DNS发现方式
PS:
##SRV: SRV记录的作用是指明某域名下提供的服务。实例:
_http._tcp.example.com.SRV 10 5 80. www.example.comSRV后面项目的含义:
10 -优先级，类似MX记录
5 -权重
80-端口
www.example.com -实际提供服务的主机名。同时SRV可以指定在端口上对应哪个service
##prometheus 基于DNS的服务中的SRV记录，让prometheus发现指定target上对应的端口对应的是exporter或instrumentation
pull 形式 以http/https方式，拉取的对应被监控端的指标数据

3、基于consul发现

192.168.100.21

1）相关概念

一款基于golang开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能，提供服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等功能

原理:通过定义json文件将可以进行数据采集的服务注册到consul中，用于自动发现同时使用prometheus做为client端获取consul上注册的服务，从而进行获取数据

2)安装consul_1.9.0版本（promethues端）

unzip consul_1.9.0_linux_amd64.zip -d /usr/local/bin

3)启动开发者模式

consul开发者模式，可以快速开启单节点的consul服务，具有完整功能，方便开发测试

[root@prometheus ~]# mkdir -pv /consul/data/
[root@prometheus ~]# mkdir /etc/consul && cd /etc/consul
[root@prometheus ~]# consul agent -dev -ui -data-dir=/consul/data/ \
 -config-dir=/etc/consul/ -client=0.0.0.0

agent -dev:运行开发模式
agent -server：运行server模式
-ui：ui界面
-data-dir：数据位置
/etc/consul:可以以文件形式定义各个services的配置，也可以基于api接口直接配置
-client：监听地址

4）编辑/etc/consul目录下的prometheus-servers.json配置文件

vim /etc/consul/prometheus-servers.json

{
  "services": [
    {
      "id": "prometheus-server-node01",
      "name": "prom-server-node01",
      "address": "192.168.226.128",
      "port": 9090,
      "tags": ["prometheus"],
      "checks": [{
        "http": "http://192.168.226.128:9090/metrics",
        "interval": "5s"
      }]
    }
  ]
}

#重载配置文件
consul reload
或使用consul service register /etc/consul/prometheus-service.json

##浏览器访问 192.168.100.21:8500

5）创建consul自动发现的prometheus.yml文件

cd /usr/local/prometheus-2.27.1
mkdir consul_sd && cd consul_sd
[root@prometheus consul_sd]# vim prometheus.yml
-------只列出job部分----------
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    consul_sd_configs:
    - server: "192.168.100.21:8500"
      tags:
      - "prometheus"
      refresh_interval: 2m

  # All nodes
  - job_name: 'nodes'
    consul_sd_configs:
    - server: "192.168.100.21:8500"
      tags:
      - "nodes"
      refresh_interval: 2m

#指点配置文件启动
cd /usr/local/prometheus-2.27.1
killall prometheus
./prometheus --config.file=./consul_sd/prometheus.yml
#开启consul服务
consul agent -dev -ui -data-dir=/consul/data/ \
-config-dir=/etc/consul/ -client=0.0.0.0

6）注册其他node节点

1.在192.168.100.21 /etc/consul/目录下编辑nodes.json文件

[root@prometheus ~]# vim /etc/consul/nodes.json

{
  "services": [
    {
      "id": "node_exporter-node01",
      "name": "node01",
      "address": "192.168.100.22",
      "port": 9100,
      "tags": ["nodes"],
      "checks": [{
        "http": "http://192.168.100.22:9100/metrics",
        "interval": "5s"
      }]
    },
    {
      "id": "node_exporter-node02",
      "name": "node02",
      "address": "192.168.100.5",
      "port": 9100,
      "tags": ["nodes"],
      "checks": [{
        "http": "http://192.168.100.5:9100/metrics",
        "interval": "5s"
      }]
    }
  ]
}

#重载配置文件
consul reload

7）、启动node节点

如果node节点没有上线重启以下node节点服务./node_exporter
浏览器访问192.168.100.21:9090 / 192.168.100.21:8500

8）、注销consul中的节点&& 重新加入

(命令形式是临时的)
当重新指定consul文件，可以将文件的节点假如promethues中

consul services deregister xxx.json/-id=web
consul services register /etc/consul/nodes.json		&& 或consul reload

（实际生产中，很多时候会由应用程序、节点或脚本，基于consul 的api进行注册的，而不是直接以人为定义文件的方式进行注册）

###基于K8S API的服务发现????
prom 基于k8s api的服务发现机制，支持将API server中node、service、endpoint、pod和ingress等资源类型下相应的各资源对象视为target，并持续监视相关资源变化情况（K8S 的api server可自动发现及自动添加）
其中
① node、service、endpoint、pod和ingress资源分别由各自的发现机制进行定义
以node为例，pro监控node可以直接在node节点上部署exporter，也可以直接将kubectl视为监控节点的入口之一
kubectl 内置了cadvisor（容器监控工具）
cadvisor ：用来分析运行中的容器的资源占用及其性能特性的工具，同时提供基础查询界面和http接口

② 负责发现每种类型资源对象的组件，在pro中称为一个“role"(role 为每个资源类型独有的一种自动发现机制)
③ 同时支持在集群上基于daemonset控制器部署node-exporter后发现个节点

小结：
服务发现
① 文件定义形式（静态发现高端了一丢丢）
② DNS服务发现——》基于SRV记录
③ consul 服务发现——》利用nodes节点注册到consul，consul暴露出8500端口，给与prometheus进行采集targets（监控端），再到监控端
（node_exporter:9100的端口）来pull抓取数据
④ K8S 待续…

二、grafana的布置

1、简介

grafana是一款基于go语言开发的通用可视化工具，支持从不同的数据源加载并展示数据，可作为其数据源的部分储存系统如下所示：

TSDB：Prometheus、IfluxDB、OpenTSDB和Graphit
日志和文档存储：Loki和ElasitchSearch
分布式请求跟踪：Zipkin、Jaeger和Tenpo
SQL DB：Mysql、PostgreSQL和Microsoft SQL server
grafana基础默认监听于TCP协议的3000端口，支持集成其他认证服务，且能够通过/metrics输出内建指标；

数据源（Data Source）：提供用于展示的数据的储存系统
仪表盘（Dashboard）：组织和管理数据的可视化面板（Panel）
团队和用户：提供了面向企业组织层级的管理能力；

一）centos系统上的部署步骤 （版本7.3.6）

wget https://mirros.huaweicloud.com/grafana/7.3.6/grafana-7.3.6-1.x86_64.rpm
yum install grafana-7.3.6-1.x86_64.rpm


systemctl start grafana-server

#假如用docker容器，运行方式

VERSION=7.3.6
docker run -d --name=grafana -p 3000:3000 grafana/grafana

#账号密码默认为admin,admin
grafana默认配置文件目录 /etc/grafana/grafana.ini

#直接访问ip:3000进入grafana控制台

#grafana模板
https://grafana.com/grafana/dashboards

默认密码 admin admin
vim /etc/grafana/grafana.ini
170-180左右标识密码用户 security模块

#假如想修改默认指标，edit执行prosql语句

创建新面板
—》create添加数据
——》① prometheus_http_requests_total 计算来访的总计数据（进行速率计算）
——》② rate(prometheus_http_requests_total[1h]) 计算1小时来访的总计数据
——》③ rate(prometheus_http_requests_total{code!=“200”}[1h]) 计算1小时来访code不等于200的总计数据（进行速率计算）
###保留语句，记录我们所关心的项目

面板出了像这样自定义外，我们还可以在官网直接找到编号后直接下载
prometheus 数据源面板8919

默认dashboard
https://grafana.com/grafana/dashboards

搜索promethues
prometheus kafka 数据源面板10555

三、打标签（仅作了解）

（一）重新打标定义（在job上定义）

对target重新打标是在数据抓取之前动态重写target标签的强大工具，在每个数据抓取配置中，可以定义多个relabel步骤，它们将按照定义的顺序依次执行;
对于发现的每个target，Prometheus默认会执行如下操作

job的标签设定为其所属的job name的值;
_address_标签的值为该target的套接字地址":"
instance标签的值为_address_的值;
_scheme_标签的值为抓取该target上指标时使用的协议(http或https) ;
_metrics _path_标签的值为抓取该target上的指标时使用URI路径，默认为/metrics;⑥
param_标签的值为传递的URL参数中第一个名称为的参数的值
重新标记期间，还可以使用该target上以"meta "开头的元标签;

各服务发现机制为其target添加的元标签会有所不同;
重新标记完成后，该target上以""开头的所有标签都会被移除;

若在relabel的过程中需要临时存储标签值，则要使用tmp标签名称为前缀进行保存，以避免同Prometheus的内建标签冲突

（二）relabel config(重新打标配置)

修改标签值、增加删除标签，通过调用不同参数实现自己的需求

source_labels：指定调用哪些已有的标签（可引用多个）在重新打标的时候会将这些标签对应的值给引用/提取并连接起来，例如: cpu指标{host=node1; host=node2 }
target_labels：与source_labels组合使用，可以指定使用哪个已有标签赋值给指定的新标签
separator：对应源标签的标签值使用什么连接符，默认为" ;"
regex：对于源标签，使用哪个正则表达式对源标签进行模式匹配、匹配后可以将对应的结果复制到target上，赋值方式:(引用所有正则表达式的内容进行赋值)
modulus ： : hash算法函数
replacement ：把目标标签的值改为新的值
action <relabel_action> ：表示重新打标的方式是什么，以及要实现什么功能