prometheus告警规则的配置 prometheus告警抑制

转载

mob64ca14061c9e 2024-04-25 08:52:21

文章标签 prometheus告警规则的配置 prometheus 数据 hg vim 文章分类 云原生云计算

一、Alertmanager

prometheus触发一条告警的过程：
prometheus–>触发闽值->超出持续时间->alertmanager–>分组|抑制|静默–>媒体类型->邮件|钉钉|微信等。

分组（group）：将类似性质的警报合并为单个通知，比如网络通知、主机通知、服务通知。
静默（silences）：是一种简单的特定时间静音的机制，例如：服务器要升级维护可以先设置这个时间段告警静默。
抑制（inhibition）：当警报发出后，停止重复发送由此警报引发的其他警报即合并一个故障引起的多个报警事件，可以消除冗余告警

安装alertmanager：

官方配置文档：https://prometheus.io/docs/alerting/latest/configuration/

[root@k8s-ha1 apps]#tar xvf alertmanager-0.23.0.linux-amd64.tar.gz 
[root@k8s-ha1 apps]#ln -sv alertmanager-0.23.0.linux-amd64 alertmanager
[root@k8s-ha1 apps]#ll alertmanager/
total 53596
drwxr-xr-x 2 3434 3434       93 Aug 25  2021 ./
drwxr-xr-x 4 root root      235 Mar 25 16:06 ../
-rw-r--r-- 1 3434 3434    11357 Aug 25  2021 LICENSE
-rw-r--r-- 1 3434 3434      457 Aug 25  2021 NOTICE
-rwxr-xr-x 1 3434 3434 30942810 Aug 25  2021 alertmanager*
-rw-r--r-- 1 3434 3434      348 Aug 25  2021 alertmanager.yml
-rwxr-xr-x 1 3434 3434 23913946 Aug 25  2021 amtool*

