Alertmanager
告警触发流程
prometheus(将告警存到自己TSDB,并与存取数据与规则进行匹配)--->触发阈值--->超出持续时间--->alertmanager-->分组|抑制|静默--->媒体类型--->邮件|钉钉微信等。
分组(group):将类似性质的警报合并为单个通知,比如网络通知、主机通知、服务通知。
静默(silences):是一种简单的特定时间静音的机制,例如:服务器要升级维护可以先设置这个时间段告警静默
抑制(inhibition):当警报发出后,停止重复发送由此警报引发的其他警报即合并一个故障引起的多个报警事件,可以消除冗余告警
部署alertmanager
wget https://github.com/prometheus/alertmanager/releases/download/v0.24.0/alertmanager-0.24.0.linux-amd64.tar.gz
tar -zxvf alertmanager-0.24.0.linux-amd64.tar.gz
ln -sv /apps/alertmanager-0.24.0.linux-amd64 /apps/alertmanager
vim /etc/systemd/system/alertmanager.service
[Unit]
Description=Prometheus Alertmanager
After=network.target
[Service]
ExecStart=/apps/alertmanager/alertmanager --config.file=/apps/alertmanager/alertmanager.yml
[Install]
WantedBy=multi-user.target
systemctl restart alertmanager.service
systemctl enable alertmanager.service
配置邮箱告警
global:
resolve_timeout: 1m
smtp_smarthost: 'smtp.qq.com:465'
smtp_from: '834943551@qq.com'
smtp_auth_username: '834943551@qq.com'
smtp_auth_password: 'wjalztedjqftbdac'
smtp_require_tls: false
route: #类似路由表,规则匹配把邮件发给谁
group_by: ['alertname'] #对告警进行分类,如某节点cpu告警
group_wait: 30s #一般告警第一次发送之前等待的延迟时间,即产生告警后延迟10秒钟将组内新产生的告警消息一起合并发送(一般设置为0秒~几分钟)
group_interval: 5m #一条成功发送的告警(还未恢复),在最终发送通知之前等待的时间(通常设置为3小时或更长时间)。长时间未恢复告警延迟发送
repeat_interval: 1h #一条成功发送的告警,在最终发送通知之前等待的时间(通常设置为3小时或更长时间)。
receiver: 'web.hook' #接收人信息,可以设置多组
receivers:
- name: 'web.hook'
email_configs:
- to: '2901283510@qq.com'
send_resolved: true
inhibit_rules: #抑制
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'dev', 'instance']这三个分组不发告警
配置Prometheus告警规则
[root@lvs-backup prometheus]# vim prometheus.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- 192.168.226.152:9093
# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
- "/apps/prometheus/rule/service_ruler.yml"
[root@lvs-backup prometheus]# vim rule/service_ruler.yml
groups:
- name: alert_pod_rules
rules:
- alert: Pod_all_cpu_usage
expr: (sum by(name)( rate(container_cpu_usage_seconds_total{image!=""}[5m]))*100) > 100
for: 1m
labels:
serverity: critical
service: pods
annotations:
description: 容器 {{ $labels.name }} CPU 资源利用率大于 10%, 当前值是 ({{ $value }})
summary: CPU 负载告警
验证
配置钉钉告警
告警流程
Prometheus产生告警,发给alertmanager,alertmanager根据配置发给dingtalk,dingtalk调接口发给钉钉
部署并启动dingtalk
nohup ./prometheus-webhook-dingtalk --web.listen-address="0.0.0.0:8060" --ding.profile="alert=https://oapi.dingtalk.com/robot/send?access_token=39cf91648655a524929181fdabae7007c03a3bd1f1db92d4eaf0c85b973fd26b" &
alertmanager添加钉钉配置
- name: dingding
webhook_configs:
- url: "http://192.168.226.152:8060/dingtalk/alert/send"
send_resolved: true
验证
消息中分类告警
根据消息中的属性信息设置规则,将消息分类发送,如严重级别的告警发到钉钉,其他发到邮箱
route:
group_by: ['alertname']
group_wait: 30s
group_interval: 5s
repeat_interval: 20s
receiver: 'web.hook'
routes:
- receiver: dingding
group_wait: 30s
group_interval: 5s
repeat_interval: 20s
match_re:
severity: general #general发钉钉,其余发邮箱
- alert: NodeFilesystemUsage
# expr:表达式。 获取磁盘使用率 大于百分之80 触发
expr: 100 - (node_filesystem_free_bytes{mountpoint="/",fstype=~"ext4|xfs"} / node_filesystem_size_bytes{fstype=~"ext4|xfs"} * 100) > 80
# for:持续时间。 表示持续一分钟获取不到信息,则触发报警。0表示不使用持续时间
for: 1m
# labels:定义当前告警规则级别
labels:
# severity: 指定告警级别。
severity: general
service: node
# annotations: 注释 告警通知
annotations:
# 调用标签具体指附加通知信息
summary: "Instance {{ $labels.instance }} :{{ $labels.mountpoint }} 分区使用率过高" # 自定义摘要
description: "{{ $labels.instance }} : {{ $labels.job }} :{{ $labels.mountpoint }} 这个分区使用大于80% (当前值:{{ $value }})" # 自定义具体描述
自定义告警模板
{{ define "__text_alert_list" }}{{ range . }}
------------------------
告警级别:{{ .Labels.severity }}
告警类型:{{ .Labels.alertname }}
主机: {{ .Labels.instance }}
告警主题: {{ .Annotations.summary }}
告警描叙: {{ .Annotations.description }}
触发时间: {{ .StartsAt.Format "2006-01-02 15:04:05" }}
{{ end }}{{ end }}
nohup ./prometheus-webhook-dingtalk --template.file=/usr/local/dingtalk/default.tmpl --web.listen-address="0.0.0.0:8060" --ding.profile="alert=https://oapi.dingtalk.com/robot/send?access_token=39cf91648655a524929181fdabae7007c03a3bd1f1db92d4eaf0c85b973fd26b" &
PrometheusAlert
Pushgateway
pushgateway简介
pushgateway是采用被动推送的方式,而不是类似于prometheus server主动连接exporter获取监控数据(需要脚本等工具推送给pushgateway)。
pushgateway可以单独运行在一个节点,然后需要自定义监控脚本把需要监控的主动推送给pushgateway的API接口,然后 pushgateway再等待prometheus server抓取数据,即 pushgateway本身没有任何抓取监控数据的功能,目前pushgateway只是被动的等待数据从客户端推送过来。
--persistence.file=""#数据保存的文件,默认只保存在内存中
--persistence.interval=5m#数据持久化的间隔时间
部署pushgateway
[root@lvs-backup apps]# ln -sv /apps/pushgateway-1.4.3.linux-amd64 /apps/pushgateway
"/apps/pushgateway" -> "/apps/pushgateway-1.4.3.linux-amd64"
[root@lvs-backup apps]# cd pushgateway
[root@lvs-backup pushgateway]# nohup ./pushgateway &
验证pushgateway 是否启动
Prometheus配置抓取pushgateway的数据
- job_name: 'pushwateway'
scrape_interval: 15s #采集周期
static_configs:
- targets: ["192.168.226.152:9091"]
honor_labels: true #保留原标签
# honor_labels控制 Prometheus如何处理已经存在于已抓取数据中的标签与Prometheus将附加服务器端的标签之间的冲突("job"和" instance"标签,手动配置的目标标签以及服务发现实现生成的标签)。
#如果honor_labels 设置为"true",则通过保留已抓取数据的标签值并忽略冲突的服务器端标签来解决标签冲突。
#如果honor_labels设置为"false",则通过将已抓取数据中的冲突标签重命名为"“exported<original-label>”(例如"exported_instance" , " exported_job")然后附加服务器端标签来解决标签冲突
测试单条数据推送pushgateway
要Push 数据到PushGateway中,可以通过其提供的API标准接口来添加,默认URL地址为:http:ll<ip>:9091/metrics/job/<JOBNAME>{/<LABEL_NAME>/<LABEL_VALUE>}
其中<JOBNAME>是必填项,为job标签值,后边可以跟任意数量的标签对,一般我们会添加一个instance/<INSTANCE_NAME>实例名称标签,来方便区分各个指标。
echo "mytest_metric 20220624" | curl --data-binary @- http://192.168.226.152:9091/metrics/job/mytest_job
#以二进制形式将数据上传到该路径
自定义脚本收集数据
[root@lvs-backup pushgateway]# vim pushgateway-monitor,sh
#!/bin/bash
total_memory=`free -m | grep -i mem | awk '{print $2}'`
used_memory=`free -m | grep -i mem | awk '{print $4}'`
job_name="custom_memory_monitor"
instance_name=`ifconfig ens33 | grep -w inet | awk '{print $2}'`
pushgateway_server="http://192.168.226.152:9091/metrics/job"
cat <<EOF | curl --data-binary @- ${pushgateway_server}/${job_name}/instance/${instance_name}
#TYPE node_memory_total gauge
node_memory_total ${total_memory}
# TYPE memory_used gauge
node_memory_used ${used_memory}
EOF
删除pushgateway的数据
curl -X DELETE http://192.168.226.152:9091/metrics/job/mytest_job
prometheus联邦
node节点部署node_exporter
部署联邦节点
[root@k8s-master1 apps]# bash prometheus-install.sh
"/apps/prometheus" -> "/apps/prometheus-2.36.0.linux-amd64"
Created symlink from /etc/systemd/system/multi-user.target.wants/prometheus.service to /etc/systemd/system/prometheus.service.
prometheus Server install successful
配置联邦节点监控node节点
- job_name: "prometheus-server"
static_configs:
- targets: ["192.168.226.145:9100","192.168.226.146:9100","192.168.226.144:9100"]
Prometheus server配置采集联邦server
- job_name: 'prometheus-federate-144'
scrape_interval: 10s #采集周期
honor_labels: true
metrics_path: '/federate' #路径
params:
'match[]':
- '{job="prometheus"}'
- '{__name__=~"job:.*"}' #模糊匹配,默认
- '{__name__=~"node.*"}' #模糊匹配,默认
static_configs:
- targets: ["192.168.226.144:9090"]
prometheus存储系统
Prometheus有着非常高效的时间序列数据存储方法,每个采样数据仅仅占用3.5byte 左右空间,上百万条时间序列,30秒间隔,保留60天(默认15天),大概200多G空间(引用官方PPT) 。
默认情况下,prometheus将采集到的数据存储在本地的TSDB数据库中,路径默认为prometheus安装目录的data目录,数据写入过程为先把数据写入wal日志并放在内存,然后2小时后将内存数据保存至一个新的block块,同时再把新采集的数据写入内存并在2小时后再保存至一个新的block块,以此类推。
block特性
block 会压缩、合并历史数据块,以及删除过期的块,随着压缩、合并,block的数量会减少,在压缩过程中会发生三件事:定期执行压缩、合并小的block 到大的block、清理过期的块。
[root@lvs-backup data]# tree /apps/prometheus/data/01G5M4XM0MHE50P9B29634QKES
/apps/prometheus/data/01G5M4XM0MHE50P9B29634QKES
├── chunks
│ └── 000001 #数目录,每个大小为512MB是过会被切分为多个
├── index #索引文件,记录存偏的数操的索引信惠,通过文件内的几个夜来查找时序数据
├── meta.json #block元教据信息,包舍了教据的采集时间和压缩历史
└── tombstones #逻辑数据,主要记载删除的数据和要删除的数据,删除标记,可在删除块时排除样本
1 directory, 4 files
本地存储配置参数
--config.file="prometheus.yml"#指定配置文件
--web.listen-address="0.0.0.0:9090"#指定监听地址
--storage.tsdb.path="data/"#指定数存储目录
--storage.tsdb.retention.size=B, KB,MB,GB,TB, PB, EB #指定chunk 大小,默认512MB
--storage.tsdb.retention.time= #数据保存时长,默认15天
--query.timeout=2m #最大查询超时时间
-query.max-concurrency=20#最大查询并发数
--web.read-timeout=5m #最大空闲超时时间
--web.max-connections=512#最大并发连接数
--web.enable-lifecycle #启用API动态加载配置功能
Prometheus远端存储之:victoriametrics
VictoriaMetrics 是一个快速、经济高效且可扩展的监控解决方案和时间序列数据库。
部署单机版
启动参数
-httpListenAddr=0.0.0.0:8428#监听地址及端口
-storageDataPath #VictoriaMetrics将所有数据存储在此目录中,默认为执行启动victoria 的当前目录下的victoria-metrics-data目录中。
-retentionPeriod #存储数据的保留,较旧的数据会自动删除,默认保留期为1个月,默认单位为m(月),支持的单位有h (hour), d (day),w (week), y (vear)。
配置service文件
[root@lvs-backup apps]# vim /etc/systemd/system/victoriametrics.service
Descriptio=Victoriametrics Server
After=network.target
[Service]
ExecStart=/apps/victoria-metrics-prod -httpListenAddr=0.0.0.0:8428 -storageDataPath=/data/victoria -retentionPeriod=3
[Install]
WantedBy=multi-user.target
[root@lvs-backup apps]# systemctl enable victoriametrics.service
验证
Prometheus添加数据源
remote_write:
- url: http://192.168.226.152:8428/api/v1/write
victoria已写入数据
Prometheus已不在将数据写入本地,grafana已经从Prometheus中读取不到数据
grafana配置读取 victoria中数据
victoria集群版本部署
组件介绍
vminsert #写入组件(写),vminsert负责接收数据写入并根据对度量名称及其所有标签的一致 hash 结果将数据分散写入不同的后端vmstorage 节点之间vmstorage,vminsert默认端口8480
vmstorage #数据持久化组件,默认单副本,存储原始数据并返回给定时间范围内给定标签过滤器的查询数据,默认端口8482。
vmselect#查询组件(读),连接vmstorage ,默认端口8481
其他组件:
vmagent#是一个很小但功能强大的代理,它可以从node_exporter各种来源收集度量数据,并将它们存储在VictoriaMetrics或任何其他支持远程写入协议的与prometheus兼容的存储系统中,有替代prometheus server的意向。
vmalert:替换prometheus server,v以 VictoriaMetrics为数据源,基于兼容prometheus的告警规则,判断数据是否异常,并将产生的通知发送给alertermanager
Vmgateway:读写VictoriaMetrics 数据的代理网关,可实现限速和访问控制等功能,目前为企业版组件vmctl: VictoriaMetrics的命令行工具,目前主要用于将prometheus.opentsdb等数据源的数据迁移到VictoriaMetrics。
部署vmstorage组件
负责数据的持久化,监听端口:API8482 ,数据写入端口:8400,数据读取端口:8401。
[root@lvs-backup system]# vim vmstorage.service
[Unit]
Description=Vmstorage Server
After=network.target
[Service]
Restart=on-failure
WorkingDirectory=/tmp
ExecStart=/usr/local/bin/vmstorage-prod -loggerTimezone Asia/Shanghai -storageDataPath /data/vmstorage-data -httpListenAddr :8482 -vminsertAddr :8400 -vmselectAddr :8401
[Install]
WantedBy=multi-user.target
部署vmselect组件
接收外部的写请求,默认端口8480。
[root@lvs-backup system]# vim vmselect.service
[Unit]
Description=Vminsert Server
After=network.target
[Service]
Restart=on-failure
WorkingDirectory=/tmp
ExecStart=/usr/local/bin/vmselect-prod -httpListenAddr :8481 -storageNode=192.168.226.152:8401,192.168.226.144:8401
[Install]
WantedBy=multi-user.target
部署vmselect组件
负责接收外部的读请求,默认端口8481。
[root@lvs-backup system]# vim vmselect.service
[Unit]
Description=Vminsert Server
After=network.target
[Service]
Restart=on-failure
WorkingDirectory=/tmp
ExecStart=/usr/local/bin/vmselect-prod -httpListenAddr :8481 -storageNode=192.168.226.152:8401,192.168.226.144:8401
[Install]
WantedBy=multi-user.target
Prometheus中配置采集数据源
remote_write:
- url: http://192.168.226.152:8480/insert/0/prometheus
- url: http://192.168.226.144:8480/insert/0/prometheus
grafana配置数据源
导入模板
SkyWalking
分布式链路追踪系统简起源
在较大型的web集群和微服务环境中,客户端的一次请求可能需要经过多个不同的模块、多个不同中间件、多台不同机器的一起相互协作才能处理完成客户端的请求,而在这一系列的请求过程之中,处理流程可能是串行执行也可能是并行执行的,那么如何确定客户端的一次请求到结束的背后究竟调用了哪些应用以及哪些模块并经过了哪些节点,且每个模块的调用先后顺序是怎样的、每个模块的处理相应性能如何?后期随着业务系统的不断增多,业务处理逻辑会越来越复杂,而分布式系统中急需一套链路追踪(Trace)系统来解决这些痛点,从而让运维人员对整个业务系统一目了然、了如指掌。
分布式服务跟踪系统是整个分布式系统中跟踪一个用户请求的完整过程,包括数据采集、数据传输、数据存储、数据分析和数据可视化,获取并存储和分享此类跟踪可以让运维清晰了解用户请求与业务系统交互背后的整个调用链的调用关系,链路追踪系统是针对调试和监控微服务不可或缺的好帮手。