Prometheus 安装配置:Consul 自动发现与 Thanos Sidecar 持久化

Prometheus 安装配置:Consul 自动发现与 Thanos Sidecar 持久化

概述

Prometheus 是云原生监控体系中常用的时序数据库和指标采集组件。它本身负责拉取指标、存储时序数据和执行 PromQL 查询;在服务数量较多、实例经常变化的环境中,可以配合 Consul 做服务发现,避免手工维护大量 targets;如果需要长期保存历史数据,则可以接入 Thanos Sidecar,将本地 TSDB 数据块上传到对象存储或共享存储中。

本文记录一套 Prometheus + Consul 服务发现 + Thanos Sidecar 的基础安装配置方式,适合中小规模运维监控场景参考。

1. Prometheus 启动参数

Prometheus 可以直接使用二进制文件启动。示例安装目录为 /opt/monitor/prometheus

bash 复制代码
/opt/monitor/prometheus/prometheus \
  --config.file=prometheus.yml \
  --web.enable-lifecycle \
  --storage.tsdb.max-block-duration=2h \
  --storage.tsdb.min-block-duration=2h

几个关键参数说明如下:

参数 说明
--config.file 指定 Prometheus 配置文件
--web.enable-lifecycle 允许通过 HTTP 接口热加载配置
--storage.tsdb.max-block-duration TSDB 最大块时长
--storage.tsdb.min-block-duration TSDB 最小块时长

如果后续需要配合 Thanos Sidecar 上传历史数据,建议将 TSDB block 时长固定为 2 小时。这也是 Thanos 官方常见部署方式中的推荐配置。

配置修改后,可以通过下面的接口热加载:

bash 复制代码
curl -X POST http://127.0.0.1:9090/-/reload

前提是启动时已经加上 --web.enable-lifecycle

2. Consul 服务发现配置

Prometheus 支持通过 consul_sd_configs 从 Consul 自动发现服务。服务注册到 Consul 后,Prometheus 根据服务名、标签、地址等元数据筛选目标并生成指标抓取配置。

2.1 Netdata 服务发现示例

下面示例用于发现 Netdata 节点,并从 Consul tag 中提取组织、环境等标签:

yaml 复制代码
scrape_configs:
  - job_name: 'netdata-example'
    consul_sd_configs:
      - server: 'consul.example.local:8500'
        services: []
    relabel_configs:
      - source_labels: [__meta_consul_service]
        regex: 'app-(.+)-netdata'
        action: keep
      - source_labels: [__meta_consul_tags]
        regex: ',(.+),(.+),(.+),'
        target_label: org
        replacement: $1
      - source_labels: [__meta_consul_tags]
        regex: ',(.+),(.+),(.+),'
        target_label: env
        replacement: $2
      - source_labels: [__meta_consul_service_address]
        regex: (.+)
        target_label: ip
        replacement: $1
    metrics_path: '/api/v1/allmetrics'

这里的核心逻辑是:

配置 作用
consul_sd_configs.server Consul 服务地址
services: [] 不限制服务名,先拉取全部服务再通过 relabel 过滤
__meta_consul_service Consul 中注册的服务名
action: keep 只保留匹配规则的服务
__meta_consul_tags 从 Consul tags 中提取业务标签
metrics_path Netdata 指标接口路径

2.2 Windows Exporter 服务发现示例

Windows 节点可以通过 windows_exporter 暴露指标,再由 Prometheus 自动发现:

yaml 复制代码
scrape_configs:
  - job_name: 'winexporter-example'
    consul_sd_configs:
      - server: 'consul.example.local:8500'
        services: []
    relabel_configs:
      - source_labels: [__meta_consul_service]
        regex: 'app-(.+)-winexporter'
        action: keep
      - source_labels: [__meta_consul_tags]
        regex: ',(.+),(.+),(.+),'
        target_label: org
        replacement: $1
      - source_labels: [__meta_consul_tags]
        regex: ',(.+),(.+),(.+),'
        target_label: env
        replacement: $2
      - source_labels: [__meta_consul_service_address]
        regex: (.+)
        target_label: ip
        replacement: $1

