Prometheus+Grafana联合部署

一、Grafana部署

1、Grafana介绍

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）
团队和用户：提供了面向企业组织层级的管理能力

2、部署步骤

[root@prometheus ~]# ls
grafana-7.3.6-1.x86_64.rpm

[root@prometheus ~]# yum install grafana-7.3.6-1.x86_64.rpm -y

[root@prometheus ~]# systemctl start grafana-server.service

[root@prometheus ~]# ss -antp | grep grafana-server

二、打标签

1、重新打标定义（在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的内建标签冲突

2、relabel config(重新打标配置)

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

三、prometheus告警功能

Prometheus对指标的收集、存储同告警能力分属于Prometheus Server和AlertManager(通用的组件)两个独立的组件，前者仅负责基于"告警规则"生成告警通知，具体的告警操作则由后者完成。Alertmanager负责处理由客户端发来的告警通知客户端通常是Prometheus server，但它也支持接收来自其它工具的告警。Alertmanager对告警通知进行分组、去重后，根据路由规则将其路由到不同的receiver，如Email、短信或PagerDuty等。目前Alertmanager还不支持钉钉，那用户完全可以通过Webhook与钉钉机器人进行集成，从而通过钉钉接收告警信息。同时AltManager还提供了静默和告警抑制机制来对告警通知行为进行优化

1、告警功能概述

prometheus对指标的收集、存储与告警能力分属于Prometheus serve和alertmanager两个独立的组件，pro-server只负责通过"告警规则"生成告警通知，具体告警操作是由alertmmanager完成

2、告警规则

是由PromQL编写的布尔值表达式使用>< =与一个常用量值，比如80%进行比较，其返回值为true或false，prometheus-server对抓取到的指标序列与告警规则中做为比较的Prometheus匹配，则会把此样本值抓取过来作比较，若返回值为true则认为指标异常，不能满足false，则为正常值以上表达式为告警规则表达式。比如：筛选一个指标数据cpu使用率<0%系统异常

3、通知告警信息

一旦条件表达式为true了就会触发通知信息，送给altermanager，由alter借助特定服务的API或者访问入口，将此信息发出去一般称为告警媒介，也可以借助邮件进行告警SMTP

4、prometheus监控系统的告警逻辑

route：告警路由，分组、分类分发告警消息给不同渠道
prometheus通过alter-rule规则，生成告警通知给altermanager，altermanager会生成本地的告警路由表（第一路由默认称为根路由，所有的告警信息都需要一个根路由，没有一个匹配项，则需要设置一个默认路由）为实现将特定的信息发送给特定的用户。
例如：
按消息级别来看，严重、中等、普通级别，红色报警、蓝色报警，应用发送方
按分组：业务运维、系统运维、基础设施运维、k8s运维

5、告警功能

除了基本的告警通知能力外，Altermanager还支持对告警进行去重、分组、抑制

6、静默、抑制、分组等功能

分组 （Grouping)：将相似告警合并为单个告警通知的机制，在系统因大面积故障而触发告警潮时，分组机制能避免用户被大量的告警噪声淹没，进而导致关键信息的隐没；
抑制(Inhibition)：系统中某个组件或服务故障而触发告警通知后，那些依赖于该组件或服务的其它组件或服务可能也会因此而触发告警，抑制便是避免类似的级联告警的一种特性，从而让用户能将精力集中于真正的故障所在；
静默(silent)：是指在一个特定的时间窗口内，即便接收到告警通知，Alertmanager也不会真正向用户发送告警信息的行为;通常，在系统例行维护期间，需要激活告警系统的静默特性；
路由(route)：用于配置Alertmanager如何处理传入的特定类型的告警通知，其基本逻辑是根据路由匹配规则的匹配结果来确定处理当前告警通知的路径和行为

四、部署告警对接邮箱

在prometheus-server端定义告警规则，指定alertmanager的位置，将告警信息发送给alert处理

1、安装altermanager

[root@prometheus ~]# cd /opt/

[root@prometheus opt]# ls
alertmanager-0.23.0.linux-amd64.tar.gz

[