Prometheus初体验（三）

一、安装部署

Prometheus基于Golang编写，编译后的软件包，不依赖于任何的第三方依赖。用户只需要下载对应平台的二进制包，解压并且添加基本的配置即可正常启动Prometheus Server。

二进制部署

1、下载安装包

为您的平台下载最新版本的Prometheus，然后解压缩并运行它：

https://prometheus.io/docs/prometheus/latest/getting_started/

tar xvfz prometheus-*.tar.gz
cd prometheus-*
mv prometheus-* /usr/local/prometheus

2、注册为服务

Centos7上，注册为服务：

cat /usr/lib/systemd/system/prometheus.service

 [Unit]
Description=https://prometheus.io

[Service]
Restart=on-failure
ExecStart=/usr/local/prometheus/prometheus --config.file=/usr/local/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target

Centos6上，注册为服务：

#!/bin/bash
#
# Comments to support chkconfig
# chkconfig: 2345 98 02
# description: prometheus service script
#
# Source function library.
. /etc/init.d/functions
 
### Default variables
prog_name="prometheus"
config_file="/usr/local/${prog_name}/${prog_name}.yml"
prog_path="/usr/local/${prog_name}/${prog_name}"
data_path="/usr/local/${prog_name}/data"
pidfile="/var/run/${prog_name}.pid"
prog_logs="/var/log/${prog_name}.log"
#启动项，监听本地9090端口，支持配置热加载
options="--web.listen-address=0.0.0.0:9090 --config.file=${config_file}  --storage.tsdb.path=${data_path}"
DESC="Prometheus Server"

# Check if requirements are met
[ -x "${prog_path}" ] || exit 1
 
RETVAL=0
 
start(){
  action $"Starting $DESC..." su -s /bin/sh -c "nohup $prog_path $options >> $prog_logs 2>&1 &" 2> /dev/null
  RETVAL=$?
  PID=$(pidof ${prog_path})
  [ ! -z "${PID}" ] && echo ${PID} > ${pidfile}
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog_name
  return $RETVAL
}
 
stop(){
  echo -n $"Shutting down $prog_name: "
  killproc -p ${pidfile}
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog_name
  return $RETVAL
}
 
restart() {
  stop
  start
}
 
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog_path
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|status}"
    RETVAL=1
esac
 
exit $RETVAL

3、启动promethues

Centos7：

systemctl start prometheus

Centos6:

service prometheus start

Docker方式部署

https://prometheus.io/docs/prometheus/latest/installation/

prometheus.yml通过运行以下命令将您从主机绑定：

docker run -p 9090:9090 -v /tmp/prometheus.yml:/etc/prometheus/prometheus.yml \
       prom/prometheus

或者为配置使用额外的卷：

docker run -p 9090:9090 -v /prometheus-data \
       prom/prometheus --config.file=/prometheus-data/prometheus.yml

二、界面访问

http://localhost:9090访问自己的状态页面

可以通过访问localhost:9090验证Prometheus自身的指标：localhost:9090/metrics

三、自我监控

Prometheus从目标机上通过http方式拉取采样点数据, 它也可以拉取自身服务数据并监控自身的健康状况

当然Prometheus服务拉取自身服务采样数据，并没有多大的用处，但是它是一个好的DEMO。保存下面的Prometheus配置，并命名为：prometheus.yml:

global:
  scrape_interval:     15s # 默认情况下，每15s拉取一次目标采样点数据。

  # 我们可以附加一些指定标签到采样点度量标签列表中, 用于和第三方系统进行通信, 包括：federation, remote storage, Alertmanager
  external_labels:
    monitor: 'codelab-monitor'

# 下面就是拉取自身服务采样点数据配置
scrape_configs:
  # job名称会增加到拉取到的所有采样点上，同时还有一个instance目标服务的host：port标签也会增加到采样点上
  - job_name: 'prometheus'

    # 覆盖global的采样点，拉取时间间隔5s
    scrape_interval: 5s

    static_configs:
      - targets: ['localhost:9090']

　　重启promethues服务。

通过http://10.11.100.99:9090/targets，就可以查看到了：

四、配置文件

配置文件的格式是YAML，使用--config.file指定配置文件的位置。本节列出重要的配置项。

1、全局配置文件