如果服务命名规范比较稳定,建议在 Consul 注册阶段就约定好服务名和 tag 格式。这样 Prometheus 侧只需要维护少量通用 relabel 规则。

3. Thanos Sidecar 配置

Prometheus 本地 TSDB 更适合保存短周期数据。如果需要长期存储、跨集群查询或统一查询入口,可以接入 Thanos。

Thanos Sidecar 运行在 Prometheus 旁边,主要负责两件事:

  1. 读取 Prometheus 本地 TSDB 数据块。
  2. 将历史 block 上传到对象存储或共享存储。

启动命令示例:

bash 复制代码
/opt/monitor/thanos/thanos sidecar \
  --tsdb.path /opt/monitor/prometheus/data/ \
  --prometheus.url http://localhost:9090 \
  --objstore.config-file thanos_bucket_file.yml \
  --log.level info

参数说明:

参数 说明
--tsdb.path Prometheus 数据目录
--prometheus.url Prometheus HTTP 地址
--objstore.config-file Thanos 对象存储配置文件
--log.level 日志级别,生产环境通常使用 info

4. 对象存储配置示例

测试环境可以使用本地文件系统模拟对象存储:

yaml 复制代码
type: FILESYSTEM
config:
  directory: "/opt/monitor/thanos/bucket"

生产环境更常见的是使用 S3 兼容对象存储,例如 MinIO、AWS S3、阿里云 OSS 等。以 S3 兼容存储为例:

yaml 复制代码
type: S3
config:
  bucket: "prometheus-thanos"
  endpoint: "s3.example.com"
  access_key: "your_access_key"
  secret_key: "your_secret_key"
  insecure: false

实际使用时不要把 access key 和 secret key 直接提交到代码仓库,建议通过配置管理、密钥管理系统或独立权限文件维护。

5. 常见注意事项

  1. Prometheus 启动 Thanos Sidecar 前,建议固定 TSDB block 时长为 2 小时。
  2. Consul 服务命名和 tag 格式要提前约定,否则 relabel 规则会越来越复杂。
  3. --web.enable-lifecycle 方便热加载配置,但需要配合网络访问控制,避免被未授权调用。
  4. Thanos Sidecar 的 --tsdb.path 必须和 Prometheus 实际数据目录一致。
  5. 生产环境不要使用 debug 日志级别长期运行,避免日志量过大。
  6. 对象存储账号应只授予必要 bucket 的读写权限,避免权限过大。

总结

Prometheus 单独部署并不复杂,真正需要提前设计的是服务发现和长期存储。

在实例数量较少时,可以直接静态配置 targets;当服务数量增加、节点变动频繁后,Consul 服务发现能显著降低维护成本;当本地磁盘无法满足历史数据保存需求时,再通过 Thanos Sidecar 接入对象存储,实现更长周期的数据保留和后续扩展。

相关推荐
溜达的大象13 小时前
Prometheus怎么监控没有公网IP的服务器?Node Exporter远程采集实战
服务器·tcp/ip·prometheus
Livia要学习6 天前
Prometheus架构解析
prometheus
云烟成雨TD7 天前
Micrometer 系列【63】统一观测:基于 Spring Boot 的生产级演示案例 | 基于 OTLP 集成 Prometheus + Jaeger
spring boot·云原生·prometheus
江南风月9 天前
如何使用WGCLOUD实现智能运维
运维·zabbix·运维开发·prometheus
凤山老林11 天前
可观测性落地:Spring Boot 3.x + Actuator + Prometheus + Grafana 监控体系搭建
spring boot·grafana·prometheus
企鹅郁金香13 天前
部署搭建 Prometheus 和 Grafana教程
eureka·grafana·prometheus
云边有个稻草人14 天前
Ubuntu部署Prometheus与Alertmanager:服务接入和远程监控
数据库·ubuntu·prometheus
雨辰AI15 天前
K8s 国产数据库慢 SQL 自动监控|Prometheus+Grafana 可视化全落地
数据库·sql·安全·容器·kubernetes·grafana·prometheus
lee_curry16 天前
RuoYi Cloud:Gateway、Auth、System 接入 Prometheus JVM 监控,并练习多副本、滚动升级和故障恢复
jvm·gateway·prometheus