云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载Thanos 是一组可组合的组件能够将多个 Prometheus 实例整合为高可用的监控体系并在对象存储允许的前提下提供近乎无限的存储容量。Prometheus Operator 在Prometheus与ThanosRuler两类自定义资源CRD中内置了对 Thanos 的一等支持前者负责在每个 Prometheus Pod 内注入 Thanos Sidecar 容器后者则直接管理独立的 Thanos Ruler 集群。读完本文你将掌握如何在PrometheusCR 中开启 Thanos Sidecar、将 TSDB 数据块备份到对象存储、理解新旧版本压缩行为差异以及如何用ThanosRulerCR 部署跨集群的规则评估实例。Thanos 与 Prometheus Operator 的职责边界Thanos 由 Sidecar、Querier、Receiver、Compactor、Store Gateway 等组件构成。在与 Prometheus Operator 集成时Operator 只负责管理其中两类组件Thanos Sidecar由Prometheus自定义资源驱动作为容器注入到 Prometheus Pod 内部。它一方面将本地 Prometheus 的 StoreAPI 暴露给 Thanos 查询体系另一方面可选地把 TSDB 数据块上传到对象存储Thanos Ruler由ThanosRuler自定义资源驱动部署独立的 Ruler 实例用于跨集群评估 PromQL 记录规则与告警规则。而 Querier、Receiver、Compactor、Store Gateway 等其余组件需要独立于 Operator 部署。官方 kube-thanos 项目提供了这些组件的部署起点Operator 不参与其生命周期管理。在 Prometheus CR 中启用 Thanos SidecarPrometheusCRD 通过spec.thanos字段控制 Sidecar 的注入。只要将thanos设置为非空值最简形式是只给一个合法的 Thanos 容器镜像地址Operator 就会在生成的 StatefulSet Pod 中加入名为thanos-sidecar的容器# Prometheus 自定义资源片段 ... spec: ... thanos: image: quay.io/thanos/thanos:v0.28.1 ...spec.thanos对应源码中的ThanosSpec结构体见 pkg/apis/monitoring/v1/prometheus_types.go除image外还支持以下常用字段字段说明imageThanos 容器镜像地址一旦指定即覆盖baseImage/tag/sha的组合拼装仍需配合version让 Operator 获知具体版本versionThanos 版本Operator 依据它决定生成何种 StatefulSet 与配置参数缺省时按 Operator 发布时的最新上游版本处理baseImage/tag/sha已废弃推荐统一使用image完整镜像引用resourcesSidecar 容器的资源 requests/limitsobjectStorageConfig引用 Kubernetes Secret 中的对象存储配置用于上传 TSDB 块objectStorageConfigFile优先级更高objectStorageConfigFile直接指定对象存储配置文件的挂载路径优先于objectStorageConfiggrpcListenLocal/httpListenLocal为 true 时 Sidecar 的 gRPC/HTTP 端点改为监听 loopback 接口而非 Pod IP旧的listenLocal已废弃tracingConfig/tracingConfigFile追踪配置实验性功能文件形式优先级更高grpcServerTlsConfig提供 StoreAPI 的 gRPC 服务端 TLS 参数logLevel/logFormat日志级别debug/info/warn/error与格式logfmt/jsonminTimeStoreAPI 服务的时间范围下限支持 RFC3339 常量或相对时长如-1d、2h45mblockSizeTSDB 块时长默认2h与上游 Prometheus 默认值一致改动会影响整体内存与 Compactor 效率readyTimeout/getConfigInterval/getConfigTimeoutSidecar 等待 Prometheus 就绪、拉取配置的间隔与超时volumeMounts/additionalArgs追加卷挂载或透传额外的 CLI 参数如隐藏 flag仓库自带的 example/thanos/prometheus.yaml 展示了一个双副本 Prometheus 与 Thanos 集成的最小实例仅通过version: v0.42.4即可让 Operator 拉取对应版本镜像apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: labels: prometheus: self name: self namespace: default spec: replicas: 2 ruleSelector: matchLabels: prometheus: k8s role: prometheus-rulefiles serviceMonitorSelector: matchLabels: app.kubernetes.io/name: prometheus thanos: version: v0.42.4配置 Thanos 对象存储要让 Sidecar 将 TSDB 数据块上传到对象存储需要先准备一份 Thanos 格式的存储配置文件再放入 Kubernetes Secret。配置格式与示例可参考 Thanos 官方 storage 文档下面是一个 S3 兼容存储的例子type: s3 config: bucket: thanos endpoint: ams3.digitaloceanspaces.com access_key: XXX secret_key: XXX假设将上述内容保存为/tmp/thanos-config.yaml可用如下命令在monitoring命名空间创建名为thanos-objstore-config的 Secretkubectl -n monitoring create secret generic thanos-objstore-config --from-filethanos.yaml/tmp/thanos-config.yaml随后在PrometheusCR 的thanos字段中通过objectStorageConfig引用该 Secretkey对应 Secret 内的键名name对应 Secret 名称... spec: ... thanos: image: quay.io/thanos/thanos:v0.28.1 objectStorageConfig: key: thanos.yaml name: thanos-objstore-config ...这样 Operator 就会把 Secret 内容挂载为 Sidecar 的--objstore.config-fileSidecar 会将 Prometheus 每 2 小时生成的新数据块持续上传至对象存储。若你更倾向于在 Sidecar 容器内直接指定配置文件路径可改用objectStorageConfigFile字段该字段在源码中明确标注优先级高于objectStorageConfig见 pkg/apis/monitoring/v1/prometheus_types.go。压缩行为的两种模式旧行为与新协调机制启用对象存储后本地 Prometheus 压缩与 Sidecar 上传之间的协调方式随版本而异这是生产环境最容易踩坑的点务必注意旧模式Prometheus v3.9.0 或 Thanos Sidecar v0.42.0objectStorageConfig生效会禁用本地 Prometheus 压缩Operator 将--storage.tsdb.min-block-duration与--storage.tsdb.max-block-duration都设为2h或blockSize指定值。此时必须由全局唯一的 Thanos Compactor在对象存储层面完成压缩本地不再做压缩新模式Prometheus v3.9.0 且 Thanos Sidecar v0.42.0Operator保留本地压缩改为通过 Sidecar 的 shipper 元数据文件协调上传Prometheus 以--storage.tsdb.delay-compact-file.path启动Sidecar 则以--shipper.meta-file-name与--shipper.ignore-unequal-block-size启动Prometheus 只会压缩已经上传到对象存储的 level-1 数据块从而规避关闭本地压缩带来的查询与内存开销。如需强制退回旧行为可在PrometheusCR 中设置spec.disableCompaction: true。上述逻辑在源码中有完整的映射compactionModeFor根据 Prometheus 与 Thanos 版本计算压缩模式compactionModeDisabled分支写入min/max-block-duration参数compactionModeDelayed分支写入delay-compact-file.path见 pkg/prometheus/server/statefulset.goSidecar 侧的两个 shipper 参数则在 pkg/prometheus/server/statefulset.go 中追加并由 pkg/prometheus/server/statefulset_test.go 的TestCompactionMode系列用例逐一验证延迟模式下压缩参数保持存在且 shipper 参数成对出现显式禁用压缩时则恢复旧行为。部署 ThanosRuler跨集群规则评估Thanos Ruler 中强制校验若两个查询字段都为空直接返回错误拒绝生成 StatefulSet。原文档给出的完整示例... apiVersion: monitoring.coreos.com/v1 kind: ThanosRuler metadata: name: thanos-ruler-demo labels: example: thanos-ruler namespace: monitoring spec: image: quay.io/thanos/thanos:v0.28.1 ruleSelector: matchLabels: role: my-thanos-rules queryEndpoints: - dnssrv_http._tcp.my-thanos-querier.monitoring.svc.cluster.local alertmanagersConfig: key: alertmanager-configs.yaml name: thanosruler-alertmanager-config仓库中的 example/thanos/thanos-ruler.yaml 则演示了queryConfig的写法apiVersion: monitoring.coreos.com/v1 kind: ThanosRuler metadata: labels: app.kubernetes.io/name: thanos-ruler name: thanos-ruler namespace: default spec: image: quay.io/thanos/thanos:v0.42.4 queryConfig: key: query.yaml name: thanos-ruler ruleSelector: matchLabels: role: thanos-example version: v0.42.4ThanosRulerSpec定义见 pkg/apis/monitoring/v1/thanos_types.go还包含一批高频字段源码注释与 CLI 参数映射见 pkg/thanos/statefulset.go给出了确切行为字段默认值/说明replicasRuler 副本数未设置时按 1 处理ExpectedReplicas逻辑ruleSelector/ruleNamespaceSelector选择PrometheusRule的标签与命名空间选择器后者未指定时仅限ThanosRuler同命名空间queryConfig查询端点配置文件Secret 引用优先于queryEndpointsqueryEndpoints查询端点列表映射为--queryCLI 参数alertmanagersConfigAlertmanager 端点配置Secret 引用优先于已废弃的alertmanagersUrl映射为--alertmanagers.config-filealertmanagersUrl旧式 Alertmanager 地址列表已废弃映射为--alertmanagers.urlevaluationInterval规则评估间隔默认15s映射为--eval-intervalretention本地数据保留时长默认24h映射为--tsdb.retention配置 remote-write 后无效果无状态模式resendDelay向 Alertmanager 重发告警的最小间隔映射为--resend-delayruleOutageTolerance/ruleGracePeriod告警for状态恢复容忍度与宽限期Thanos v0.30.0映射为--for-outage-tolerance/--for-grace-periodruleQueryOffset规则组默认查询偏移Thanos v0.38.0ruleConcurrentEval并发规则评估数Thanos v0.37.0labels/alertDropLabels外部标签默认始终添加副本标签thanos_ruler_replica值为 Pod 名该标签在告警中始终被丢弃enableFeatures显式开启默认关闭的特性 flagThanos v0.39.0开启后不受官方支持remoteWrite远程写入列表非空时 Ruler 进入无状态模式Thanos v0.24.0portName/serviceName端口名默认web不指定serviceName时 Operator 自动创建thanos-ruler-operated无头 ServicelogLevel/logFormat/additionalArgs日志与额外参数透传为 ThanosRuler 配置 Alertmanager.spec.alertmanagersConfig引用的 Secret 内是 Thanos Ruler 的 alertmanager 配置格式见 Thanos 官方 rule 组件文档一个包含静态端点与 API 版本的示例如下apiVersion: v1 kind: Secret metadata: name: thanosruler-alertmanager-config stringData: alertmanager-configs.yaml: |- alertmanagers: - static_configs: - dnssrv_web._tcp.alertmanager-operated.monitoring.svc.cluster.local api_version: v2保存为/tmp/alertmanager-configs.yaml后用与对象存储 Secret 相同的方式创建kubectl -n monitoring create secret generic thanosruler-alertmanager-config --from-filealertmanager-configs.yaml/tmp/alertmanager-configs.yaml注意该示例通过 DNS SRV 记录自动发现alertmanager-operated服务这正是 Operator 为 Alertmanager StatefulSet 创建的 headless 服务二者可无缝对接。规则加载机制ThanosRuler 使用的记录与告警规则与 Prometheus 完全一致均来自PrometheusRule对象。示例中ruleSelector匹配标签rolemy-thanos-rules即所有带该标签的PrometheusRule会被加载到 Ruler Pod 中配合ruleNamespaceSelector可跨命名空间收集规则。若未匹配到任何规则Operator 会在日志中输出No PrometheusRule have been selected.提示见 pkg/thanos/operator.go。其余 Thanos 组件的部署建议注入 Sidecar 只是迈出 Thanos 体系的第一步。要形成完整的高可用监控链路还需独立部署以下组件Querier统一聚合各 Prometheus Sidecar 暴露的 StoreAPI提供全局查询视图Store Gateway启用对象存储备份时必需从对象存储读取历史数据块补齐离线时间范围的数据Compactor启用对象存储备份时必需在全局对象存储层面执行压缩、降采样与数据保留在旧压缩模式下它是唯一执行压缩的组件不可省略。这些组件的部署方式可参考 kube-thanos 项目它们不属于 Prometheus Operator 的托管范围需要作为独立工作负载管理。小结通过PrometheusCR 的thanos字段与ThanosRulerCRPrometheus Operator 将 Thanos Sidecar 的注入、对象存储备份、跨集群规则评估纳入了声明式管理Sidecar 侧只需提供镜像与可选的对象存储 Secret即可完成数据备份并接入全局查询ThanosRuler侧只需指定查询端点与规则选择器即可拉起独立评估集群。理解新旧版本压缩行为差异、善用queryConfig/alertmanagersConfig等 Secret 引用式配置是生产落地时保证数据一致性与告警可达性的关键。赞分享云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载相关推荐终极指南如何用Prometheus与Thanos构建企业级监控系统终极指南如何用Prometheus与Thanos构建企业级监控系统 Prometheus是一个开源的监控和警报工具用于监控Kubernetes应用程序和云基可观测性指标监控时序数据库告警VictoriaMetrics 组件对接云对象存储实战指南S3 / GCS / Azure Blob 备份与规则读取VictoriaMetrics 组件对接云对象存储实战指南S3 / GCS / Azure Blob 备份与规则读取 本文是 VictoriaMetrics时序数据库数据库指标监控可观测性后端Spraykatz实战案例在企业渗透测试中的5大应用场景Spraykatz实战案例在企业渗透测试中的5大应用场景 Spraykatz是一款强大的Windows凭据收集工具它通过自动化远程procdump和解析ls上一篇四步在 yuzu 模拟器上跑通第一款 Switch 游戏新手实践教程下一篇Windhawk终极指南如何用自定义插件重新定义你的Windows体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Prometheus Operator 与 Thanos 集成实战：Sidecar 对象存储备份与 ThanosRuler 全局规则评估
云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载Thanos 是一组可组合的组件能够将多个 Prometheus 实例整合为高可用的监控体系并在对象存储允许的前提下提供近乎无限的存储容量。Prometheus Operator 在Prometheus与ThanosRuler两类自定义资源CRD中内置了对 Thanos 的一等支持前者负责在每个 Prometheus Pod 内注入 Thanos Sidecar 容器后者则直接管理独立的 Thanos Ruler 集群。读完本文你将掌握如何在PrometheusCR 中开启 Thanos Sidecar、将 TSDB 数据块备份到对象存储、理解新旧版本压缩行为差异以及如何用ThanosRulerCR 部署跨集群的规则评估实例。Thanos 与 Prometheus Operator 的职责边界Thanos 由 Sidecar、Querier、Receiver、Compactor、Store Gateway 等组件构成。在与 Prometheus Operator 集成时Operator 只负责管理其中两类组件Thanos Sidecar由Prometheus自定义资源驱动作为容器注入到 Prometheus Pod 内部。它一方面将本地 Prometheus 的 StoreAPI 暴露给 Thanos 查询体系另一方面可选地把 TSDB 数据块上传到对象存储Thanos Ruler由ThanosRuler自定义资源驱动部署独立的 Ruler 实例用于跨集群评估 PromQL 记录规则与告警规则。而 Querier、Receiver、Compactor、Store Gateway 等其余组件需要独立于 Operator 部署。官方 kube-thanos 项目提供了这些组件的部署起点Operator 不参与其生命周期管理。在 Prometheus CR 中启用 Thanos SidecarPrometheusCRD 通过spec.thanos字段控制 Sidecar 的注入。只要将thanos设置为非空值最简形式是只给一个合法的 Thanos 容器镜像地址Operator 就会在生成的 StatefulSet Pod 中加入名为thanos-sidecar的容器# Prometheus 自定义资源片段 ... spec: ... thanos: image: quay.io/thanos/thanos:v0.28.1 ...spec.thanos对应源码中的ThanosSpec结构体见 pkg/apis/monitoring/v1/prometheus_types.go除image外还支持以下常用字段字段说明imageThanos 容器镜像地址一旦指定即覆盖baseImage/tag/sha的组合拼装仍需配合version让 Operator 获知具体版本versionThanos 版本Operator 依据它决定生成何种 StatefulSet 与配置参数缺省时按 Operator 发布时的最新上游版本处理baseImage/tag/sha已废弃推荐统一使用image完整镜像引用resourcesSidecar 容器的资源 requests/limitsobjectStorageConfig引用 Kubernetes Secret 中的对象存储配置用于上传 TSDB 块objectStorageConfigFile优先级更高objectStorageConfigFile直接指定对象存储配置文件的挂载路径优先于objectStorageConfiggrpcListenLocal/httpListenLocal为 true 时 Sidecar 的 gRPC/HTTP 端点改为监听 loopback 接口而非 Pod IP旧的listenLocal已废弃tracingConfig/tracingConfigFile追踪配置实验性功能文件形式优先级更高grpcServerTlsConfig提供 StoreAPI 的 gRPC 服务端 TLS 参数logLevel/logFormat日志级别debug/info/warn/error与格式logfmt/jsonminTimeStoreAPI 服务的时间范围下限支持 RFC3339 常量或相对时长如-1d、2h45mblockSizeTSDB 块时长默认2h与上游 Prometheus 默认值一致改动会影响整体内存与 Compactor 效率readyTimeout/getConfigInterval/getConfigTimeoutSidecar 等待 Prometheus 就绪、拉取配置的间隔与超时volumeMounts/additionalArgs追加卷挂载或透传额外的 CLI 参数如隐藏 flag仓库自带的 example/thanos/prometheus.yaml 展示了一个双副本 Prometheus 与 Thanos 集成的最小实例仅通过version: v0.42.4即可让 Operator 拉取对应版本镜像apiVersion: monitoring.coreos.com/v1 kind: Prometheus metadata: labels: prometheus: self name: self namespace: default spec: replicas: 2 ruleSelector: matchLabels: prometheus: k8s role: prometheus-rulefiles serviceMonitorSelector: matchLabels: app.kubernetes.io/name: prometheus thanos: version: v0.42.4配置 Thanos 对象存储要让 Sidecar 将 TSDB 数据块上传到对象存储需要先准备一份 Thanos 格式的存储配置文件再放入 Kubernetes Secret。配置格式与示例可参考 Thanos 官方 storage 文档下面是一个 S3 兼容存储的例子type: s3 config: bucket: thanos endpoint: ams3.digitaloceanspaces.com access_key: XXX secret_key: XXX假设将上述内容保存为/tmp/thanos-config.yaml可用如下命令在monitoring命名空间创建名为thanos-objstore-config的 Secretkubectl -n monitoring create secret generic thanos-objstore-config --from-filethanos.yaml/tmp/thanos-config.yaml随后在PrometheusCR 的thanos字段中通过objectStorageConfig引用该 Secretkey对应 Secret 内的键名name对应 Secret 名称... spec: ... thanos: image: quay.io/thanos/thanos:v0.28.1 objectStorageConfig: key: thanos.yaml name: thanos-objstore-config ...这样 Operator 就会把 Secret 内容挂载为 Sidecar 的--objstore.config-fileSidecar 会将 Prometheus 每 2 小时生成的新数据块持续上传至对象存储。若你更倾向于在 Sidecar 容器内直接指定配置文件路径可改用objectStorageConfigFile字段该字段在源码中明确标注优先级高于objectStorageConfig见 pkg/apis/monitoring/v1/prometheus_types.go。压缩行为的两种模式旧行为与新协调机制启用对象存储后本地 Prometheus 压缩与 Sidecar 上传之间的协调方式随版本而异这是生产环境最容易踩坑的点务必注意旧模式Prometheus v3.9.0 或 Thanos Sidecar v0.42.0objectStorageConfig生效会禁用本地 Prometheus 压缩Operator 将--storage.tsdb.min-block-duration与--storage.tsdb.max-block-duration都设为2h或blockSize指定值。此时必须由全局唯一的 Thanos Compactor在对象存储层面完成压缩本地不再做压缩新模式Prometheus v3.9.0 且 Thanos Sidecar v0.42.0Operator保留本地压缩改为通过 Sidecar 的 shipper 元数据文件协调上传Prometheus 以--storage.tsdb.delay-compact-file.path启动Sidecar 则以--shipper.meta-file-name与--shipper.ignore-unequal-block-size启动Prometheus 只会压缩已经上传到对象存储的 level-1 数据块从而规避关闭本地压缩带来的查询与内存开销。如需强制退回旧行为可在PrometheusCR 中设置spec.disableCompaction: true。上述逻辑在源码中有完整的映射compactionModeFor根据 Prometheus 与 Thanos 版本计算压缩模式compactionModeDisabled分支写入min/max-block-duration参数compactionModeDelayed分支写入delay-compact-file.path见 pkg/prometheus/server/statefulset.goSidecar 侧的两个 shipper 参数则在 pkg/prometheus/server/statefulset.go 中追加并由 pkg/prometheus/server/statefulset_test.go 的TestCompactionMode系列用例逐一验证延迟模式下压缩参数保持存在且 shipper 参数成对出现显式禁用压缩时则恢复旧行为。部署 ThanosRuler跨集群规则评估Thanos Ruler 中强制校验若两个查询字段都为空直接返回错误拒绝生成 StatefulSet。原文档给出的完整示例... apiVersion: monitoring.coreos.com/v1 kind: ThanosRuler metadata: name: thanos-ruler-demo labels: example: thanos-ruler namespace: monitoring spec: image: quay.io/thanos/thanos:v0.28.1 ruleSelector: matchLabels: role: my-thanos-rules queryEndpoints: - dnssrv_http._tcp.my-thanos-querier.monitoring.svc.cluster.local alertmanagersConfig: key: alertmanager-configs.yaml name: thanosruler-alertmanager-config仓库中的 example/thanos/thanos-ruler.yaml 则演示了queryConfig的写法apiVersion: monitoring.coreos.com/v1 kind: ThanosRuler metadata: labels: app.kubernetes.io/name: thanos-ruler name: thanos-ruler namespace: default spec: image: quay.io/thanos/thanos:v0.42.4 queryConfig: key: query.yaml name: thanos-ruler ruleSelector: matchLabels: role: thanos-example version: v0.42.4ThanosRulerSpec定义见 pkg/apis/monitoring/v1/thanos_types.go还包含一批高频字段源码注释与 CLI 参数映射见 pkg/thanos/statefulset.go给出了确切行为字段默认值/说明replicasRuler 副本数未设置时按 1 处理ExpectedReplicas逻辑ruleSelector/ruleNamespaceSelector选择PrometheusRule的标签与命名空间选择器后者未指定时仅限ThanosRuler同命名空间queryConfig查询端点配置文件Secret 引用优先于queryEndpointsqueryEndpoints查询端点列表映射为--queryCLI 参数alertmanagersConfigAlertmanager 端点配置Secret 引用优先于已废弃的alertmanagersUrl映射为--alertmanagers.config-filealertmanagersUrl旧式 Alertmanager 地址列表已废弃映射为--alertmanagers.urlevaluationInterval规则评估间隔默认15s映射为--eval-intervalretention本地数据保留时长默认24h映射为--tsdb.retention配置 remote-write 后无效果无状态模式resendDelay向 Alertmanager 重发告警的最小间隔映射为--resend-delayruleOutageTolerance/ruleGracePeriod告警for状态恢复容忍度与宽限期Thanos v0.30.0映射为--for-outage-tolerance/--for-grace-periodruleQueryOffset规则组默认查询偏移Thanos v0.38.0ruleConcurrentEval并发规则评估数Thanos v0.37.0labels/alertDropLabels外部标签默认始终添加副本标签thanos_ruler_replica值为 Pod 名该标签在告警中始终被丢弃enableFeatures显式开启默认关闭的特性 flagThanos v0.39.0开启后不受官方支持remoteWrite远程写入列表非空时 Ruler 进入无状态模式Thanos v0.24.0portName/serviceName端口名默认web不指定serviceName时 Operator 自动创建thanos-ruler-operated无头 ServicelogLevel/logFormat/additionalArgs日志与额外参数透传为 ThanosRuler 配置 Alertmanager.spec.alertmanagersConfig引用的 Secret 内是 Thanos Ruler 的 alertmanager 配置格式见 Thanos 官方 rule 组件文档一个包含静态端点与 API 版本的示例如下apiVersion: v1 kind: Secret metadata: name: thanosruler-alertmanager-config stringData: alertmanager-configs.yaml: |- alertmanagers: - static_configs: - dnssrv_web._tcp.alertmanager-operated.monitoring.svc.cluster.local api_version: v2保存为/tmp/alertmanager-configs.yaml后用与对象存储 Secret 相同的方式创建kubectl -n monitoring create secret generic thanosruler-alertmanager-config --from-filealertmanager-configs.yaml/tmp/alertmanager-configs.yaml注意该示例通过 DNS SRV 记录自动发现alertmanager-operated服务这正是 Operator 为 Alertmanager StatefulSet 创建的 headless 服务二者可无缝对接。规则加载机制ThanosRuler 使用的记录与告警规则与 Prometheus 完全一致均来自PrometheusRule对象。示例中ruleSelector匹配标签rolemy-thanos-rules即所有带该标签的PrometheusRule会被加载到 Ruler Pod 中配合ruleNamespaceSelector可跨命名空间收集规则。若未匹配到任何规则Operator 会在日志中输出No PrometheusRule have been selected.提示见 pkg/thanos/operator.go。其余 Thanos 组件的部署建议注入 Sidecar 只是迈出 Thanos 体系的第一步。要形成完整的高可用监控链路还需独立部署以下组件Querier统一聚合各 Prometheus Sidecar 暴露的 StoreAPI提供全局查询视图Store Gateway启用对象存储备份时必需从对象存储读取历史数据块补齐离线时间范围的数据Compactor启用对象存储备份时必需在全局对象存储层面执行压缩、降采样与数据保留在旧压缩模式下它是唯一执行压缩的组件不可省略。这些组件的部署方式可参考 kube-thanos 项目它们不属于 Prometheus Operator 的托管范围需要作为独立工作负载管理。小结通过PrometheusCR 的thanos字段与ThanosRulerCRPrometheus Operator 将 Thanos Sidecar 的注入、对象存储备份、跨集群规则评估纳入了声明式管理Sidecar 侧只需提供镜像与可选的对象存储 Secret即可完成数据备份并接入全局查询ThanosRuler侧只需指定查询端点与规则选择器即可拉起独立评估集群。理解新旧版本压缩行为差异、善用queryConfig/alertmanagersConfig等 Secret 引用式配置是生产落地时保证数据一致性与告警可达性的关键。赞分享云原生可观测性【免费下载链接】prometheus-operatorPrometheus Operator creates/configures/manages Prometheus clusters atop Kubernetes项目地址https://gitcode.com/gh_mirrors/pr/prometheus-operator点击查看免费下载相关推荐终极指南如何用Prometheus与Thanos构建企业级监控系统终极指南如何用Prometheus与Thanos构建企业级监控系统 Prometheus是一个开源的监控和警报工具用于监控Kubernetes应用程序和云基可观测性指标监控时序数据库告警VictoriaMetrics 组件对接云对象存储实战指南S3 / GCS / Azure Blob 备份与规则读取VictoriaMetrics 组件对接云对象存储实战指南S3 / GCS / Azure Blob 备份与规则读取 本文是 VictoriaMetrics时序数据库数据库指标监控可观测性后端Spraykatz实战案例在企业渗透测试中的5大应用场景Spraykatz实战案例在企业渗透测试中的5大应用场景 Spraykatz是一款强大的Windows凭据收集工具它通过自动化远程procdump和解析ls上一篇四步在 yuzu 模拟器上跑通第一款 Switch 游戏新手实践教程下一篇Windhawk终极指南如何用自定义插件重新定义你的Windows体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考