有关配置选项的完整，请参阅：https://prometheus.io/docs/prometheus/latest/configuration/configuration/

Prometheus以scrape_interval规则周期性从监控目标上收集数据，然后将数据存储到本地存储上。scrape_interval可以设定全局也可以设定单个metrics。

Prometheus以evaluation_interval规则周期性对告警规则做计算，然后更新告警状态。evaluation_interval只有设定在全局。

global：全局配置

alerting：告警配置

rule_files：告警规则

scrape_configs：配置数据源，称为target，每个target用job_name命名。又分为静态配置和服务发现

global:
  # 默认抓取周期，设置每15s采集数据一次，默认1分钟
  [ scrape_interval: <duration> | default = 1m ]
  # 默认抓取超时
  [ scrape_timeout: <duration> | default = 10s ]
  # 估算规则的默认周期 # 每15秒计算一次规则。默认1分钟
  [ evaluation_interval: <duration> | default = 1m ]
  # 和外部系统（例如AlertManager）通信时为时间序列或者警情（Alert）强制添加的标签列表
  external_labels:
    [ <labelname>: <labelvalue> ... ]
 
# 规则文件列表
rule_files:
  [ - <filepath_glob> ... ]
 
# 抓取配置列表
scrape_configs:
  [ - <scrape_config> ... ]
 
# Alertmanager相关配置
alerting:
  alert_relabel_configs:
    [ - <relabel_config> ... ]
  alertmanagers:
    [ - <alertmanager_config> ... ]
 
# 远程读写特性相关的配置
remote_write:
  [ - <remote_write> ... ]
remote_read:
  [ - <remote_read> ... ]

　　其中，比较重要的配置为scrape_configs.

2、scrape_configs

根据配置的任务（job）以http/s周期性的收刮（scrape/pull）

指定目标（target）上的指标（metric）。目标（target）

可以以静态方式或者自动发现方式指定。Prometheus将收刮（scrape）的指标（metric）保存在本地或者远程存储上。

使用scrape_configs定义采集目标

配置一系列的目标，以及如何抓取它们的参数。一般情况下，每个scrape_config对应单个Job。

目标可以在scrape_config中静态的配置，也可以使用某种服务发现机制动态发现。

# 任务名称，自动作为抓取到的指标的一个标签
job_name: <job_name>
 
# 抓取周期
[ scrape_interval: <duration> | default = <global_config.scrape_interval> ]
# 每次抓取的超时
[ scrape_timeout: <duration> | default = <global_config.scrape_timeout> ]
# 从目标抓取指标的URL路径
[ metrics_path: <path> | default = /metrics ]
# 当添加标签发现指标已经有同名标签时，是否保留原有标签不覆盖
[ honor_labels: <boolean> | default = false ]
# 抓取协议
[ scheme: <scheme> | default = http ]
# HTTP请求参数
params:
  [ <string>: [<string>, ...] ]
 
# 身份验证信息
basic_auth:
  [ username: <string> ]
  [ password: <secret> ]
  [ password_file: <string> ]
# Authorization请求头取值
[ bearer_token: <secret> ]
# 从文件读取Authorization请求头
[ bearer_token_file: /path/to/bearer/token/file ]
 
# TLS配置
tls_config:
  [ <tls_config> ]
 
# 代理配置
[ proxy_url: <string> ]
 
# DNS服务发现配置
dns_sd_configs:
  [ - <dns_sd_config> ... ]
# 文件服务发现配置
file_sd_configs:
  [ - <file_sd_config> ... ]
# K8S服务发现配置
kubernetes_sd_configs:
  [ - <kubernetes_sd_config> ... ]
 
# 此Job的静态配置的目标列表，用的最多的配置！！！
static_configs:
  [ - <static_config> ... ]
 
# 目标重打标签配置
relabel_configs:
  [ - <relabel_config> ... ]
# 指标重打标签配置
metric_relabel_configs:
  [ - <relabel_config> ... ]
 
