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 旁边,主要负责两件事:
- 读取 Prometheus 本地 TSDB 数据块。
- 将历史 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. 常见注意事项
- Prometheus 启动 Thanos Sidecar 前,建议固定 TSDB block 时长为 2 小时。
- Consul 服务命名和 tag 格式要提前约定,否则 relabel 规则会越来越复杂。
--web.enable-lifecycle方便热加载配置,但需要配合网络访问控制,避免被未授权调用。- Thanos Sidecar 的
--tsdb.path必须和 Prometheus 实际数据目录一致。 - 生产环境不要使用
debug日志级别长期运行,避免日志量过大。 - 对象存储账号应只授予必要 bucket 的读写权限,避免权限过大。
总结
Prometheus 单独部署并不复杂,真正需要提前设计的是服务发现和长期存储。
在实例数量较少时,可以直接静态配置 targets;当服务数量增加、节点变动频繁后,Consul 服务发现能显著降低维护成本;当本地磁盘无法满足历史数据保存需求时,再通过 Thanos Sidecar 接入对象存储,实现更长周期的数据保留和后续扩展。