docker promethues的服务发现和grafana
Posted 遙遙背影暖暖流星
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了docker promethues的服务发现和grafana相关的知识,希望对你有一定的参考价值。
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> :表示重新打标的方式是什么,以及要实现什么功能
以上是关于docker promethues的服务发现和grafana的主要内容,如果未能解决你的问题,请参考以下文章