# 每次抓取允许的最大样本数量，如果在指标重打标签后，样本数量仍然超过限制，则整个抓取认为失败
# 0表示不限制
[ sample_limit: <int> | default = 0

`3、relabel_configs`

relabel_configs ：允许在采集之前对任何目标及其标签进行修改

重新标签的意义？

重命名标签名
删除标签
过滤目标

action：重新标签动作

replace：默认，通过regex匹配source_label的值，使用replacement来引用表达式匹配的分组
keep：删除regex与连接不匹配的目标 source_labels
drop：删除regex与连接匹配的目标 source_labels
labeldrop：删除regex匹配的标签
labelkeep：删除regex不匹配的标签
hashmod：设置target_label为modulus连接的哈希值source_labels
labelmap：匹配regex所有标签名称。然后复制匹配标签的值进行分组，replacement分组引用（${1},${2},…）替代

4、基于文件的服务发现

支持服务发现的来源：

azure_sd_configs
consul_sd_configs
dns_sd_configs
ec2_sd_configs
openstack_sd_configs
file_sd_configs
gce_sd_configs
kubernetes_sd_configs
marathon_sd_configs
nerve_sd_configs
serverset_sd_configs
triton_sd_configs

Prometheus也提供了服务发现功能，可以从consul，dns，kubernetes，file等等多种来源发现新的目标。

其中最简单的是从文件发现服务。

https://github.com/prometheus/prometheus/tree/master/discovery

服务发现支持： endpoints，ingress，kubernetes，node，pod，service

五、监控案例

监控Linux服务器

node_exporter：用于*NIX系统监控，使用Go语言编写的收集器。

使用文档：https://prometheus.io/docs/guides/node-exporter/

GitHub：https://github.com/prometheus/node_exporter

exporter列表：https://prometheus.io/docs/instrumenting/exporters/

收集到 node_exporter 的数据后，我们可以使用 PromQL 进行一些业务查询和监控，下面是一些比较常见的查询。

注意：以下查询均以单个节点作为例子，如果大家想查看所有节点，将 instance="xxx" 去掉即可。

CPU使用率：
100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100)
内存使用率：
100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100
磁盘使用率：
100 - (node_filesystem_free_bytes{mountpoint="/",fstype=~"ext4|xfs"} / node_filesystem_size_bytes{mountpoint="/",fstype=~"ext4|xfs"} * 100)

监控Mysql数据库

mysql_exporter：用于收集MySQL性能信息。

https://github.com/prometheus/mysqld_exporter

https://grafana.com/dashboards/7362

登录mysql为exporter创建账号：
mysql> CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'XXXXXXXX' WITH MAX_USER_CONNECTIONS 3;
mysql> GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

# cat .my.cnf 
[client]
user=exporter
password=exporter123

# ./mysqld_exporter --config.my-cnf=.my.cnf
- job_name: 'mysql'
    static_configs:
      - targets: ['localhost:9104']

六、可视化方案

Grafana是一个开源的最近非常流行的度量分析和可视化工具。

https://grafana.com/grafana/download

Grafana支持查询普罗米修斯。自Grafana 2.5.0（2015-10-28）以来，包含了Prometheus的Grafana数据源。

Grafana.com维护着一组共享仪表板，可以下载并与Grafana的独立实例一起使用。

比如

https://grafana.com/dashboards/9276

七、监控告警

告警无疑是监控中非常重要的环节，虽然监控数据可视化了，也非常容易观察到运行状态。但我们很难做到时刻盯着监控，所以程序来帮巡检并自动告警，这个程序是幕后英雄，保障业务稳定性就靠它了。

前面讲到过Prometheus的报警功能主要是利用Alertmanager这个组件。当Alertmanager接收到 Prometheus 端发送过来的 Alerts 时，Alertmanager 会对 Alerts 进行去重复，分组，按标签内容发送不同报警组，包括：邮件，微信，webhook。

使用prometheus进行告警分为两部分：Prometheus Server中的告警规则会向Alertmanager发送。然后，Alertmanager管理这些告警，包括进行重复数据删除，分组和路由，以及告警的静默和抑制。

1、部署Alertmanager

在Prometheus平台中，警报由独立的组件Alertmanager处理。通常情况下，我们首先告诉Prometheus Alertmanager所在的位置，然后在Prometheus配置中创建警报规则，最后配置Alertmanager来处理警报并发送给接收者（邮件，webhook、slack等）。

地址1：https://prometheus.io/download/

地址2：https://github.com/prometheus/alertmanager/releases

注册为服务

#!/bin/bash
#
# Comments to support chkconfig
# chkconfig: 2345 98 02
# description: prometheus service script
#
# Source function library.
. /etc/init.d/functions
 