[root@k8s-ha1 apps]#vim /etc/systemd/system/alertmanager.service
[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target

[Service]
Restart=on-failure
WorkingDirectory=/apps/alertmanager
ExecStart=/apps/alertmanager/alertmanager

[Install]
WantedBy=multi-user.target
[root@k8s-ha1 apps]#systemctl daemon-reload && systemct1 restart alertmanager.service && systemct1 enable alertmanager.service

1、邮件通知:

（1）配置alertmanager并启动
[root@k8s-ha1 alertmanager]#vim alertmanager.yml 
见alertmanager.yml文档-邮件通知

[root@k8s-ha1 alertmanager]#./amtool check-config alertmanager.yml 
Checking 'alertmanager.yml'  SUCCESS
Found:
 - global config
 - route
 - 1 inhibit rules
 - 1 receivers
 - 0 templates

[root@k8s-ha1 alertmanager]#systemct1 restart alertmanager.service
[root@k8s-ha1 alertmanager]#ss -ntl |grep 9093
LISTEN  0        4096                   *:9093                 *:*      
#验证web访问：http://192.168.150.159:9093/

（2）配置prometheus报警规则：
[root@k8s-harbor1 prometheus]#cd /etc/prometheus/
[root@k8s-harbor1 prometheus]#vim prometheus.yml 

# Alertmanager配置
alerting: 
  alertmanagers:
  - static_configs:
    - targets: ['192.168.150.159:9093']

# 规则配置
rule_files: 
  - "/etc/prometheus/rule.yml" #指定rule文件
  # - "first_rules.yml"
  # - "second_rules.yml"

（3）创建报警规则文件：
[root@k8s-harbor1 prometheus]#vim rule.yml
见alertmanager.yml文档-rule.yml

#报警规则验证：
[root@k8s-ha1 prometheus]#./promtool check rules rule.yml #监测rule规则文件是否正确
Checking rule.yml
  SUCCESS: 6 rules found

#重启prometheus：
[root@k8s-harbor1 prometheus]#systemctl restart prometheus

（4）验证
#验证报警规则匹配：
[root@k8s-ha1 alertmanager]#./amtool alert --alertmanager.url=http://192.168.150.159:9093
Alertname 			Starts At 				summary
Pod all_cpu usage 2019-08-07 07：39：04 cST Dev CPU负载告警

#prometheus首页alerts状态：
http://192.168.150.154:9090/alerts
promethus报警状态：
·Inactive：没有异常。
·Pending：已触发阈值，但未满足告警持续时间（即rule中的for字段）
·Firing：已触发阈值且满足条件并发送至alertmanager

#prometheus web界面验证报警规则：
http://192.168.150.154:9090/rules
Status-->Rules

#验证收到的报警邮件：
qq邮箱查看

2、钉钉通知

https://im.dingtalk.com/

（1）钉钉群组创建机器人-关键字认证：
1\电脑版本添加-群机器人-添加机器人-自定义
自定义关键字：如alertname
Webhook：https://oapi.dingtalk.com/robot/send?access_token=7f87fe3afafbfc330
使用 Webhook 地址，向钉钉群推送消息
2\部署Webhook-dingtalk
#tar xvf prometheus-webhook-dingtalk-1.4.0.linux-amd64.tar.gz 
#cd prometheus-webhook-dingtalk-1.4.0.linux-amd64/
#./prometheus-webhook-dingtalk --web.listen-address="0.0.0.0:8060" --ding.profile="alertname=https://oapi.dingtalk.com/robot/send?access_token=7f87fe3afafbfc330"
#nohup ./prometheus-webhook-dingtalk --web.listen-address="0.0.0.0:8060" --ding.profile="alertname=https://oapi.dingtalk.com/robot/send?access_token=ba76276cd923a4e5dc d653ffabe4b71c4a23e8c4eb8e91446840d527c8d9cd4e"&
3\配置alertmanager并启动
https://prometheus.io/docs/alerting/latest/configuration/
[root@k8s-ha1 alertmanager]#vim alertmanager.yml   
route: 
  receiver: dingding
receivers:
  - name: dingding
    webhook_configs：
    - url: 'http://172.31.2.120:8060/dingtalk/alertname/send'
      send_resolved: true
[root@k8s-ha1 alertmanager]#./alertmanager
4\验证消息发送
#dingtalk验证日志
#钉钉验证消息

（2）钉钉群组创建机器人-加签认证：
1\电脑版本添加-群机器人-添加机器人-自定义
加签：SEC1b1b6d07a534bb46f5b5c88a35c742d0b83c47641793d4e2a6797f757d065923
Webhook：https://oapi.dingtalk.com/robot/send?access_token=d29ee91f14c4b26be50ccfff
2\编写python脚本实现
3\配置alertmanager并启动(不变)

钉钉如何调用服务端API
https://open.dingtalk.com/document/orgapp-server/how-to-call-apis https://github.com/timonwong/prometheus-webhook-dingtalk

3、企业微信通知:

（1）打开企业微信官网注册账号并登录pc版
https://work.weixin.qq.com/

（2）创建应用：
应用管理-创建应用-短信故障通知-注册完成
AgentID和Secret会在发送微信报警信息的时候调用

填写应用信息：
注册完成：
使用移动端微信扫描登录：
创建应用：
应用管理-创建应用-企业微信通知-注册完成

创建微信账号：
验证通讯录：
查看企业信息：
企业ID在发送微信报警信息的时候会调用

测试发送信息：
认证信息收集：
AgentID、Secret、企业ID

alertermanager配置：
[root@k8s-ha1 alertmanager]#vim alertmanager.yml 
route: 
  receiver: wechat
receivers:
  -name: 'wechat'
    wechat_configs：
    - corp_id: ww4c893118fbf4d07c
      #to_user: '@all'
      to_party：2 #部门ID，消息发送给指定组
      agent_id：1000004
      api_secret: STd8cpSsa2RAxH16WpnL6ZiOVXulbh-XBh2_1kAnAU
      send_resolved: true

企业微信验证消息：

4、消息分类发送:

根据消息中的属性信息设置规则，将消息分类发送，如将severity级别为critical的通知消息发送到dingding，其它的则发送到微信：

[root@k8s-ha1 alertmanager]#vim alertmanager.yml 
见alertmanager.yml文档-消息分类发送
#验证消息发送

5、自定义消息模板:

默认的消息内容需要调整、而且消息是连接在一起的。

（1）定义模板：
#vim /apps/alertmanager-0.23.0.linux-amd64/message_template.templ
{{ define "wechat.default.message" }}
{{ range $i,$alert:=.Alerts }}
===alertmanager 监控报警===
告警状态: {{  .Status }}
告警级别: {{ $alert.Labels.severity }}
告警类型: {{ $alert.Labels.alertname }}
告警应用: {{ $alert.Annotations.summary }}
故障主机: {{ $alert.Labels.instance }}
告警主题: {{ $alert.Annotations.summary }}
触发阀值: {{ $alert.Annotations.value }}
告警详情: {{ $alert.Annotations.description }}
触发时间: {{ $alert.StartsAt.Format"2006-01-02 15:04:05" }}
============end============
{{ end }}
{{ end }}
（2）alertermanager引用模板
[root@k8s-ha1 alertmanager]#vim alertmanager.yml   
templates:
  - '/apps/alertmanager-0.23.0.linux-amd64/message_template.templ'
（3）验证消息内容

6、告警抑制与静默:

告警抑制：
基于告警规则，超过80%就不再发60%的告警，即由60%的表达式触发的告警被抑制了。

[root@k8s-harbor1 prometheus]#vim pods_rule.yaml 
    rules:
    - alert: 磁盘容量
      expr: 100-(node_filesystem_free_bytes{fstype=~"ext4|xfs"}/node_filesystem_size_bytes {fstype=~"ext4|xfs"}*100) > 80  #磁盘容量利用率大于80%
      for: 2s
      labels:
        severity: critical
      annotations:
        summary: "{{$labels.mountpoint}} 磁盘分区使用率过高！"
        description: "{{$labels.mountpoint }} 磁盘分区使用大于80%(目前使用:{{$value}}%)"

    - alert: 磁盘容量
      expr: 100-(node_filesystem_free_bytes{fstype=~"ext4|xfs"}/node_filesystem_size_bytes {fstype=~"ext4|xfs"}*100) > 60 #磁盘容量利用率大于60%
      for: 2s
      labels:
        severity: warning
      annotations:
        summary: "{{$labels.mountpoint}} 磁盘分区使用率过高！"
        description: "{{$labels.mountpoint }} 磁盘分区使用大于80%(目前使用:{{$value}}%)"

手动静默：
网页–找到告警事件–点击slience

7、alertermanager高可用:

单机架构
高可用架构：基于负载均衡
基于Gossip机制：
https://yunlzheng.gitbook.io/prometheus-book/part-ii-prometheus-jin-jie/readmd/alertmanager-high-availability Alertmanager引入了Gossip机制。Gossip机制为多个Alertmanager之间提供了信息传递的机制。
确保及时在多个Alertmanager分别接收到相同告警信息的情况下，也只有一个告警通知被发送给Receiver。

8、PrometheusAlert:

https://github.com/feiyu563/PrometheusAlert PrometheusAlert是开源的运维告警中心消息转发系统，支持主流的监控系统Prometheus、Zabbix，日志系统Graylog2，Graylog3、数据可视化系统Grafana、SonarQube，
阿里云-云监控，以及所有支持WebHook接口的系统发出的预警消息，支持将收到的这些消息发送到钉钉，微信，email，飞书，腾讯短信，腾讯电话，阿里云短信，
阿里云电话，华为短信，百度云短信，容联云电话，七陌短信，七陌语音，TeleGram，百度Hi（如流）等。

二、pushgateway

https://github.com/prometheus/pushgateway

1、pushgateway简介:

pushgateway是采用被动推送的方式,而不是类似于prometheus server 主动连接exporter获取监控数据。
pushgateway可以单独运行在一个节点,然后需要自定义监控脚本把需要监控的主动推送给pushgateway的API接口,然后pushgateway 再等待prometheus server 抓取数据,
即pushgateway本身没有任何抓取监控数据的功能,目前 pushgateway只是被动的等待数据从客户端推送过来。
–persistence.file=1"#数据保存的文件,默认只保存在内存中
–persistence.interval=5m#数据持久化的间隔时间

2、部署pushgateway:

#docker load -i pushgateway.tar.gz
#docker run -d --name pushgateway -p 9091:9091 prom/pushgateway
#验证pushgateway数据:
192.168.150.161:9091/metrics

3、prometheus到pushgateway采集数据:

[root@k8s-master1 case]#vim prometheus-cfg.yaml 
  #通过pushgatway采集节点的指标数据:
  - job_name: pushgatway-monitoring
    scrape_interval: 5s
    static_configs:
      - targets: ['192.168.150.161:9091']	
	honor_labels: true
[root@k8s-master1 case]#kubectl apply -f prometheus-cfg.yaml && kubectl delete -f prometheus-deployment.yaml && kubectl apply -f prometheus-deployment.yaml 

#honor_labels控制Prometheus如何处理已经存在于已抓取数据中的标签与Prometheus将附加服务器端的标签之间的冲突("job“和"instance”标签,手动配置的目标标签以及服务发现实现生成的标签)。
#如果honor_labels设置为“true",则通过保留已抓取数据的标签值并忽略冲突的服务器端标签来解决标签冲突。
#如果honor_labels设置为“false",则通过将已抓取数据中的冲突标签重命名为“exported_<original-label>"(例如"exported_instance","exported_job")然后附加服务器端标签来解决标签冲突

#验证Prometheus数据:
192.168.150.151:30090/targets

4、测试从客户端推送数据:

(1)测试从客户端推送单条数据:
要Push 数据到PushGateway中,可以通过其提供的API标准接口来添加,默认URL地址为:
http://:9091/metrics/job/{//}. 其中是必填项,为job标签值,后边可以跟任意数量的标签对,一般我们会添加一个instance/<INSTANCE_NAME>实例名称标签,来方便区分各个指标。

例如:推送一个job名称为mytest_job,key为mytest_metric值为2022
#echo “mytest_metric 2022” | curl --data-binary@-http://192.168.150.161:9091/metrics/job/mytest_job

pushgateway验证数据:
http://192.168.150.161:9091/# http://192.168.150.161:9091/metrics
除了mytest_metric外,同时还新增了push_time_seconds和push_failure_time_seconds两个指标,这两个是PushGateway自动生成的指标,
分别用于记录指标数据的成功上传时间和失败上传时间。

Prometheus验证数据:
192.168.150.151:30090-搜素mytest_metric

(2)测试从客户端推送多条数据:

#cat <<EOF | curl --data-binary@-http://192.168.150.161:9091/metrics/job/test_job/instance/172.31.0.100
#TYPE node_memory_usage gauge 
node_memory_usage 4311744512
#TYPE memory_total gauge 
node_memory_total 103481868288
EOF

pushgateway验证数据:
Prometheus验证数据:

5、自定义收集数据

基于自定义脚本实现数据的收集和推送
#vim mem_monitor.sh
#/bin/bash 
total_memory=$(free |awk '/Mem/{print $2}')
used_memory=$(free |awk '/Mem/{print $3}')
job_name="custom_memory_monitor"
instance_name=`ifconfig eth0 | grep -w inet | awk '{print $2}'`
pushgateway_server="http://192.168.150.161:9091/metrics/job"

cat <<EOF |curl --data-binary@-${pushgateway_server}/${job_name}/instance/${instance_name}
#TYPE custom_memory_total gauge 
custom_memory_total $total_memory
#TYPE custom_memory_used gauge 
custom_memory_used $used_memory 
EOF

#分别在不同主机执行脚本,验证指标数据收集和推送:
#bash mem_monitor.sh

pushgateway验证数据:
Prometheus验证数据:

6、删除数据

首先对一个组写入多条instance数据:
#cat <<EOF | curl --data-binary@-http://192.168.150.161:9091/metrics/job/test_job/instance/172.31.0.100
#TYPE node_memory_usage gauge 
node_memory_usage 4311744512
#TYPE memory_total gauge 
node_memory_total 103481868288
EOF
#cat <<EOF | curl --data-binary@-http://192.168.150.161:9091/metrics/job/test_job/instance/172.31.0.101
#TYPE node_memory_usage gauge 
node_memory_usage 4311744512
#TYPE memory_total gauge 
node_memory_total 103481868288
EOF

通过API删除指定组内指定实例的数据:
#curl -X DELETE http://192.168.150.161:9091/metrics/job/test_job/instance/172.31.0.100
通过web界面删除
http://192.168.150.161:9091/#

三、Prometheus联邦机制

环境:
192.168.150.151 #主节点
192.168.150.152 #联邦节点
192.168.150.153 #联邦节点
192.168.150.161 #node1,联邦节点1的目标采集服务器
192.168.150.162 #node2,联邦节点2的目标采集服务器

#主节点和联邦节点分别部署prometheus_server
二进制部署
#node节点(被监控节点)分别部署node-exporter(exporter)
二进制部署
#配置联邦节点监控node节点
分别在联邦节点1监控node1,联邦节点2监控node2

#prometheus主节点采集联邦节点数据:
  #采集联邦节点的指标数据:
  - job_name: prometheus-federate-150.152
    scrape_interval: 10s
	honor_labels: true
	metrics_path: /federate
	params:
	  'match[]':
	  - '{job="prometheus"}'
	  - '{__name__=~"job:.*"}'
	  - '{__name__=~"node:.*"}'	
    static_configs:
      - targets: ['192.168.150.152:9090']	

  - job_name: prometheus-federate-150.153
    scrape_interval: 10s
	honor_labels: true
	metrics_path: /federate
	params:
	  'match[]':
	  - '{job="prometheus"}'
	  - '{__name__=~"job:.*"}'
	  - '{__name__=~"node:.*"}'	
    static_configs:
      - targets: ['192.168.150.153:9090']	
#Prometheus验证数据及验证指标数据

四、Prometheus存储系统

Prometheus有着非常高效的时间序列数据存储方法,每个采样数据仅仅占用3.5byte左右空间,上百万条时间序列,30秒间隔,保留60天,大概200多G空间(引用官方PPT)。

1、本地存储

默认情况下,prometheus将采集到的数据存储在本地的TSDB数据库中,路径默认为prometheus安装目录的data目录,数据写入过程为先把数据写入wal日志并放在内存,
然后2小时后将内存数据保存至一个新的block块,同时再把新采集的数据写入内存并在2小时后再保存至一个新的block块,以此类推。

block简介:
每个block为一个data目录中以01开头的存储目录,如下:

~#Is-1/apps/prometheus/data/
total4
drwxr-xr-x 3 root root 68 Dec 24 05:00 01FQNCYZ0BPFA8AQDDZM1C5PRN  #block 
drwxr-xr-x 3 root root 68 Dec 27 09:10 01FQXJESTQXVBEPM857SF9XBX7  #block 
drwxr-xr-x 3 root root 68 Dec 28 07:20 01FQZYJJ605MEQ7KHBBM09PBVH  #block 
drwxr-xr-x 3 root root 68 Dec 28 07:20 01FQZYJJABE4JGM85TXJ25WESQ  #block

block特性:
block会压缩、合并历史数据块,以及删除过期的块,随着压缩、合并,block的数量会减少,在压缩过程中会发生三件事:定期执行压缩、合并小的block到大的block、清理过期的块。
每个块有4部分组成:

~#tree/apps/prometheus/data/01FQNCYZ0BPFA8AQDDZM1C5PRN/
/apps/prometheus/data/01FQNCYZOBPFA8AQDDZM1C5PRN/
|——chunks
|    |——000001  #数据目录,每个大小为512MB超过会被切分为多个
|——index  #索引文件,记录存储的数据的索引信息,通过文件内的几个表来查找时序数据
|——meta.json  #block元数据信息,包含了样本数、采集数据数据的起始时间、压缩历史
|——tombstones  #逻辑数据,主要记载删除记录和标记要测除的内容,测除标记,可在查询块时排除样本。

本地存储配置参数:
–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动态加载配置功能

2、远端存储–VictoriaMetrics

https://github.com/VictoriaMetrics/VictoriaMetrics https://docs.victoriametrics.com/Single-server-VictoriaMetrics.html

(1)单机版部署:

#tar xvf victoria-metrics-amd64-v1.71.0.tar.gz
参数:
-httpListenAddr=0.0.0.0:8428  #监听地址及端口
-storageDataPath  #VictoriaMetrics 将所有数据存储在此目录中,默认为执行启动victoria的当前目录下的victoria-metrics-data目录中。
-retentionPeriod  #存储数据的保留,较旧的数据会自劫删除,默认保留期为1个月,默认单位为m(月),支持的单位有h(hour),d(day),w(week),y(year)。

#mv victoria-metrics-prod /usr/local/bin/

service启动文件:
#cat/etc/systemd/system/victoria-metrics-prod.service
[Unit]
Description=For Victoria-metrics-prod Service
After=network.target

[Service]
ExecStart=/usr/local/bin/victoria-metrics-prod -httpListenAddr=0.0.0.0:8428
-storageDataPath=/data/victoria-retentionPeriod=3

[Instal]
WantedBy=multi-user.target

#systemctl daemon-reload && systemctl restart victoria-metrics-prod.service && systemctl enable victoria-metrics-prod.service

#验证web页面
192.168.150.167:8448

prometheus配置:
#通过VictoriaMetrics配置远端存储
remote_write:
  - url: http://192.168.150.167:8448/api/v1/write

验证VictoriaMetrics数据:
192.168.150.167:8448

grafana设置:
添加数据源:类型为prometheus,地址及端口为VictoriaMetrics:
导入指定模板:8919
验证grafana数据

(2)docker-compose部署
https://github.com/VictoriaMetrics/VictoriaMetrics/tree/cluster/deployment/docker

#git clone https://github.com/VictoriaMetrics/VictoriaMetrics.git
#cd VictoriaMetrics/deployment/docker/
#ll
total 56
-rw-r--r-- 1 root root 61    Dec 29 10:48 alertmanager.yml
-rw-r--r-- 1 root root 16487 Dec 29 10:48 alerts.yml
drwxr-xr-x 2 root root 4096  Dec 29 10:48 base
drwxr-xr-x 2 root root 4096  Dec 29 10:48 builder
-rw-r--r-- 1 root root 2807  Dec 29 10:48 docker-compose.yml
-rw-r--r-- 1 root root 5312  Dec 29 10:48 Makefile
-rw-r--r-- 1 root root 298   Dec 29 10:48 prometheus.yml
drwxr-xr-x 4 root root 4096  Dec 29 10:48 provisioning
-rw-r--r-- 1 root root 1488  Dec 29 10:48 README.md
#docker-compose up -d
验证web界面:
192.168.150.167:8448

(3)集群版部署
8.2.3.1：组件介绍:

vminsert #写入组件（写）,vminsert 负责接收数据写入并根据对度量名称及其所有标签的一致hash结果将数据分散写入不同的后端Vmstorage节点之间vmstorage,vminsert默认端口8480
vmstorage #存储原始数据并返回给定时间范围内给定标签过滤器的查询数据,默认端口8482
vmselect #查询组件（读）,连接vmstorage,默认端口8481
其它可选组件:
vmagent #是一个很小但功能强大的代理,它可以从nodeexporter各种来源收集度量数据,并将它们存储在VictoriaMetrics 或任何其他支持远程写入协议的
与prometheus兼容的存储系统中,有替代prometheus server的意向。

vmalert:替换prometheus server,以VictoriaMetrics为数据源,基于兼容prometheus的告警规则,判断数据是否异常,并将产生的通知发送给alertermanager 
Vmgateway:读写VictoriaMetrics数据的代理网关,可实现限速和访问控制等功能,目前为企业版组件
vmctl: VictoriaMetrics的命令行工具,目前主要用于将prometheus、opentsdb等数据源的数据迁移到VictoriaMetrics。

8.2.3.2：部署集群:
分别在各个VictoriaMetrics服务器进行安装配置:

#tar xvf victoria-metrics-amd64-v1.71.0-cluster.tar.gz
vminsert-prod
vmselect-prod
vmstorage-prod
#mv vminsert-prod vmselect-prod vmstorage-prod /usr/local/bin/
主要参数:
-httpListenAddr string
Address to listen for http connections（default":8482"）
-vminsertAddr string
TCP address to accept connections from vminsert services（default":8400"）
-vmselectAddr string
TCP address to accept connections from vmselect services（default":8401"）

#部署vmstorage-prod组件:
负责数据的持久化,监听端口:API8482,数据写入端口:8400,数据读取端口:8401。
#vim/etc/systemd/system/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
[Instal]
WantedBy=multi-user.target

#systemctl restart vmstorage.service
#systemctl enable vmstorage.service
#systemctl status vmstorage.service

#scp /etc/systemd/system/vmstorage.service 172.31.2.182:/etc/systemd/system/vmstorage.service
#scp /etc/systemd/system/vmstorage.service 172.31.2.183:/etc/systemd/system/vmstorage.service
#scp /usr/local/bin/vm* 172.31.2.182:/usr/local/bin/
#scp /usr/local/bin/vm* 172.31.2.183:/usr/local/bin/

182:
#systemctl daemon-reload && systemctl start vmstorage && systemctl enable vmstorage
183:
#systemctl daemon-reload && systemctl start vmstorage && systemctl enable vmstorage


#部署vminsert-prod组件:
接收外部的写请求,默认端口8480。
#vim/etc/systemd/system/vminsert.service
[Unit]
Description=Vminsert Server 
After=network.target
[Service]
Restart=on-failure 
WorkingDirectory=/tmp 
ExecStart=/usr/local/bin/vminsert-prod -httpListenAddr:8480 -storageNode=172.31.2.181:8400,172.31.2.182:8400,172.31.2.183:8400
[Instal]
WantedBy=multi-user.target

#systemctl daemon-reload && systemctl restart vminsert && systemctl enable vminsert
#scp /etc/systemd/system/vminsert.service 172.31.2.182:/etc/systemd/system/vminsert.service
#scp /etc/systemd/system/vminsert.service 172.31.2.183:/etc/systemd/system/vminsert.service


#部署vmselect-prod组件:
负责接收外部的读请求,默认端口8481。
#vim/etc/systemd/system/vmselect.service
[Unit]
Description=Vminsert Server 
After=network.target
[Service]
Restart=on-failure 
WorkingDirectory=/tmp 
ExecStart=/usr/local/bin/vmselect-prod -httpListenAddr:8481 -storageNode=172.31.2.181:8401,172.31.2.182:8401,172.31.2.183:8401
Instal]
WantedBy=multi-user.target

