Prometheus部署（一）
Prometheus部署
Prometheus是最初在SoundCloud上构建的开源系统监视和警报工具包。自2012年成立以来，许多公司和组织都采用了Prometheus，该项目拥有非常活跃的开发人员和用户社区。Prometheus 于2016年加入了 Cloud Native Computing Foundation，这是继Kubernetes之后的第二个托管项目。
官网：https://prometheus.io
Exporter是一个采集监控数据并通过Prometheus监控规范对外提供数据的组件，能为Prometheus提供监控的接口。
Exporter将监控数据采集的端点通过HTTP服务的形式暴露给Prometheus Server，Prometheus Server通过访问该Exporter提供的Endpoint端点，即可获取到需要采集的监控数据。不同的Exporter负责不同的业务。
Prometheus 开源的系统监控和报警框架，灵感源自Google的Borgmon监控系统
AlertManager 处理由客户端应用程序（如Prometheus server）发送的警报。它负责将重复数据删除，分组和路由到正确的接收者集成，还负责沉默和抑制警报
Node_Exporter 用来监控各节点的资源信息的exporter，应部署到prometheus监控的所有节点
PushGateway 推送网关，用于接收各节点推送的数据并暴露给Prometheus server
文档：https://prometheus.io/docs/introduction/overview/
下载prometheus各组件：
https://prometheus.io/download/
Prometheus介绍
- prometheus的特点：
1. 多维的数据模型（基于时间序列的Key、Value键值对）
2. 灵活的查询和聚合语言PromQL
3. 提供本地存储和分布式存储
4. 通过基于HTTP的Pull模型采集时间序列数据
5. 可利用Pushgateway（Prometheus的可选中间件）实现Push模式
6. 可通过动态服务发现或静态配置发现目标机器
7. 支持多种图表和数据大盘
- prometheus的组件：
1. Prometheus server，负责拉取、存储时间序列数据
2. 客户端库（client library），插入应用程序代码
3. 推送网关（push gateway），支持短暂的任务
4. 特殊类型的exporter，支持如HAProxy，StatsD，Graphite等服务
5. 一个alertmanager处理告警
6. 各种支持工具
-
架构图
-
prometheus的使用场景：
prometheus非常适合记录任何纯数字时间序列。它既适合以机器为中心的监视，也适合监视高度动态的面向服务的体系结构。在微服务世界中，它对多维数据收集和查询的支持是一种特别的优势。
prometheus的设计旨在提高可靠性，使其成为中断期间要使用的系统，从而使您能够快速诊断问题。每个prometheus服务器都是独立的，而不依赖于网络存储或其他远程服务，当基础设施部分出现问题时仍然可以使用它。
Prometheus概念
- 数据模型：
prometheus将所有数据存储为时间序列：属于相同 metric名称和相同标签组（键值对）的时间戳值流。
-metric 和 标签：
每一个时间序列都是由其 metric名称和一组标签（键值对）组成唯一标识。
metric名称代表了被监控系统的一般特征（如 http_requests_total代表接收到的HTTP请求总数）。它可能包含ASCII字母和数字，以及下划线和冒号，它必须匹配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*。
注意：冒号是为用户定义的记录规则保留的，不应该被exporter使用。
标签给prometheus建立了多维度数据模型：对于相同的 metric名称，标签的任何组合都可以标识该 metric的特定维度实例（例如：所有使用POST方法到 /api/tracks 接口的HTTP请求）。查询语言会基于这些维度进行过滤和聚合。更改任何标签值，包括添加或删除标签，都会创建一个新的时间序列。
标签名称可能包含ASCII字母、数字和下划线，它必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*。另外，以双下划线__开头的标签名称仅供内部使用。
标签值可以包含任何Unicode字符。标签值为空的标签被认为是不存在的标签。
- 表示法:
给定 metric名称和一组标签，通常使用以下表示法标识时间序列：
例如，一个时间序列的 metric名称是 api_http_requests_total，标签是 method="POST" 和 handler="/messages"。可以这样写：
api_http_requests_total{method="POST", handler="/messages"}
这和OpenTSDB的表示法是一样的。
- metric类型：
Counter 值只能单调增加或重启时归零，可以用来表示处理的请求数、完成的任务数、出现的错误数量等
Gauge 值可以任意增加或减少，可以用来测量温度、当前内存使用等
Histogram 取样观测结果，一般用来请求持续时间或响应大小，并在一个可配置的分布区间（bucket）内计算这些结果，提供所有观测结果的总和
累加的 counter，代表观测区间：_bucket{le=""}
所有观测值的总数：_sum
观测的事件数量：_count
Summary 取样观测结果，一般用来请求持续时间或响应大小，提供观测次数及所有观测结果的总和，还可以通过一个滑动的时间窗口计算可分配的分位数
观测的事件流φ-quantiles (0 ≤ φ ≤ 1)：{quantile="φ"}
所有观测值的总和：_sum
观测的事件数量：_count
- 实例与任务：
在prometheus中，一个可以拉取数据的端点叫做实例（instance），一般等同于一个进程。一组有着同样目标的实例（例如为弹性或可用性而复制的进程副本）叫做任务（job）。
当prometheus拉取目标时，它会自动添加一些标签到时间序列中，用于标识被拉取的目标：
job：目标所属的任务名称
instance：目标URL中的:部分
如果两个标签在被拉取的数据中已经存在，那么就要看配置选项 honor_labels 的值来决定行为了。
每次对实例的拉取，prometheus会在以下的时间序列中保存一个样本（样本指的是在一个时间序列中特定时间点的一个值）：
up{job="", instance=""}：如果实例健康（可达），则为 1 ，否则为 0
scrape_duration_seconds{job="", instance=""}：拉取的时长
scrape_samples_post_metric_relabeling{job="", instance=""}：在 metric relabeling 之后，留存的样本数量
scrape_samples_scraped{job="", instance=""}：目标暴露出的样本数量
up 时间序列对于实例的可用性监控来说非常有用。
https://blog.csdn.net/miss1181248983/article/details/107112451/
Prometheus部署
全部关闭防火墙和selinux
systemctl stop firewalld && systemctl disable firewalld
- 下载prometheus：
# wget https://github.com/prometheus/prometheus/releases/download/v2.29.2/prometheus-2.13.1.linux-amd64.tar.gz
wget https://github.com/prometheus/prometheus/releases/download/v2.13.1/prometheus-2.13.1.linux-amd64.tar.gz
tar -zxvf prometheus-2.13.1.linux-amd64.tar.gz
mv prometheus-2.13.1.linux-amd64 prometheus
cd prometheus
vi prometheus.yml
# my global config
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=` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
#采集node exporter监控数据
- job_name: 'node'
static_configs:
- targets: ['172.16.76.246:9100','172.16.245.197:9100','172.16.245.198:9100','172.16.76.245:9100','172.16.76.243:9100','172.16.76.244:9100','172.16.245.196:9100','172.16.76.247:9100','172.16.76.248:9100','172.16.76.249:9100']
- 安装prometheus：
# -M 不要自动建立用户的登入目录
useradd -s /sbin/nologin -M prometheus
mkdir /opt/prometheus/data -p
chown -R prometheus:prometheus /opt/prometheus/
vi /usr/lib/systemd/system/prometheus.service
# vim /etc/systemd/system/prometheus.service
[Unit]
Description=Prometheus
Documentation=https://prometheus.io/
After=network.target
[Service]
Type=simple
User=prometheus
ExecStart=/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml --storage.tsdb.path=/opt/prometheus/data
Restart=on-failure
[Install]
WantedBy=multi-user.target
- 启动prometheus：
systemctl daemon-reload
systemctl enable prometheus && systemctl start prometheus && systemctl status prometheus
netstat -nltp | grep prometheus
tcp6 0 0 :::9090 :::* LISTEN 27238/prometheus
# 查看日志
journalctl -u prometheus -fn 200
- 浏览器访问：
http://121.40.xxx.xxx:9090/service-discovery
http://121.40.xxx.xxx:9090/targets
http://121.40.xxx.xxx:9090/graph
http://121.40.xxx.xxx:9090/metrics
Prometheus配置
prometheus的配置文件prometheus.yml，它主要分以下几个配置块：
全局配置 global
告警配置 alerting
规则文件配置 rule_files
拉取配置 scrape_configs
远程读写配置 remote_read、remote_write
- 全局配置 global：
global指定在所有其他配置上下文中有效的参数。还可用作其他配置部分的默认设置。
global:
# 默认拉取频率
[ scrape_interval: | default = 1m ]
# 拉取超时时间
[ scrape_timeout: | default = 10s ]
# 执行规则频率
[ evaluation_interval: | default = 1m ]
# 通信时添加到任何时间序列或告警的标签
# external systems (federation, remote storage, Alertmanager).
external_labels:
[ : ... ]
# 记录PromQL查询的日志文件
[ query_log_file: ]
- 告警配置 alerting：
alerting指定与Alertmanager相关的设置。
alerting:
alert_relabel_configs:
[ - ... ]
alertmanagers:
[ - ... ]
- 规则文件配置 rule_files：
rule_files指定prometheus加载的任何规则的位置，从所有匹配的文件中读取规则和告警。目前没有规则。
# 一次性加载规则，并根据全局的“评估间隔”定期评估它们。
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"
- 拉取配置 scrape_configs：
scrape_configs指定prometheus监控哪些资源。默认会拉取prometheus本身的时间序列数据，通过
http://localhost:9090/metrics
进行拉取。
一个scrape_config指定一组目标和参数，描述如何拉取它们。在一般情况下，一个拉取配置指定一个作业。在高级配置中，这可能会改变。
可以通过static_configs参数静态配置目标，也可以使用支持的服务发现机制之一动态发现目标。
此外，relabel_configs在拉取之前，可以对任何目标及其标签进行修改。
scrape_configs:
job_name:
# 拉取频率
[ scrape_interval: | default = ]
# 拉取超时时间
[ scrape_timeout: | default = ]
# 拉取的http路径
[ metrics_path: | default = /metrics ]
# honor_labels 控制prometheus处理已存在于收集数据中的标签与prometheus将附加在服务器端的标签("作业"和"实例"标签、手动配置的目标标签和由服务发现实现生成的标签)之间的冲突
# 如果 honor_labels 设置为 "true"，则通过保持从拉取数据获得的标签值并忽略冲突的服务器端标签来解决标签冲突
# 如果 honor_labels 设置为 "false"，则通过将拉取数据中冲突的标签重命名为"exported_"来解决标签冲突(例如"exported_instance"、"exported_job")，然后附加服务器端标签
# 注意，任何全局配置的 "external_labels"都不受此设置的影响。在与外部系统的通信中，只有当时间序列还没有给定的标签时，它们才被应用，否则就会被忽略
[ honor_labels: | default = false ]
# honor_timestamps 控制prometheus是否遵守拉取数据中的时间戳
# 如果 honor_timestamps 设置为 "true"，将使用目标公开的metrics的时间戳
# 如果 honor_timestamps 设置为 "false"，目标公开的metrics的时间戳将被忽略
[ honor_timestamps: | default = true ]
# 配置用于请求的协议
[ scheme: | default = http ]
# 可选的http url参数
params:
[ : [, ...] ]
# 在每个拉取请求上配置 username 和 password 来设置 Authorization 头部，password 和 password_file 二选一
basic_auth:
[ username: ]
[ password: ]
[ password_file: ]
# 在每个拉取请求上配置 bearer token 来设置 Authorization 头部，bearer_token 和 bearer_token_file 二选一
[ bearer_token: ]
# 在每个拉取请求上配置 bearer_token_file 来设置 Authorization 头部，bearer_token_file 和 bearer_token 二选一
[ bearer_token_file: /path/to/bearer/token/file ]
# 配置拉取请求的TLS设置
tls_config:
[ ]
# 可选的代理URL
[ proxy_url: ]
# Azure服务发现配置列表
azure_sd_configs:
[ - ... ]
# Consul服务发现配置列表
consul_sd_configs:
[ - ... ]
# DNS服务发现配置列表
dns_sd_configs:
[ - ... ]
# EC2服务发现配置列表
ec2_sd_configs:
[ - ... ]
# OpenStack服务发现配置列表
openstack_sd_configs:
[ - ... ]
# file服务发现配置列表
file_sd_configs:
[ - ... ]
# GCE服务发现配置列表
gce_sd_configs:
[ - ... ]
# Kubernetes服务发现配置列表
kubernetes_sd_configs:
[ - ... ]
# Marathon服务发现配置列表
marathon_sd_configs:
[ - ... ]
# AirBnB's Nerve服务发现配置列表
nerve_sd_configs:
[ - ... ]
# Zookeeper Serverset服务发现配置列表
serverset_sd_configs:
[ - ... ]
# Triton服务发现配置列表
triton_sd_configs:
[ - ... ]
# 静态配置目标列表
static_configs:
[ - ... ]
# 目标relabel配置列表
relabel_configs:
[ - ... ]
# metric relabel配置列表
metric_relabel_configs:
[ - ... ]
# 每次拉取样品的数量限制
# metric relabelling之后，如果有超过这个数量的样品，整个拉取将被视为失效。0表示没有限制
[ sample_limit: | default = 0 ]
- 远程读写配置 remote_read/remote_write：
remote_read/remote_write将数据源与prometheus分离，当前不做配置。
# 与远程写功能相关的设置
remote_write:
[ - ... ]
# 与远程读功能相关的设置
remote_read:
[ - ... ]
Node Exporter部署
- 下载node_exporter：
wget https://github.com/prometheus/node_exporter/releases/download/v0.18.1/node_exporter-0.18.1.linux-amd64.tar.gz
tar -xf node_exporter-0.18.1.linux-amd64.tar.gz
mkdir -p /opt/prometheus_exporter
mv node_exporter-0.18.1.linux-amd64 /opt/prometheus_exporter/node_exporter
- 安装node_exporter：
# useradd -M -s /sbin/nologin prometheus #若已创建，可省略该步
chown -R prometheus:prometheus /opt/prometheus_exporter/
vim /etc/systemd/system/node_exporter.service
[Unit]
Description=node_exporter
After=network.target
[Service]
Restart=on-failure
ExecStart=/opt/prometheus_exporter/node_exporter/node_exporter
[Install]
WantedBy=multi-user.target
网上配置：
[Unit]
Description=node_exporter
After=network.target
[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/opt/prometheus_exporter/node_exporter/node_exporter \
--web.listen-address=0.0.0.0:9100 \
--web.telemetry-path=/metrics \
--log.level=info \
--log.format=logfmt
Restart=always
[Install]
WantedBy=multi-user.target
- 启动node_exporter：
systemctl daemon-reload
systemctl enable node_exporter && systemctl start node_exporter
systemctl status node_exporter
netstat -lntp | grep node_exporter
tcp6 0 0 :::9100 :::* LISTEN 19315/node_exporter
# 查看日志
journalctl -u node_exporter -fn 200
- 浏览器访问：
http://121.40.xxx.xxx:9100/metrics
[root@prometheus opt]# curl http://localhost:9100/metrics | head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 7.96e-06
go_gc_duration_seconds{quantile="0.25"} 1.0463e-05
go_gc_duration_seconds{quantile="0.5"} 1.156e-05
go_gc_duration_seconds{quantile="0.75"} 1.6091e-05
go_gc_duration_seconds{quantile="1"} 0.000173457
go_gc_duration_seconds_sum 0.701821635
go_gc_duration_seconds_count 43383
# HELP go_goroutines Number of goroutines that currently exist.
100 16190 0 16190 0 0 2144k 0 --:--:-- --:--:-- --:--:-- 2258k
curl: (23) Failed writing body (0 != 2048)
-
node exporter展示了prometheus可以拉取的指标，包括在输出中更下方的各种系统指标（带有前缀node_）。要查看这些指标（以及帮助和类型信息）：
curl http://localhost:9100/metrics | grep 'node_' -
配置scrape_configs：
启动好node_exporter后，还需要配置prometheus才能访问node exporter指标。
vim /opt/prometheus/prometheus.yml
scrape_configs:
# The job name is added as a label `job=` to any timeseries scraped from this config.
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
#采集node exporter监控数据
- job_name: 'node'
static_configs:
- targets: ['172.16.76.246:9100','172.16.245.197:9100','172.16.245.198:9100','172.16.76.245:9100','172.16.76.243:9100','172.16.76.244:9100','172.16.245.196:9100','172.16.76.247:9100','172.16.76.248:9100','172.16.76.249:9100']
systemctl restart prometheus
- 查看node状态： 访问prometheus页面，Status → Targets
可以看到，之前部署的node exporter状态是UP，说明运行正常。
通过部署的node_exporter可以收集当前主机的系统基础信息。如查看系统15分钟平均负载。
node_exporter部署完成。
AlertManager部署
- 下载alertmanager：
wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
tar xf alertmanager-0.21.0.linux-amd64.tar.gz
mv alertmanager-0.21.0.linux-amd64 /opt/alertmanager
mkdir -p /opt/alertmanager/data
# useradd -M -s /sbin/nologin prometheus #若已创建，可省略该步
chown -R prometheus:prometheus /opt/alertmanager
# vim /etc/systemd/system/alertmanager.service
vim /usr/lib/systemd/system/alertmanager.service
[Unit]
Description=Alertmanager
After=network.target
[Service]
Type=simple
User=prometheus
Group=prometheus
ExecStart=/opt/alertmanager/alertmanager \
--config.file=/opt/alertmanager/alertmanager.yml \
--storage.path=/opt/alertmanager/data \
--web.listen-address=0.0.0.0:9093 \
--cluster.listen-address=0.0.0.0:9094 \
--log.level=info \
--log.format=logfmt
Restart=always
[Install]
WantedBy=multi-user.target
每一个 Unit（服务等） 都有一个配置文件，告诉 Systemd 怎么启动这个 Unit 。 Systemd 默认从目录/etc/systemd/system/读取配置文件。 但是，里面存放的大部分文件都是符号链接，指向目录/usr/lib/systemd/system/，真正的配置文件存放在那个目录。 systemctl enable 命令用于在上面两个目录之间，建立符号链接关系。
$ sudo systemctl enable clamd@scan.service
# 等同于
$ sudo ln -s '/usr/lib/systemd/system/clamd@scan.service' '/etc/systemd/system/multi-user.target.wants/clamd@scan.service'
如果配置文件里面设置了开机启动，systemctl enable命令相当于激活开机启动。
与之对应的，systemctl disable命令用于在两个目录之间，撤销符号链接关系，相当于撤销开机启动。
$ sudo systemctl disable clamd@scan.service
配置文件的后缀名，就是该 Unit 的种类，比如sshd.socket。如果省略，Systemd 默认后缀名为.service，所以sshd会被理解成sshd.service。
- 启动alertmanager：
systemctl daemon-reload
systemctl enable alertmanager && systemctl start alertmanager
systemctl status alertmanager
# 查看日志
journalctl -u alertmanager -fn 200
netstat -lntp | grep alertmanager
tcp6 0 0 :::9093 :::* LISTEN 32422/alertmanager
tcp6 0 0 :::9094 :::* LISTEN 32422/alertmanager
curl localhost:9093/metrics | head
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
# HELP alertmanager_alerts How many alerts by state.
# TYPE alertmanager_alerts gauge
alertmanager_alerts{state="active"} 0
alertmanager_alerts{state="suppressed"} 0
# HELP alertmanager_alerts_invalid_total The total number of received alerts that were invalid.
# TYPE alertmanager_alerts_invalid_total counter
alertmanager_alerts_invalid_total{version="v1"} 0
alertmanager_alerts_invalid_total{version="v2"} 0
# HELP alertmanager_alerts_received_total The total number of received alerts.
# TYPE alertmanager_alerts_received_total counter
- 配置alerting： 启动好alertmanager后，还需要配置prometheus才能通过alertmanager告警
vim /opt/prometheus/prometheus.yml #更改 alerting 内容
# my global config
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
- localhost: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=` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090']
#采集node exporter监控数据
- job_name: 'node'
static_configs:
- targets: ['172.16.76.246:9100','172.16.245.197:9100','172.16.245.198:9100','172.16.76.245:9100','172.16.76.243:9100','172.16.76.244:9100','172.16.245.196:9100','172.16.76.247:9100','172.16.76.248:9100','172.16.76.249:9100']
- job_name: 'alertmanager'
static_configs:
- targets: ['localhost:9093']
systemctl restart prometheus
systemctl restart alertmanager
访问prometheus页面，Status → Targets
可以看到，之前部署的alertmanager状态是UP，说明运行正常。
alertmanager部署完成。但alertmanager还需要进一步配置通知路由和通知接收者.
AlertManager配置
alertmanager通过命令行标志和配置文件进行配置。命令行标志配置不可变的系统参数时，配置文件定义禁止规则，通知路由和通知接收器。
alertmanager的配置文件alertmanager.yml，它主要分以下几个配置块：
全局配置 global
通知模板 templates
路由配置 route
接收器配置 receivers
抑制配置 inhibit_rules
- 全局配置 global： global指定在所有其他配置上下文中有效的参数。还用作其他配置部分的默认设置。
global:
# 默认的SMTP头字段
[ smtp_from: ]
# 默认的SMTP smarthost用于发送电子邮件，包括端口号
# 端口号通常是25，对于TLS上的SMTP，端口号为587
# Example: smtp.example.org:587
[ smtp_smarthost: ]
# 要标识给SMTP服务器的默认主机名
[ smtp_hello: | default = "localhost" ]
# SMTP认证使用CRAM-MD5，登录和普通。如果为空，Alertmanager不会对SMTP服务器进行身份验证
[ smtp_auth_username: ]
# SMTP Auth using LOGIN and PLAIN.
[ smtp_auth_password: ]
# SMTP Auth using PLAIN.
[ smtp_auth_identity: ]
# SMTP Auth using CRAM-MD5.
[ smtp_auth_secret: ]
# 默认的SMTP TLS要求
# 注意，Go不支持到远程SMTP端点的未加密连接
[ smtp_require_tls: | default = true ]
# 用于Slack通知的API URL
[ slack_api_url: ]
[ victorops_api_key: ]
[ victorops_api_url: | default = "https://alert.victorops.com/integrations/generic/20131114/alert/" ]
[ pagerduty_url: | default = "https://events.pagerduty.com/v2/enqueue" ]
[ opsgenie_api_key: ]
[ opsgenie_api_url: | default = "https://api.opsgenie.com/" ]
[ wechat_api_url: | default = "https://qyapi.weixin.qq.com/cgi-bin/" ]
[ wechat_api_secret: ]
[ wechat_api_corp_id: ]
# 默认HTTP客户端配置
[ http_config: ]
# 如果告警不包括EndsAt，则ResolveTimeout是alertmanager使用的默认值，在此时间过后，如果告警没有更新，则可以声明警报已解除
# 这对Prometheus的告警没有影响，它们包括EndsAt
[ resolve_timeout: | default = 5m ]
- 通知模板 templates：
templates指定了从其中读取自定义通知模板定义的文件，最后一个文件可以使用一个通配符匹配器，如templates/*.tmpl。
templates:
[ - ... ]
- 路由配置 route：
route定义了路由树中的节点及其子节点。如果未设置，则其可选配置参数将从其父节点继承。
每个告警都会在已配置的顶级路由处进入路由树，该路由树必须与所有告警匹配（即没有任何已配置的匹配器），然后它会遍历子节点。如果continue设置为false，它将在第一个匹配的子项之后停止；如果continue设置为true，则告警将继续与后续的同级进行匹配。如果告警与节点的任何子节点都不匹配（不匹配的子节点或不存在子节点），则根据当前节点的配置参数来处理告警。
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'web.hook'
- 接收器配置 receivers：
receivers是一个或多个通知集成的命名配置。建议通过webhook接收器实现自定义通知集成。
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
- 抑制规则配置 inhibit_rules：
当存在与另一组匹配器匹配的告警（源）时，抑制规则会使与一组匹配器匹配的告警（目标）“静音”。目标和源告警的equal列表中的标签名称都必须具有相同的标签值。
在语义上，缺少标签和带有空值的标签是相同的。因此，如果equal源告警和目标告警都缺少列出的所有标签名称，则将应用抑制规则。
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
- 默认配置示例：
vim /opt/alertmanager/alertmanager.yml
global:
resolve_timeout: 5m
route:
group_by: ['alertname']
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: 'web.hook'
receivers:
- name: 'web.hook'
webhook_configs:
- url: 'http://127.0.0.1:5001/'
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']
- 浏览器访问：
http://121.40.xxx.xxx:9093/#/alerts
http://121.40.xxx.xxx:9093/metrics
Grafana部署
grafana 是一款采用 go 语言编写的开源应用，主要用于大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，目前已经支持绝大部分常用的时序数据库。
官网：https://grafana.com
- 安装grafana：
vim /etc/yum.repos.d/grafana.repo
[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
- 一键安装
yum makecache fast
yum install -y grafana
systemctl daemon-reload
systemctl enable grafana-server && systemctl start grafana-server
netstat -lntp | grep 3000
访问ip:3000，初始账号密码为admin、admin，建议后面更改密码。
grafana部署完成。grafana配置文件：/etc/grafana/grafana.ini。
导入prometheus数据源：
Configuration → Data Sources → Prometheus → Select，填入http://ip:9090，保存即可。
导入dashboard：
官方dashboard模板：https://grafana.com/grafana/dashboards
选择排行第一的中文模板：1 Node Exporter for Prometheus Dashboard CN v20200628，模板ID是8919。
Manage → Import，填入模板ID，导入，
自定义dashboard名称，选择数据源Prometheus，
至此，prometheus + grafana 部署完成。接下来详细配置prometheus的监控与告警。
vi /etc/security/limits.conf
# End of file
root soft nofile 65535
root hard nofile 65535
* soft nofile 65535
* hard nofile 65535
* soft nproc 65535
* hard nproc 65535
* hard memlock unlimited
* soft memlock unlimited
vi /etc/security/limits.d/20-nproc.conf
* soft nproc 65536
root soft nproc unlimited
- ?动部署：
wget https://dl.grafana.com/enterprise/release/grafana-enterprise-
8.1.2.linux-amd64.tar.gz
tar -zxvf grafana-enterprise-8.1.2.linux-amd64.tar.gz
mv grafana-8.1.2 grafana
useradd -s /sbin/nologin -M grafana
mkdir -p /opt/grafana/data
chown -R grafana:grafana /opt/grafana/
vim /opt/grafana/conf/defaults.ini
vi /usr/lib/systemd/system/grafana.service
vim grafana-server.service
[Unit]
Description=Grafana
After=network.target
[Service]
User=grafana
Group=grafana
Type=notify
ExecStart=/opt/grafana/bin/grafana-server -homepath /opt/grafana
Restart=on-failure
[Install]
WantedBy=multi-user.target
- 启动：
systemctl daemon-reload
systemctl enable grafana
systemctl start grafana
systemctl status grafana
journalctl -u grafana -fn 200
配置grafana-node_exporter仪表版 添加data sources，点击添加选择prometheus即可
Name默认Prometheus，URL填写上面配置的prometheus地址http://ip:9090，其他默认，保存即可
在Dashboards页面导入Prometheus Status模板，这里选择导入官网的模板
导入Prometheus仪表版，Dashboards–Manage–import 在 Granfana.com-Dashboard中填写8919，点击load即可。（https://grafana.com/dashboards 中可以直接搜索prometheus，copy ID to Clipboard，grafana官网提供了大量的仪表板模板可以使用）
点击“import”，执行导入，效果如下:
轻量级日志系统Loki部署
一、简 介 Loki是受Prometheus启发由Grafana Labs团队开源的水平可扩展，高度可用的多租户日志聚合系统。 开发语言: Google Go。它的设计具有很高的成本效益，并且易于操作。使用标签来作为索引，而不是对全文进行检索，也就是说，你通过这些标签既可以查询日志的内容也可以查询到监控的数据签，极大地降低了日志索引的存储。系统架构十分简单，由以下3个部分组成 ：
Loki 是主服务器，负责存储日志和处理查询 。 promtail 是代理，负责收集日志并将其发送给 loki 。 Grafana 用于 UI 展示。
只要在应用程序服务器上安装promtail来收集日志然后发送给Loki存储，就可以在Grafana UI界面通过添加Loki为数据源进行日志查询（如果Loki服务器性能不够，可以部署多个Loki进行存储及查询）。作为一个日志系统不关只有查询分析日志的能力，还能对日志进行监控和报警。
二、系 统 架 构
promtail收集并将日志发送给loki的 Distributor 组件
Distributor会对接收到的日志流进行正确性校验，并将验证后的日志分批并行发送到Ingester
Ingester 接受日志流并构建数据块，压缩后存放到所连接的存储后端
Querier 收到HTTP查询请求，并将请求发送至Ingester 用以获取内存数据 ，Ingester 收到请求后返回符合条件的数据 ；
如果 Ingester 没有返回数据，Querier 会从后端存储加载数据并遍历去重执行查询 ，通过HTTP返回查询结果
三、与 ELK 比 较 ELK虽然功能丰富，但规模复杂，资源占用高，操作苦难，很多功能往往用不上，有点杀鸡用牛刀的感觉。 不对日志进行全文索引。通过存储压缩非结构化日志和仅索引元数据，Loki 操作起来会更简单，更省成本。 通过使用与 Prometheus 相同的标签记录流对日志进行索引和分组，这使得日志的扩展和操作效率更高。 安装部署简单快速，且受 Grafana 原生支持。
四、部署
（1）下载安装包（loki、promtail、grafana官网）：
mkdir -p /root/loki
cd /root/loki
curl -O -L "https://github.com/grafana/loki/releases/download/v2.3.0/loki-linux-amd64.zip"
unzip loki-linux-amd64.zip
chmod a+x loki-linux-amd64
wget https://raw.githubusercontent.com/grafana/loki/master/cmd/loki/loki-local-config.yaml
wget https://raw.githubusercontent.com/grafana/loki/main/clients/cmd/promtail/promtail-local-config.yaml
（2）自定义配置文件（loki.yaml和promtail.yaml），由自己创建：
vim loki-local-config.yaml
auth_enabled: false
server:
http_listen_port: 3100
grpc_listen_port: 9096
ingester:
wal:
enabled: true
dir: /tmp/wal
lifecycler:
address: 127.0.0.1
ring:
kvstore:
store: inmemory
replication_factor: 1
final_sleep: 0s
chunk_idle_period: 1h # Any chunk not receiving new logs in this time will be flushed
max_chunk_age: 1h # All chunks will be flushed when they hit this age, default is 1h
chunk_target_size: 1048576 # Loki will attempt to build chunks up to 1.5MB, flushing first if chunk_idle_period or max_chunk_age is reached first
chunk_retain_period: 30s # Must be greater than index read cache TTL if using an index cache (Default index read cache TTL is 5m)
max_transfer_retries: 0 # Chunk transfers disabled
schema_config:
configs:
- from: 2020-10-24
store: boltdb-shipper
object_store: filesystem
schema: v11
index:
prefix: index_
period: 24h
storage_config:
boltdb_shipper:
active_index_directory: /tmp/loki/boltdb-shipper-active
cache_location: /tmp/loki/boltdb-shipper-cache
cache_ttl: 24h # Can be increased for faster performance over longer query periods, uses more disk space
shared_store: filesystem
filesystem:
directory: /tmp/loki/chunks
compactor:
working_directory: /tmp/loki/boltdb-shipper-compactor
shared_store: filesystem
limits_config:
reject_old_samples: true
reject_old_samples_max_age: 168h
chunk_store_config:
max_look_back_period: 0s
table_manager:
retention_deletes_enabled: false
retention_period: 0s
ruler:
storage:
type: local
local:
directory: /tmp/loki/rules
rule_path: /tmp/loki/rules-temp
alertmanager_url: http://localhost:9093
ring:
kvstore:
store: inmemory
enable_api: true
- 启动:
nohup ./loki-linux-amd64 -config.file=loki-local-config.yaml >/dev/null 2>&1 &
vim promtail-local-config.yaml
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /tmp/positions.yaml
clients:
- url: http://localhost:3100/loki/api/v1/push
scrape_configs:
- job_name: system
static_configs:
- targets:
- localhost
labels:
job: varlogs
__path__: /var/log/*log
- 部署promtail-linux-amd64（需要采集日志的服务器）
mkdir -p /root/promtail
cd /root/promtail
wget https://github.com/grafana/loki/releases/download/v2.3.0/promtail-linux-amd64.zip
unzip promtail-linux-amd64.zip
chmod a+x promtail-linux-amd64
wget https://raw.githubusercontent.com/grafana/loki/main/clients/cmd/promtail/promtail-local-config.yaml
yaml配置一:
vim promtail-local-config.yaml
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /tmp/positions.yaml
clients:
- url: http://172.16.76.246:3100/loki/api/v1/push
scrape_configs:
- job_name: journal
pipeline_stages:
- multiline:
firstline: '^\d{4}-\d{2}-\d{2} \d{1,2}:\d{2}:\d{2}'
max_wait_time: 3s
- match:
selector: '{job="systemd-journal",unit!~"xxxx.service|xxxx.service|xxxx.service|xxxx.service|xxxx.service|xxxx.service"}'
action: drop
#stages:
#- regex:
# expression: '^(?s)(?P启动服务(先启loki)：
- 启动：
nohup ./promtail-linux-amd64 -config.file=promtail-local-config.yaml > /dev/null 2>&1 &
yaml配置二:
vim promtail-local-config.yaml
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /tmp/positions.yaml
clients:
- url: http://172.16.76.246:3100/loki/api/v1/push
scrape_configs:
- job_name: journal
pipeline_stages:
- multiline:
firstline: '^\d{4}-\d{2}-\d{2} \d{1,2}:\d{2}:\d{2}'
max_wait_time: 3s
- match:
selector: '{job="systemd-journal",unit!~"xxxx.service|xxxx.service|xxxx.service|webank-financial.service"}'
action: drop
#stages:
#- regex:
# expression: '^(?s)(?P启动服务(先启loki)：
- 启动：
nohup ./promtail-linux-amd64 -config.file=promtail-local-config.yaml > /dev/null 2>&1 &
五、使 用 示 例
（1）浏览器登陆地址：http://127.0.0.1:3000 访问Grafana，首次登陆默认用户名和密码都是 admin，登录后会提示修改密码。
（2）进入Data Sources添加数据源，选择Loki，URL为loki的地址: http://127.0.0.1:3100 ，Name自己定义
（3）然后进入Explore就可以搜索查询日志了，日志查询由两部分组成：日志流选择器和搜索表达式。出于性能原因，需要先通过选择日志标签来选择日志流。查询字段Log labels旁边的按钮显示了可用日志流的标签列表
标签匹配符：
= 完全相等。
!= 不相等。
=~ 正则表达式匹配。
!~ 不进行正则表达式匹配。
例：{job=“UMG-log”,filename="/home/zoehuawang/loki/UMG.07.18.15-40-07.log"}
搜索表达式：
|= 行包含字符串。
!= 行不包含字符串。
|~ 行匹配正则表达式。
!~ 行与正则表达式不匹配。
例：{job=“UMG-log”} |= “07.18” |= “[-973]” != “0xffffffff”
完！！