### Default variables
base_name="alertmanager"
prog_name="alertmanager"
config_file="/usr/local/${base_name}/${prog_name}.yml"
prog_path="/usr/local/${base_name}/${prog_name}"
data_path="/usr/local/${base_name}/data"
pidfile="/var/run/${porg_name}.pid"
prog_logs="/var/log/${prog_name}.log"
#启动项，监听本地9090端口，支持配置热加载
options="--config.file=${config_file}"
DESC="altermanager"

# Check if requirements are met
[ -x "${prog_path}" ] || exit 1
 
RETVAL=0
 
start(){
  action $"Starting $DESC..." su -s /bin/sh -c "nohup $prog_path $options>> $prog_logs 2>&1 &" 2> /dev/null
  RETVAL=$?
  PID=$(pidof ${prog_path})
  [ ! -z "${PID}" ] && echo ${PID} > ${pidfile}
  echo
  [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog_name
  return $RETVAL
}
 
stop(){
  echo -n $"Shutting down $prog_name: "
  killproc -p ${pidfile}
  RETVAL=$?
  echo
  [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog_name
  return $RETVAL
}
 
restart() {
  stop
  start
}
 
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog_path
    RETVAL=$?
    ;;
  *)
    echo $"Usage: $0 {start|stop|restart|status}"
    RETVAL=1
esac
 
exit $RETVAL

启动Alertmanager

service alertmanager start

2、配置alertmanager

一个完整的alertmanager.yml如下：

# 全局配置项
global: 
  resolve_timeout: 5m #处理超时时间，默认为5min
  smtp_smarthost: 'smtp.sina.com:25' # 邮箱smtp服务器代理
  smtp_from: '******@sina.com' # 发送邮箱名称
  smtp_auth_username: '******@sina.com' # 邮箱名称
  smtp_auth_password: '******' # 邮箱密码或授权码
  wechat_api_url: 'https://qyapi.weixin.qq.com/cgi-bin/' # 企业微信地址


# 定义模板信心
templates:
  - 'template/*.tmpl'

# 定义路由树信息
route:
  group_by: ['alertname'] # 报警分组依据
  group_wait: 10s # 最初即第一次等待多久时间发送一组警报的通知
  group_interval: 10s # 在发送新警报前的等待时间
  repeat_interval: 1m # 发送重复警报的周期 对于email配置中，此项不可以设置过低，否则将会由于邮件发送太多频繁，被smtp服务器拒绝
  receiver: 'email' # 发送警报的接收者的名称，以下receivers name的名称

# 定义警报接收者信息
receivers:
  - name: 'email' # 警报
    email_configs: # 邮箱配置
    - to: '******@163.com'  # 接收警报的email配置
      html: '{{ template "test.html" . }}' # 设定邮箱的内容模板
      headers: { Subject: "[WARN] 报警邮件"} # 接收邮件的标题
    webhook_configs: # webhook配置
    - url: 'http://127.0.0.1:5001'
    send_resolved: true
    wechat_configs: # 企业微信报警配置
    - send_resolved: true
      to_party: '1' # 接收组的id
      agent_id: '1000002' # (企业微信-->自定应用-->AgentId)
      corp_id: '******' # 企业信息(我的企业-->CorpId[在底部])
      api_secret: '******' # 企业微信(企业微信-->自定应用-->Secret)
      message: '{{ template "test_wechat.html" . }}' # 发送消息模板的设定
# 一个inhibition规则是在与另一组匹配器匹配的警报存在的条件下，使匹配一组匹配器的警报失效的规则。两个警报必须具有一组相同的标签。 
inhibit_rules: 
  - source_match: 
     severity: 'critical' 
    target_match: 
     severity: 'warning' 
    equal: ['alertname', 'dev', 'instance']

设置告警和通知的主要步骤如下：

部署Alertmanager
配置Prometheus与Alertmanager通信
在Prometheus中创建告警规则

a、配置Prometheus与Alertmanager通信

# vi prometheus.yml
alerting:
  alertmanagers:
  - static_configs:
    - targets:
       - 127.0.0.1:9093

b、在Prometheus中创建告警规则

# vi prometheus.yml
rule_files:
   - "rules/*.yml"

# vi rules/node.yml
groups:
- name: example   # 报警规则组名称
  rules:
  # 任何实例5分钟内无法访问发出告警
  - alert: InstanceDown
    expr: up == 0
    for: 5m  #持续时间 ， 表示持续一分钟获取不到信息，则触发报警
    labels:
      severity: page  # 自定义标签
    annotations:
      summary: "Instance {{ $labels.instance }} down" # 自定义摘要
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes." # 自定义具体描述

c、触发告警

d、告警状态

一旦这些警报存储在Alertmanager，它们可能处于以下任何状态：

Inactive：这里什么都没有发生。
Pending：已触发阈值，但未满足告警持续时间（即rule中的for字段）
Firing：已触发阈值且满足告警持续时间。警报发送到Notification Pipeline，经过处理，发送给接受者。

这样目的是多次判断失败才发告警，减少邮件。

3、告警分配

route属性用来设置报警的分发策略，它是一个树状结构，按照深度优先从左向右的顺序进行匹配。

route:
  receiver: 'default-receiver'  
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  group_by: [cluster, alertname]
# 所有不匹配以下子路由的告警都将保留在根节点，并发送到“default-receiver”
  routes:
# 所有service=mysql或者service=cassandra的告警分配到数据库接收端
  - receiver: 'database-pager'
    group_wait: 10s
    match_re:
      service: mysql|cassandra
# 所有带有team=frontend标签的告警都与此子路由匹配
# 它们是按产品和环境分组的，而不是集群
  - receiver: 'frontend-pager'
    group_by: [product, environment]
    match:
      team: frontend

group_by：报警分组依据

group_wait：为一个组发送通知的初始等待时间，默认30s

group_interval：在发送新告警前的等待时间。通常5m或以上

repeat_interval：发送重复告警的周期。如果已经发送了通知，再次发送之前需要等待多长时间。通常3小时或以上

主要处理流程：

接收到Alert，根据labels判断属于哪些Route（可存在多个Route，一个Route有多个Group，一个Group有多个Alert）。
将Alert分配到Group中，没有则新建Group。
新的Group等待group_wait指定的时间（等待时可能收到同一Group的Alert），根据resolve_timeout判断Alert是否解决，然后发送通知。
已有的Group等待group_interval指定的时间，判断Alert是否解决，当上次发送通知到现在的间隔大于repeat_interval或者Group有更新时会发送通知。

4、告警收敛（分组、抑制、静默）

告警面临最大问题，是警报太多，相当于狼来了的形式。收件人很容易麻木，不再继续理会。关键的告警常常被淹没。在一问题中，alertmanger在一定程度上得到很好解决。

Prometheus成功的把一条告警发给了Altermanager，而Altermanager并不是简简单单的直接发送出去，这样就会导致告警信息过多，重要告警被淹没。所以需要对告警做合理的收敛。

告警收敛手段：

分组（group）：将类似性质的警报分类为单个通知

抑制（Inhibition）：当警报发出后，停止重复发送由此警报引发的其他警报

静默（Silences）：是一种简单的特定时间静音提醒的机制

5、Prometheus一条告警怎么触发的？

报警处理流程如下：

Prometheus Server监控目标主机上暴露的http接口（这里假设接口A），通过上述Promethes配置的'scrape_interval'定义的时间间隔，定期采集目标主机上监控数据。
当接口A不可用的时候，Server端会持续的尝试从接口中取数据，直到"scrape_timeout"时间后停止尝试。这时候把接口的状态变为“DOWN”。
Prometheus同时根据配置的"evaluation_interval"的时间间隔，定期（默认1min）的对Alert Rule进行评估；当到达评估周期的时候，发现接口A为DOWN，即UP=0为真，激活Alert，进入“PENDING”状态，并记录当前active的时间；
当下一个alert rule的评估周期到来的时候，发现UP=0继续为真，然后判断警报Active的时间是否已经超出rule里的‘for’ 持续时间，如果未超出，则进入下一个评估周期；如果时间超出，则alert的状态变为“FIRING”；同时调用Alertmanager接口，发送相关报警数据。
AlertManager收到报警数据后，会将警报信息进行分组，然后根据alertmanager配置的“group_wait”时间先进行等待。等wait时间过后再发送报警信息。
属于同一个Alert Group的警报，在等待的过程中可能进入新的alert，如果之前的报警已经成功发出，那么间隔“group_interval”的时间间隔后再重新发送报警信息。比如配置的是邮件报警，那么同属一个group的报警信息会汇总在一个邮件里进行发送。
如果Alert Group里的警报一直没发生变化并且已经成功发送，等待‘repeat_interval’时间间隔之后再重复发送相同的报警邮件；如果之前的警报没有成功发送，则相当于触发第6条条件，则需要等待group_interval时间间隔后重复发送。
同时最后至于警报信息具体发给谁，满足什么样的条件下指定警报接收人，设置不同报警发送频率，这里有alertmanager的route路由规则进行配置。

6、编写告警规则案例

# cat rules/general.yml 
groups:
- name: general.rules
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 2m
    labels:
      severity: error
    annotations:
      summary: "Instance {{ $labels.instance }} 停止工作"
      description: "{{ $labels.instance }}: job {{ $labels.job }} 已经停止5分钟以上."


# cat rules/node.yml
groups:
- name: node.rules
  rules:
  - alert: NodeFilesystemUsage
    expr: 100 - (node_filesystem_free_bytes{fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: {{$labels.mountpoint }} 分区使用过高"
      description: "{{$labels.instance}}: {{$labels.mountpoint }} 分区使用大于 80% (当前值: {{ $value }})"
  - alert: NodeMemoryUsage
    expr: 100 - (node_memory_MemFree_bytes+node_memory_Cached_bytes+node_memory_Buffers_bytes) / node_memory_MemTotal_bytes * 100 > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: 内存使用过高"
      description: "{{$labels.instance}}: 内存使用大于 80% (当前值: {{ $value }})"
  - alert: NodeCPUUsage
    expr: 100 - (avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance) * 100) > 80
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: CPU使用过高"
      description: "{{$labels.instance}}: CPU使用大于 80% (当前值: {{ $value }})"

# cat rules/reload.yml 
groups:
- name: prometheus.rules
  rules:
  - alert: AlertmanagerReloadFailed
    expr: alertmanager_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: Alertmanager配置重新加载失败"
      description: "{{$labels.instance}}: Alertmanager配置重新加载失败"
  - alert: PrometheusReloadFailed
    expr: prometheus_config_last_reload_successful == 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "{{$labels.instance}}: Prometheus配置重新加载失败"
      description: "{{$labels.instance}}: Prometheus配置重新加载失败"

posted @ 2019-08-09 13:26 skyflask 阅读(1594) 评论(0) 编辑收藏举报

刷新页面返回顶部

On The Way！

On The Way！

博学，审问，慎思，明辨，笃行。一份属于自己心路历程！人生如棋，我愿为卒，行动虽缓，何曾退缩！

Prometheus初体验（三）

一、安装部署

二进制部署

2、注册为服务

3、启动promethues

Docker方式部署

二、界面访问

三、自我监控

四、配置文件

1、全局配置文件

2、scrape_configs

`3、relabel_configs`

4、基于文件的服务发现

五、监控案例

监控Linux服务器

监控Mysql数据库

六、可视化方案

七、监控告警

1、部署Alertmanager

2、配置alertmanager

3、告警分配

4、告警收敛（分组、抑制、静默）

5、Prometheus一条告警怎么触发的？

6、编写告警规则案例

公告

On The Way！

On The Way！

博学，审问，慎思，明辨，笃行。一份属于自己心路历程！ 人生如棋，我愿为卒，行动虽缓，何曾退缩！

Prometheus初体验（三）

一、安装部署

二进制部署

2、注册为服务

3、启动promethues

Docker方式部署

二、界面访问

三、自我监控

四、配置文件

1、全局配置文件

2、scrape_configs

3、relabel_configs

4、基于文件的服务发现

五、监控案例

监控Linux服务器

监控Mysql数据库

六、可视化方案

七、监控告警

1、部署Alertmanager

2、配置alertmanager

3、告警分配

4、告警收敛（分组、抑制、静默）

5、Prometheus一条告警怎么触发的？

6、编写告警规则案例

公告

博学，审问，慎思，明辨，笃行。一份属于自己心路历程！人生如棋，我愿为卒，行动虽缓，何曾退缩！

`3、relabel_configs`