Prometheus之存储
1. 本地存储
1. 默认采用tsdb时序数据库。默认存储数据为15天。
2. 可通过启动添加脚本来修改。
--storage.tsdb.path:数据存储位置,默认是data目录。 --storage.tsdb.retention.time:保留时间,默认是15天,过15天之后,就删除。该配置会覆盖--storage.tsdb.retention的值。 --storage.tsdb.retention.size:要保留的块的最大字节数。最早的数据会首先被删除。默认为0或禁用。此标志是实验性的,可以在将来的版本中进行更改。支持的单位: KB,MB,GB,PB。例如: "512MB"
3. prometheus的本地存储目录结构
4. 对本地磁盘容量规划公式
needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample
保留时间(retention_time_seconds)和样本大小(bytes_per_sample)不变的情况下,如果想减少本地磁盘的容量需求,只能通过减少每秒获取样本数(ingested_samples_per_second)的方式。因此有两种手段,一是减少时间序列的数量,二是增加采集样本的时间间隔。考虑到Prometheus会对时间序列进行压缩,因此减少时间序列的数量效果更明显。
2. 远程存储
Prometheus的本地存储设计可以减少其自身运维和管理的复杂度,同时能够满足大部分用户监控规模的需求。但是本地存储也意味着Prometheus无法持久化数据,无法存储大量历史数据,同时也无法灵活扩展和迁移。为了保持Prometheus的简单性,Prometheus并没有尝试在自身中解决以上问题,而是通过定义两个标准接口(remote_write/remote_read),让用户可以基于这两个接口将数据保存到任意第三方的存储服务中,这种方式在Promthues中称为远程存储(Remote Storage)。
1. Remote Write
用户可以在Prometheus配置文件中指定Remote Write(远程写)的URL地址,比如指向influxdb中,也可指向消息队列等。一旦设置了该配置项,Prometheus将样本数据通过HTTP的形式发送给适配器(Adaptor)。而用户则可以在适配器中对接外部任意服务。外部服务可以是真正的存储系统, 公有云存储服务, 也可以是消息队列等任意形式。
2. Remote Read
Promthues的Remote Read(远程读)也通过了一个适配器实现。Promthues的Remote Read(远程读)的流程当中,当用户发起查询请求后(也就是说Remote Read只在数据查询时有效),Promthues将向remote_read中配置的URL发起查询请求(matchers,ranges),接收Promthues的原始样本数据。Adaptor根据请求条件从第三方存储服务中获取响应的数据。同时将数据转换为Promthues的原始样本数据返回给Prometheus Server。当获取到样本数据后,Promthues在本地使用PromQL对样本数据进行二次处理。注意:即使使用了远程读,Prometheus中对于规则文件的处理,以及Metadata API的处理都只在本地完成。
3. prometheus配置文件
remote_write: url: <string> [ remote_timeout: <duration> | default = 30s ] write_relabel_configs: [ - <relabel_config> ... ] basic_auth: [ username: <string> ] [ password: <string> ] [ bearer_token: <string> ] [ bearer_token_file: /path/to/bearer/token/file ] tls_config: [ <tls_config> ] [ proxy_url: <string> ] remote_read: url: <string> required_matchers: [ <labelname>: <labelvalue> ... ] [ remote_timeout: <duration> | default = 30s ] [ read_recent: <boolean> | default = false ] basic_auth: [ username: <string> ] [ password: <string> ] [ bearer_token: <string> ] [ bearer_token_file: /path/to/bearer/token/file ] [ <tls_config> ] [ proxy_url: <string> ]
一般使用Influxdb作为Remote Storage。目前Prometheus社区也提供了部分对于第三方数据库的Remote Storage支持,如influxDB,OpenTSDB,PostgreSQL等。
3. Prometheus联邦集群
1. 部署Prometheus联邦集群
1. 环境
10.0.0.3 Prometheus
10.0.0.5 Prometheus联邦
10.0.0.7 Prometheus联邦
2. 三台都安装Prometheus
3. 10.0.0.3配置Prometheus.yml,添加联邦服务器地址
- job_name: 'prometheus-federate-0.7' scrape_interval: 10s honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' - '{__name__=~"job:.*"}' - '{__name__=~"node.*"}' static_configs: - targets: - '10.0.0.5:9090' - job_name: 'prometheus-federate-0.5' scrape_interval: 10s honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' - '{__name__=~"job:.*"}' - '{__name__=~"node.*"}' static_configs: - targets: - '10.0.0.7:9090'
4. 10.0.0.3重启服务systemctl restart prometheus.service
2. 功能分区
当你的监控大到单个Prometheus Server无法处理的情况下,我们可以在各个数据中心中部署多个Prometheus Server实例。每一个Prometheus Server实例只负责采集当前数据中心中的一部分任务(Job),例如可以将应用监控和主机监控分离到不同的Prometheus实例当中。假如监控采集任务的规模继续增大,通过功能分区的方式可以进一步细化采集任务。对于中心Prometheus Server只需要从这些实例中聚合数据即可。
3. 水平扩展
水平扩展可以将统一任务的不同实例的监控数据采集任务划分到不同的Prometheus实例。
4. 高可用方案
1. 基本HA
用户只需要部署多套Prometheus Server实例,并且采集相同的Exporter目标即可。基本的HA模式只能确保Promthues服务的可用性问题,但是不解决Prometheus Server之间的数据一致性问题以及持久化问题(数据丢失后无法恢复),也无法进行动态的扩展。因此这种部署方式适合监控规模不大,Promthues Server也不会频繁发生迁移的情况,并且只需要保存短周期监控数据的场景。
2. 基本HA+远程存储
在基本HA模式的基础上通过添加Remote Storage存储支持,将监控数据保存在第三方存储服务上。在保证Promthues服务可用性的基础上,同时确保了数据的持久化,当Promthues Server发生宕机或者数据丢失的情况下,可以快速的恢复。 同时Promthues Server可能很好的进行迁移。因此,该方案适用于用户监控规模不大,但是希望能够将监控数据持久化,同时能够确保Promthues Server的可迁移性的场景。
3. 基本HA+远程存储+联邦集群
当单台Promthues Server无法处理大量的采集任务时,用户可以考虑基于Prometheus联邦集群的方式将监控采集任务划分到不同的Promthues实例当中,即在任务级别进行功能分区。这种方案适用于两种场景:
场景一:单数据中心 + 大量的采集任务
这种场景下Promthues的性能瓶颈主要在于大量的采集任务,因此用户需要利用Prometheus联邦集群的特性,将不同类型的采集任务划分到不同的Promthues子服务中,从而实现功能分区。
场景二:多数据中心
这种模式也适合与多数据中心的情况,当Promthues Server无法直接与数据中心中的Exporter进行通讯时,在每一个数据中部署一个单独的Promthues Server负责当前数据中心的采集任务是一个不错的方式。这样可以避免用户进行大量的网络配置,只需要确保主Promthues Server实例能够与当前数据中心的Prometheus Server通讯即可。 中心Promthues Server负责实现对多数据中心数据的聚合。
5. VictoriaMetrics
1. 简介
VM是一个支持高可用,经济高效且可扩展的监控解决方案和时间序列数据库,可用于prometheus的远程存储。
2. 优点
- 对外支持 Prometheus 相关的 API,可以直接用于 Grafana 作为 Prometheus 数据源使用(可以直接使用VictoriaMetrics 对接grafana)
- 指标数据摄取和查询具备高性能和良好的可扩展性,性能比 InfluxDB 和 TimescaleDB 高出 20 倍
- 在处理高基数时间序列时,内存方面也做了优化,比 InfluxDB 少 10x 倍,比 Prometheus、Thanos 或 Cortex 少 7 倍
- 高性能的数据压缩方式,与 TimescaleDB 相比,可以将多达 70 倍的数据点存入有限的存储空间,与 Prometheus、Thanos 或 Cortex 相比,所需的存储空间减少 7 倍
- 它针对具有高延迟 IO 和低 IOPS 的存储进行了优化
- 提供全局的查询视图,多个 Prometheus 实例或任何其他数据源可能会将数据摄取到 VictoriaMetrics
- 操作简单
- VictoriaMetrics 由一个没有外部依赖的小型可执行文件组成
- 所有的配置都是通过明确的命令行标志和合理的默认值完成的
- 所有数据都存储在 - storageDataPath 命令行参数指向的目录中
- 可以使用 vmbackup/vmrestore 工具轻松快速地从实时快照备份到 S3 或 GCS 对象存储中
- 支持从第三方时序数据库获取数据源
- 由于存储架构,它可以保护存储在非正常关机(即 OOM、硬件重置或 kill -9)时免受数据损坏
- 同样支持指标的 relabel 操作
3. Prometheus使用远程存储victormetrics(单机版)
1. 下载并配置
[root@k8s-node2 apps]# wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.80.0/victoria-metrics-linux-amd64-v1.80.0.tar.gz [root@k8s-node2 apps]# tar -xvf victoria-metrics-linux-amd64-v1.80.0.tar.gz [root@k8s-node2 apps]# cp victoria-metrics-prod /usr/local/bin [root@k8s-node2 apps]# vim /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 [Install] WantedBy=multi-user.target [root@k8s-node2 apps]# systemctl restart victoria-metrics-prod.service [root@k8s-node2 apps]# systemctl enable victoria-metrics-prod.service
2. 测试访问
浏览器直接访问IP:8428
3. 修改prometheus.yml文件并重启
remote_write: - url: http://10.211.55.22:8428/api/v1/write
4. 登录VictoriaMetrics VMUI查看是否有数据
5. 使用Grafana展示数据
导入模板
4. Prometheus使用远程存储victormetrics(集群版)
1. 下载并配置
[root@VM-0-15-centos ~]# wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.80.0/victoria-metrics-linux-amd64-v1.80.0-cluster.tar.gz [root@VM-0-15-centos ~]# tar xvf victoria-metrics-linux-amd64-v1.80.0-cluster.tar.gz [root@VM-0-15-centos ~]# mv vminsert-prod vmselect-prod vmstorage-prod /usr/local/bin/
2. 三台都配置
[root@VM-0-3-centos ~]# 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 [Install] WantedBy=multi-user.target [root@VM-0-3-centos ~]# 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=192.168.0.16:8400,192.168.0.3:8400,192.168.0.15:8400 [Install] WantedBy=multi-user.target [root@VM-0-3-centos ~]# vim /etc/systemd/system/vmselect.service [Unit] Description=Vmselect Server After=network.target [Service] Restart=on-failure WorkingDirectory=/tmp ExecStart=/usr/local/bin/vmselect-prod -httpListenAddr :8481 -storageNode=192.168.0.16:8401,192.168.0.3:8401,192.168.0.15:8401 [Install] WantedBy=multi-user.target
3. 重启服务,设置开机启动
[root@VM-0-3-centos ~]# systemctl restart vmstorage.service [root@VM-0-3-centos ~]# systemctl enable vmstorage.service [root@VM-0-3-centos ~]# systemctl restart vminsert.service [root@VM-0-3-centos ~]# systemctl enable vminsert.service [root@VM-0-3-centos ~]# systemctl restart vmselect.service [root@VM-0-3-centos ~]# systemctl enable vmselect.service
4. 编辑prometheus.yml配置文件,并重启
remote_write: - url: http://192.168.0.16:8480/insert/0/prometheus - url: http://192.168.0.3:8480/insert/0/prometheus - url: http://192.168.0.15:8480/insert/0/prometheus
5. 在grafana中添加数据源,可以使用haproxy做一个vip
其他内容与单机版相同