#systemctl daemon-reload && systemct restart vmselect && systemctl enable vmselect
#scp /etc/systemd/system/vmselect.service 172.31.2.183:/etc/systemd/system/vmselect.service
#scp /etc/systemd/system/vmselect.service 172.31.2.183:/etc/systemd/system/vmselect.service
182:
#systemctl daemon-reload && systemctl restart vmselect && systemctl enable vmselect
183:
#systemctl daemon-reload && systemctl restart vmselect && systemctl enable vmselect


#验证服务端口：
172.31.2.181：
#curl http://172.31.2.181:8480/metrics
#curl http://172.31.2.181:8481/metrics
#curl http://172.31.2.181:8482/metrics
172.31.2.182：           
#curl http://172.31.2.182:8480/metrics
#curl http://172.31.2.182:8481/metrics
#curl http://172.31.2.182:8482/metrics
172.31.2.183：           
#curl http://172.31.2.183:8480/metrics
#curl http://172.31.2.183:8481/metrics
#curl http://172.31.2.183:8482/metrics

8.2.3.3：prometheus 配置远程写入：

#单机写入
#remote_write：
#  -url:http://172.31.7.109:8428/api/v1/write
#集群写入
remote_write：
  -url:http://172.31.2.181:8480/insert/0/prometheus
  -url:http://172.31.2.182:8480/insert/0/prometheus
  -url:http://172.31.2.183:8480/insert/0/prometheus

8.2.3.4：grafana设置
https://github.com/VictoriaMetrics/VictoriaMetrics#grafana-setup

#添加数据源
导入模板号:13824
#验证数据

(4)开启数据复制
https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html#replication-and-data-safety 默认情况下,数据被vminsert的组件基于hash算法分别将数据持久化到不同的vmstorage节点,可以启用vminsert组件支持的-replicationFactor=N复制功能,
将数据分别在各节点保存一份完整的副本以实现数据的高可用。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。