跳转到内容

Thanos 面试题

30 道题
分类
可观测性
子分类
metrics
题目数
30 道
已阅读 0 / 30 题
1 Thanos 的核心架构和设计理念是什么?

答案:

Thanos 是一个基于 Prometheus 的全局监控方案,通过 Sidecar/Receiver 组件将 Prometheus 数据持久化到对象存储,并提供全局查询视图。

核心架构:

graph TD
    P1["Prom-1<br/>+Sidecar"] --> OS["对象存储 (S3/GCS)<br/>(Store Gateway 读取)"]
    P2["Prom-2<br/>+Sidecar"] --> OS
    P3["Prom-3<br/>+Sidecar"] --> OS
    OS --> TQ["Thanos Query<br/>(全局查询 + 去重)"]
    TQ --> Grafana["Grafana"]

设计理念:

原则说明
无限存储对象存储作为主存储,Prometheus 仅作为采集和短期缓存
全局视图跨 Prometheus 实例的数据统一查询
高可用多副本数据自动去重,无单点故障
低成本数据压缩到对象存储,降低本地存储成本
2 Thanos 各组件的职责和通信方式是什么?

答案:

Thanos 由多个独立组件组成,它们通过 gRPC Store API 通信,共同提供全局监控方案。

组件一览:

组件职责通信端口状态
Sidecar连接 Prometheus,上传数据到对象存储gRPC :10901有状态
Store Gateway读取对象存储中的数据gRPC :10901无状态
Query全局查询聚合器,去重gRPC :10901, HTTP :10902无状态
Compactor数据压缩、降采样、删除HTTP :10902无状态
Ruler告警和记录规则评估gRPC :10901, HTTP :10902有状态
Receiver接收 Remote Write 数据gRPC :10901, HTTP :10902有状态

组件通信:

Query → Store API (gRPC) → Sidecar (Prometheus 实时数据)
Query → Store API (gRPC) → Store Gateway (对象存储历史数据)
Query → Store API (gRPC) → Ruler (规则产生的指标)
Query → Store API (gRPC) → Receiver (Remote Write 数据)
Ruler → Store API (gRPC) → Query (用于规则评估)
Compactor → 对象存储 (读取和写入压缩后的数据)
3 Thanos Sidecar 的工作原理是什么?

答案:

Thanos Sidecar 作为边车容器与 Prometheus 部署在同一 Pod,负责数据上传和实时查询。

工作流程:

graph TD
    A["Prometheus Server<br/>每 2h 生成一个 Block"] --> B["WAL to Head to<br/>冻结 Block 2h"]
    B --> C["Sidecar 检测到新 Block"]
    C -->|"上传路径"| D["上传到对象存储 S3/GCS<br/>压缩后的 Block 数据<br/>保留原始格式"]
    C -->|"查询路径"| E["提供 Store API<br/>gRPC :10901<br/>查询 Prometheus 实时数据<br/>返回 Head 中未压缩数据"]

配置示例:

# Pod 定义
containers:
  - name: prometheus
    image: prom/prometheus:v2.50.0
    args:
      - --storage.tsdb.retention.time=2h   # 仅保留 2h(数据已上传)
      - --storage.tsdb.min-block-duration=2h
      - --storage.tsdb.max-block-duration=2h
  - name: thanos-sidecar
    image: quay.io/thanos/thanos:v0.34.0
    args:
      - sidecar
      - --tsdb.path=/prometheus
      - --prometheus.url=http://localhost:9090
      - --objstore.config-file=/etc/thanos/objstore.yml
      - --grpc-address=0.0.0.0:10901
      - --http-address=0.0.0.0:10902

对象存储配置:

type: S3
config:
  bucket: thanos-metrics
  endpoint: s3.amazonaws.com
  access_key: AKIA...
  secret_key: ...
  insecure: false
  signature_version2: false
  put_user_metadata:
    "X-Amz-Storage-Class": "STANDARD_IA"
4 Thanos Compactor 的压缩和降采样策略是什么?

答案:

Thanos Compactor 负责压缩对象存储中的数据块并生成降采样数据,优化查询性能和存储成本。

压缩过程:

graph TD
    B1["Block-1<br/>(08:00)"] --> Merged["Merged Block<br/>(08:00-14:00)<br/>- 去重<br/>- 重新索引<br/>- 更小体积"]
    B2["Block-2<br/>(10:00)"] --> Merged
    B3["Block-3<br/>(12:00)"] --> Merged
    B4["Block-4<br/>(14:00)"] --> Merged

降采样策略:

原始数据 (Raw):
  分辨率: 原始采集间隔(通常 15s)
  保留: 30 天

降采样 5m (5m):
  分辨率: 5 分钟聚合
  保留: 90 天
  数据量: 原始 × 1/20

降采样 1h (1h):
  分辨率: 1 小时聚合
  保留: 365 天
  数据量: 原始 × 1/240

降采样配置:

# Compactor 启动参数
thanos:
  compactor:
    retentionResolutionRaw: 30d
    retentionResolution5m: 180d
    retentionResolution1h: 365d
    compactInterval: 1h
    consistencyDelay: 30m
    dataDir: /data
    blockFilesConcurrency: 10
    maxDownloadBlockSize: 64GB

降采样查询行为:

Query 自动选择最佳分辨率:
  查询时间范围 < 30d → 原始数据(最高精度)
  30d < 查询时间范围 < 180d → 5m 降采样
  查询时间范围 > 180d → 1h 降采样
5 Thanos Query 的去重机制是什么?

答案:

Thanos Query 通过标签集对比和 Deduplication 标记实现多副本数据的自动去重。

去重条件:

去重前提:两个时间序列具有完全相同的 Label Set

Thanos Sidecar 上传时自动添加:
  - replica: "0"  (从 Prometheus externalLabels 中继承)
  - thanos_replica: "0"

去重逻辑:
  1. Query 从多个 Store API 获取相同序列
  2. 比较标签集(排除 replica/thanos_replica)
  3. 标签相同时,选择时间戳最大的样本
  4. 丢弃副本标签,返回唯一序列

配置:

# Query 端去重(默认开启)
--query.replica-label=replica
--query.replica-label=thanos_replica

# 关闭去重(调试用)
--query.replica-label=""

去重效果:

# 没有去重 → 返回重复序列
  up{instance="node1", job="node", replica="0"} 1
  up{instance="node1", job="node", replica="1"} 1
  up{instance="node2", job="node", replica="0"} 1
  up{instance="node2", job="node", replica="1"} 1

# 去重后 → 返回唯一序列
  up{instance="node1", job="node"} 1
  up{instance="node2", job="node"} 1
6 Thanos Receiver 的作用和适用场景是什么?

答案:

Thanos Receiver 接收 Prometheus Remote Write 数据,提供 Push 模式的写入入口,替代 Sidecar 方案。

架构:

graph TD
    Prom["Prometheus"] -->|Remote Write| RCVR
    subgraph RCVR["Thanos Receiver"]
        SA["Store API (gRPC)"] --> Q["Query 实时查询"]
        TSDB["TSDB"] --> L["本地存储(短期)"]
        OSS["对象存储"] --> LT["长期存储"]
    end

适用场景:

场景ReceiverSidecar
已有 Prometheus需要修改 Remote Write 配置需要部署 Sidecar
NAT 网络适配(Push 模式)不适配
Prometheus Operator配置 Remote Write需额外 Sidecar
数据复制支持 Fanout不支持
实时查询依赖本地缓存依赖 Prometheus

配置示例:

# Receiver 配置
thanos:
  receiver:
    # 接收端 gRPC
    grpcAddress: 0.0.0.0:10901
    # Remote Write HTTP
    httpAddress: 0.0.0.0:10902
    # 对象存储(长期)
    objstoreConfig:
      type: S3
      config:
        bucket: thanos-receive
    # 本地 TSDB 保留期
    tsdbRetention: 24h
    # 一致性哈希分片
    hashring:
      - hashring: default
        endpoints:
          - thanos-receiver-0:10901
          - thanos-receiver-1:10901
          - thanos-receiver-2:10901
    # 转发配置
    forwardTimeout: 5s
7 Thanos Ruler 的规则评估和数据来源是什么?

答案:

Thanos Ruler 替代 Prometheus 的规则评估功能,通过 Store API 从全局数据计算告警和记录规则。

数据流向:

Ruler 规则评估流程:

1. 查询数据
   Ruler → Store API → Query/Sidecar/Store Gateway

2. 评估规则
   根据 PromQL 计算记录规则和告警规则

3. 存储结果
   记录规则的结果 → 写入 Ruler 本地 TSDB
   告警 → 发送到 Alertmanager

4. 暴露结果
   Ruler TSDB → Store API → Query 可以查询

配置示例:

thanos:
  ruler:
    # 查询端
    queryEndpoints:
      - thanos-query:10901
    # 告警端
    alertmanagers:
      - alertmanager:9093
    # 规则文件
    ruleFiles:
      - /etc/thanos/rules/*.yaml
    # 数据存储
    dataDir: /data
    # 评估间隔
    evalInterval: 30s
    # 对象存储
    objstoreConfig:
      type: S3
      config:
        bucket: thanos-ruler

规则文件:

groups:
  - name: thanos-rules
    interval: 30s
    rules:
      - record: thanos:node_cpu:avg_usage
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode!="idle"}[5m]))
      - alert: HighLatency
        expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 5
        for: 5m
8 Thanos Store Gateway 的缓存机制是什么?

答案:

Thanos Store Gateway 通过多层缓存加速对象存储数据的读取。

缓存层次:

缓存类型缓存内容存储方式推荐配置
Index Cache倒排索引内存1-4GB
Chunk Cache压缩后的样本数据内存2-8GB
Bucket Cache对象存储列表内容内存500MB
Group Cache块元数据内存200MB

缓存配置:

thanos:
  store:
    # Index Cache (内存)
    indexCacheSize: 2GB
    indexCacheType: inmemory

    # Chunk Cache (内存)
    chunkCacheSize: 4GB
    chunkCacheType: inmemory

    # Memcached 缓存后端
    # indexCacheType: memcached
    # memcached:
    #   addresses: ['memcached:11211']
    #   timeout: 500ms

    # 其他缓存配置
    maxRetries: 3
    maxItemSize: 64MB
    blockSyncInterval: 5m
    consistencyDelay: 30m

缓存命中率监控:

# 缓存命中率
rate(thanos_store_index_cache_hits_total[5m])
/
rate(thanos_store_index_cache_requests_total[5m])

# Chunk 缓存
rate(thanos_store_chunk_cache_hits_total[5m])
/
rate(thanos_store_chunk_cache_requests_total[5m])
9 Thanos 的对象存储支持哪些后端?

答案:

Thanos 支持多种对象存储后端,统一通过 Bucket API 操作。

支持的后端:

后端配置 type认证方式说明
AWS S3S3Access Key / IAM Role标准对象存储
Google GCSGCSService Account适合 GCP 环境
Azure BlobAZUREAccount Key / Managed ID适合 Azure 环境
MinIOS3Access Key自建对象存储
CephS3Access Key自建存储集群
OpenStack SwiftSWIFT用户名密码OpenStack 环境
Aliyun OSSOSSAccess Key阿里云环境
本地文件FILESYSTEM-测试/开发环境
HTTP/HTTPSHTTP-只读

配置示例:

# S3
type: S3
config:
  bucket: thanos-bucket
  endpoint: s3.amazonaws.com
  region: us-east-1
  access_key: AKIA...
  secret_key: ...
  insecure: false
  signature_version2: false
  put_user_metadata:
    "X-Amz-Storage-Class": "STANDARD_IA"
  http_config:
    idle_conn_timeout: 90s
    response_header_timeout: 2m
    insecure_skip_verify: false
  sse_config:
    type: SSE-S3

# GCS
type: GCS
config:
  bucket: thanos-gcs-bucket
  service_account: |
    {
      "type": "service_account",
      "project_id": "my-project"
    }    

# MinIO (S3 兼容)
type: S3
config:
  bucket: thanos-minio
  endpoint: minio:9000
  region: us-east-1
  access_key: minioadmin
  secret_key: minioadmin
  insecure: true

# 本地文件测试
type: FILESYSTEM
config:
  directory: /tmp/thanos-test
10 Thanos Compactor 的降采样数据是如何查询的?

答案:

Thanos Query 根据查询时间范围自动选择合适的降采样分辨率,对用户透明。

查询行为:

Query 查询流程:

1. 用户发起查询(时间范围 T1-T2)
2. Query 检查时间范围大小
3. 根据范围选择分辨率:
   - T2-T1 < 30d → 查询原始数据
   - 30d < T2-T1 < 180d → 查询 5m 降采样
   - T2-T1 > 180d → 查询 1h 降采样
4. 发送 Store API 请求到 Store Gateway
5. 返回对应分辨率的数据

分辨率选择配置:

thanos query \
  --query.auto-downsampling  # 自动降采样(默认开启)

降采样数据指标:

# 已降采样的数据块
thanos_compact_downsampled_total

# 降采样延迟
thanos_compact_downsample_duration_seconds

# 降采样数据大小
thanos_store_data_blocks{resolution="5m"}
thanos_store_data_blocks{resolution="1h"}

查询示例:

# 查看 1 年内的 CPU 使用率趋势
# Query 自动使用 1h 降采样数据
avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1h]))

# 强制使用原始数据查询
avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[1h])) @ start()
11 Thanos 的 Bucket API 和 Web UI 有什么功能?

答案:

Thanos 提供 Bucket API 和 Web UI 用于查看和管理对象存储中的数据块。

Bucket Web UI 功能:

功能说明
Block 列表浏览对象存储中的所有数据块
Block 详情查看块的元数据(时间范围、样本数、大小)
源信息块的来源 Prometheus 实例
标签块的标签信息

Bucket API 命令:

# 列出所有 Block
thanos bucket ls --objstore.config-file=objstore.yml

# 检查数据块一致性
thanos bucket verify --objstore.config-file=objstore.yml

# 检查重复块
thanos bucket inspect --objstore.config-file=objstore.yml

# 删除过期的降采样数据
thanos bucket retention --objstore.config-file=objstore.yml \
  --retention.resolution-raw=0d \
  --retention.resolution-5m=180d \
  --retention.resolution-1h=365d \
  --dry-run

# 数据块标记(标记需要 Compactor 处理的块)
thanos bucket label --objstore.config-file=objstore.yml \
  --metric=__block_id \
  --value=compactme

监控 Bucket:

# 块总数
thanos_bucket_store_blocks_loaded

# 块大小分布
thanos_bucket_store_block_duration_seconds

# 列表操作延迟
thanos_bucket_store_series_data_fetch_duration_seconds

# Bucket 操作失败
rate(thanos_bucket_store_operation_failures_total[5m])
12 Thanos 的多租户和多集群支持是怎样的?

答案:

Thanos 通过 Query 的 Store API 发现机制和标签注入实现多租户和多集群查询。

多集群架构:

graph TD
    CA["集群 A: Thanos<br/>(Sidecar + Store + Query-A)"] --> GQ["Thanos Query (Global)<br/>(查询所有集群的 Store)"]
    CB["集群 B: Thanos<br/>(Sidecar + Store + Query-B)"] --> GQ
    CC["集群 C: Thanos<br/>(Sidecar + Store + Query-C)"] --> GQ
    GQ --> GF["Grafana"]

多集群配置:

# 全局 Query 通过 Store API 连接多个集群
thanos:
  query:
    # 静态 Store
    stores:
      - thanos-query-cluster-a:10901
      - thanos-query-cluster-b:10901
      - thanos-query-cluster-c:10901

    # DNS 发现
    store.sd-files:
      - /etc/thanos/store-sd.yaml
    store.sd-interval: 5m

标签隔离:

# 每个集群的 Sidecar 注入集群标签
sidecar:
  externalLabels:
    cluster: cluster-a
    environment: production
# 查询时按标签过滤
query:
  # 存储端标签
  store.labels:
    - replica
    - cluster

多租户查询:

# 查询特定集群的数据
up{cluster="cluster-a"}

# 按集群聚合
count by (cluster) (up)

# 多集群对比
avg by (cluster) (rate(node_cpu_seconds_total[5m]))
13 Thanos 的 Store API 协议和查询流程是什么?

答案:

Thanos Store API 是基于 gRPC 的通信协议,所有 Thanos 组件通过此接口共享数据。

Store API 接口定义:

service Store {
  // 查询时间序列
  rpc Series(SeriesRequest) returns (stream SeriesResponse);
  
  // 获取标签名
  rpc LabelNames(LabelNamesRequest) returns (LabelNamesResponse);
  
  // 获取标签值
  rpc LabelValues(LabelValuesRequest) returns (LabelValuesResponse);
  
  // 获取存储信息
  rpc Info(InfoRequest) returns (InfoResponse);
}

查询流程:

graph TD
    A["User Query PromQL"] --> B["Thanos Query"]
    B --> C["1. 向所有 Store 发送<br/>LabelValues 请求<br/>获取标签信息"]
    B --> D["2. 向所有 Store 发送<br/>Series 请求<br/>标签匹配器 + 时间范围"]
    B --> E["3. 接收所有 Store 返回的流式数据"]
    E --> E1["Sidecar 实时数据"]
    E --> E2["Store Gateway 历史数据"]
    E --> E3["Ruler 规则结果"]
    E --> E4["Receiver Remote Write 数据"]
    E1 & E2 & E3 & E4 --> F["4. 合并数据流"]
    F --> F1["按时间戳排序"]
    F --> F2["去重 replica 标签"]
    F1 & F2 --> G["Query Result"]

Info 接口响应:

每个 Store 返回自己的元数据:
  LabelSets: 标签范围(如 cluster="a")
  MinTime: 最早数据时间
  MaxTime: 最新数据时间
  StoreType: Sidecar/Store/Ruler/Receiver
14 Thanos Sidecar 的 Prometheus 版本兼容性是什么?

答案:

Thanos Sidecar 依赖 Prometheus 的 TSDB 格式和 API,对 Prometheus 版本有兼容性要求。

兼容性矩阵:

Prometheus 版本Sidecar 版本兼容性说明
v2.50.xv0.34.x兼容最新版本
v2.40.xv0.30.x兼容推荐升级
v2.30.xv0.25.x兼容需注意 API 差异
v2.20.xv0.20.x兼容功能受限
v2.10.xv0.15.x兼容已停止支持

Sidecar 对 Prometheus 的要求:

1. Prometheus 版本 >= v2.2.1(支持存储 Block 上传)
2. 开启 --web.enable-admin-api(Sidecar 需要读取 TSDB 状态)
3. 设置 --storage.tsdb.min-block-duration=2h(默认即可)
4. 设置 --storage.tsdb.max-block-duration=2h(避免合并)
5. 配置 externalLabels(用于区分副本)

推荐 Prometheus 配置:

# Prometheus 配置(与 Sidecar 配合)
--storage.tsdb.retention.time=2h    # 仅保留 2h(数据已上传到对象存储)
--storage.tsdb.min-block-duration=2h
--storage.tsdb.max-block-duration=2h
--web.enable-admin-api              # Sidecar 需要
--web.enable-lifecycle              # Sidecar 需要
15 Thanos 的存储成本优化策略是什么?

答案:

Thanos 通过对象存储的冷热分层和降采样策略降低长期存储成本。

成本优化策略:

策略效果说明
降采样数据量 1/20 到 1/240长周期查询使用低精度数据
存储类成本 50-80%热→冷存储类转换
生命周期成本 90%+过期数据自动清理
压缩数据量 10-30%Block 合并减少冗余
Block 分组IOPS 降低同标签数据整合

存储类配置:

# AWS S3 存储类配置
type: S3
config:
  bucket: thanos-metrics
  put_user_metadata:
    "X-Amz-Storage-Class": "STANDARD_IA"  # 30 天后自动转为 STANDARD_IA

# 或者依赖 S3 生命周期策略
# S3 Lifecycle Rule:
#   - 当前版本: 30d → STANDARD_IA, 60d → GLACIER, 365d → EXPIRED

成本估算:

原始数据量: 每天 100GB
压缩比: ~10:1(Prometheus TSDB)
每月存储: 100GB × 30 / 10 = 300GB

降采样存储:
  原始 30d: 100GB × 30 = 300GB
  5m 降采样额外 90d: 300GB × (90/30) / 20 = 45GB
  1h 降采样额外 245d: 300GB × (245/30) / 240 = 10GB
  总计: 355GB

S3 存储成本:
  标准 (300GB): $0.023/GB = $6.90/月
  STANDARD_IA (45GB): $0.0125/GB = $0.56/月
  GLACIER (10GB): $0.004/GB = $0.04/月
  总计: ~$7.50/月
16 Thanos 的端到端延迟和查询性能如何优化?

答案:

Thanos 查询性能受对象存储延迟、缓存命中率和数据量影响,多维度优化。

性能影响因素:

因素影响优化手段
对象存储延迟首次查询慢增加缓存、CDN
数据块数量查询需扫描大量块Compact 合并减少块数
序列基数查询结果集大精确匹配标签
时间范围扫描数据量大缩小查询范围
Store 数量网络开销合理规划 Store 数量

优化配置:

thanos:
  query:
    # 并行度
    maxConcurrent: 20
    maxConcurrentSelects: 10
    
    # 超时
    timeout: 2m
    lookbackDelta: 5m
    
    # Store 连接
    store.sd-interval: 5m
    store.responseTimeout: 10s
    
    # 查询优化
    auto-downsampling: true
    query.partial-response: false

  store:
    # 缓存
    indexCacheSize: 4GB
    chunkCacheSize: 8GB
    
    # 块同步
    blockSyncInterval: 5m
    consistencyDelay: 30m

查询优化建议:

1. 精确匹配标签
   up{instance="node1"}  → 快速(利用索引)
   up{job=~".+node"}     → 慢(全扫描)

2. 缩小时间范围
   查询 1h 数据 < 查询 24h 数据 < 查询 7d 数据

3. 利用降采样
   长时间范围查询 → 自动使用降采样数据

4. 减少查询的序列数
   按需聚合(sum by)而非返回所有原始序列

5. 使用记录规则
   预计算高频查询
17 Thanos Compact 的块合并和去重机制是什么?

答案:

Thanos Compactor 对对象存储中的数据块进行合并和去重,优化查询性能和存储效率。

块合并策略:

原始块(未合并):
  Block-A (prom-1, 08-10h)
  Block-B (prom-1, 10-12h)
  Block-C (prom-2, 08-10h)
  Block-D (prom-2, 10-12h)

Compactor 合并后:
  Block-AB (prom-1, 08-12h, 合并后的索引)
  Block-CD (prom-2, 08-12h, 合并后的索引)

去重策略:

多副本写入(同一序列写入多个 Block):
  Series:
    node_cpu_seconds_total{instance="node1", mode="idle", replica="0"} @ T=1, value=100
    node_cpu_seconds_total{instance="node1", mode="idle", replica="1"} @ T=1, value=100

Compactor 去重(dedup):
  消除 replica 标签差异
  选择时间戳最近的样本
  输出唯一序列:
    node_cpu_seconds_total{instance="node1", mode="idle"} @ T=1, value=100

去重标记:

# Sidecar 必须配置 externalLabels 以便去重识别
sidecar:
  externalLabels:
    prometheus_cluster: prometheus-a
    replica: 0

Compactor 配置:

thanos:
  compactor:
    # 去重标记
    dedup.func: dedup
    # 合并延迟(等待所有副本上传完成)
    consistencyDelay: 30m
    # 合并间隔
    compactInterval: 1h
    # 最大待合并块数
    maxDownloadBlockSize: 64GB
    # 并发数
    blockFilesConcurrency: 10
18 Thanos Query 的 Store Discovery 机制是什么?

答案:

Thanos Query 通过多种发现方式找到可用的 Store API 端点,动态更新查询后端。

发现方式:

方式配置刷新机制适用场景
静态配置–store=host:port启动时加载小规模固定环境
DNS SRV–store.sd-dns-interval=5m定期 DNS 查询K8s Headless Service
文件发现–store.sd-files=/path/*.json文件更新自动加载动态管理
静态文件–store.sd-filesWatch 机制复杂拓扑
gRPC 广播组件自动注册动态高级功能

DNS 发现:

# K8s Headless Service 方式
apiVersion: v1
kind: Service
metadata:
  name: thanos-store-gateway
spec:
  clusterIP: None
  selector:
    app: thanos-store
  ports:
    - name: grpc
      port: 10901

# Query 自动 DNS 发现
thanos:
  query:
    store.sd-dns-interval: 30s
    # 自动解析 DNS SRV 记录
    # _grpc._tcp.thanos-store-gateway.monitoring.svc.cluster.local

文件发现:

# /etc/thanos/store-sd.yaml
- targets:
    - thanos-sidecar-0:10901
    - thanos-sidecar-1:10901
  labels:
    cluster: prod-us-east
- targets:
    - thanos-store-0:10901
    - thanos-store-1:10901
  labels:
    type: store-gateway
19 Thanos 的告警和规则评估机制与 Prometheus 有什么不同?

答案:

Thanos Ruler 替代 Prometheus 的规则评估功能,但数据来源和作用域不同。

对比分析:

维度Prometheus 规则Thanos Ruler
数据来源本地 TSDBStore API(全局数据)
评估范围单 Prometheus 实例整个 Thanos 集群
告警发送Prometheus → AlertmanagerRuler → Alertmanager
记录规则存储本地 TSDBRuler 本地 TSDB + 对象存储
高可用双跑 + 去重多副本 + 去重
延迟实时取决于 Store API 延迟

Thanos Ruler 的高可用:

多副本 Ruler:
  Ruler-A (replica=0) + Ruler-B (replica=1)

评估行为:
  两个 Ruler 评估相同的规则
  各自产生相同的数据
  通过 replica 标签区分
  Query 端去重

故障切换:
  Ruler-A 故障 → Ruler-B 继续服务
  不丢失告警和记录规则数据

Ruler 配置:

thanos:
  ruler:
    replicas: 2
    evaluationInterval: 30s
    queryEndpoints:
      - thanos-query:10901
    alertmanagers:
      - alertmanager:9093
    externalLabels:
      ruler_replica: $(POD_NAME)
    ruleFiles:
      - /etc/thanos/rules/*.yaml
20 Thanos 的 Objstore Tool 有哪些实用操作?

答案:

Thanos Objstore Tool 是一组直接在对象存储上操作的命令行工具,用于检查和维护存储数据。

常用命令:

# 列出所有 Block
thanos tools bucket list \
  --objstore.config-file=objstore.yml

# 检查存储一致性
thanos tools bucket verify \
  --objstore.config-file=objstore.yml \
  --repair=false \
  --delete-blocks=false

# 检查重复块
thanos tools bucket inspect \
  --objstore.config-file=objstore.yml

# 数据块标记(用于 Compactor 处理)
thanos tools bucket label \
  --objstore.config-file=objstore.yml \
  --metric=__block_id \
  --value=compactme

# 删除标记的块
thanos tools bucket cleanup \
  --objstore.config-file=objstore.yml \
  --delete-delay=48h

# 数据保留管理
thanos tools bucket retention \
  --objstore.config-file=objstore.yml \
  --retention.resolution-raw=30d \
  --retention.resolution-5m=180d \
  --retention.resolution-1h=365d \
  --dry-run

数据修复工具:

# 块损坏修复
thanos tools bucket repair \
  --objstore.config-file=objstore.yml \
  --max-time=2h \
  --dry-run

# 索引重建
thanos tools bucket rewrite \
  --objstore.config-file=objstore.yml \
  --rewrite.to-block-id=<block-id>
21 Thanos 在 K8s 中的推荐部署方式是什么?

答案:

Thanos 在 K8s 中通过 Thanos Operator 或 Helm Chart 部署,各组件独立管理和扩展。

K8s 部署架构:

Namespace: thanos

  Sidecar (与 Prometheus 同 Pod):
    prometheus + thanos-sidecar

  Store Gateway (Deployment):
    Store Gateway (2 副本)
    Service: thanos-store

  Query (Deployment):
    Query (2 副本)
    Service: thanos-query

  Compactor (StatefulSet/Job):
    Compactor (1 副本)
    PVC: 10GB

  Ruler (StatefulSet):
    Ruler (2 副本)
    PVC: 50GB

Helm 部署:

# values.yaml
query:
  enabled: true
  replicas: 2
  stores:
    - thanos-store:10901
    - thanos-sidecar:10901

store:
  enabled: true
  replicas: 2
  objstoreConfig:
    type: S3
    config:
      bucket: thanos-store
      endpoint: s3.amazonaws.com

compactor:
  enabled: true
  persistence:
    size: 10Gi
  objstoreConfig:
    type: S3
    config:
      bucket: thanos-compactor
      endpoint: s3.amazonaws.com
  retentionResolutionRaw: 30d
  retentionResolution5m: 180d
  retentionResolution1h: 365d

ruler:
  enabled: true
  replicas: 2
  alertmanagers:
    - http://alertmanager:9093
  queryEndpoints:
    - thanos-query:10901
22 Thanos 与 VictoriaMetrics 的选型对比是什么?

答案:

Thanos 和 VictoriaMetrics 都是 Prometheus 的扩展方案,但架构和运维复杂度不同。

对比分析:

维度ThanosVictoriaMetrics
架构分布式微服务(6+ 组件)单体或三组件架构
部署复杂度高(多组件配置)低(单 Binary 或三组件)
存储对象存储(S3/GCS)本地磁盘 + 可选对象存储
压缩比5-10×(Prometheus TSDB)10-20×(自研引擎)
查询延迟中(对象存储远距离)低(本地磁盘)
降采样内置(3 级降采样)内置(自动降采样)
多租户需额外配置原生多租户
Remote WriteReceiver 组件默认原生支持
资源消耗高(多组件)低(单组件)
Grafana 集成Prometheus 数据源Prometheus 数据源
成熟度成熟(CNCF Incubating)成熟

选择建议:

Thanos:
  - 已有对象存储基础设施
  - 需要完全的 Prometheus 兼容性
  - 多集群统一查询
  - 团队熟悉微服务运维

VictoriaMetrics:
  - 追求运维简洁和低资源消耗
  - 需要更高的存储压缩比
  - 单集群大规模监控
  - 资源受限环境
23 Thanos 的查询 trace 和调试方法是什么?

答案:

Thanos 内置 OpenTracing 集成,支持从查询端到存储端的全链路追踪。

Trace 系统集成:

# Thanos 组件启动参数(Jaeger 集成)
thanos:
  query:
    tracing.config: |
      type: JAEGER
      config:
        service_name: thanos-query
        sampler_type: const
        sampler_param: 1
        reporter:
          localAgentHostPort: jaeger-agent:6831      

查询 Trace 分析:

每个查询请求的 Trace 包含:
  1. Query → Store API 请求
  2. Store Gateway 的索引查找
  3. Store Gateway 的块读取
  4. 对象存储的 GET 请求
  5. Query 端的数据合并和去重

通过 Trace 可以定位:
  - 哪个 Store 响应最慢
  - 对象存储的延迟瓶颈
  - 数据量大小

内部调试端点:

# Query 状态
GET /api/v1/status/tsdb       # TSDB 状态
GET /api/v1/status/store       # Store 连接状态
GET /api/v1/labels             # 标签列表

# Store 状态
GET /api/v1/status/blocks      # 已加载的块
GET /metrics                   # Prometheus 指标

# Compactor 状态
GET /api/v1/status/groups      # 压缩分组状态

# 日志级别
GET /debug/pprof/              # Go pprof 分析
GET /-/ready                   # 就绪检查
GET /-/healthy                 # 健康检查
24 Thanos 的常见故障场景和解决方案是什么?

答案:

Thanos 在多组件分布式架构下面临多种故障场景。

常见故障:

故障场景症状解决方案
对象存储不可达查询 500,Upload 失败检查网络和认证配置
Compactor 失败块未合并,存储增长检查 Compactor 日志和对象存储
Query OOMPod 内存超限增加内存,限制并发查询
Store 加载慢新数据查询延迟增加 Store Gateway 缓存
Sidecar 上传失败数据只在 Prometheus 本地检查 Sidecar 状态和对象存储
Ruler 评估延迟告警延迟增加 Ruler 副本
数据不一致查询结果错误运行 bucket verify 修复

诊断步骤:

1. 检查组件状态
   kubectl get pods -n thanos
   kubectl logs thanos-query-xxx -n thanos

2. 检查对象存储
   thanos tools bucket verify --objstore.config-file=objstore.yml

3. 检查 Store 连接
   curl thanos-query:10902/api/v1/status/store

4. 检查块状态
   curl thanos-store:10902/api/v1/status/blocks

5. 检查内存
   kubectl top pods -n thanos

6. 检查重启次数
   kubectl get pods -n thanos | grep CrashLoopBackOff
25 Thanos 的数据备份和灾难恢复方案是什么?

答案:

Thanos 的数据存储在对象存储中,备份和恢复策略围绕对象存储设计。

备份策略:

# 1. 对象存储跨区域复制
# AWS S3 CRR (Cross-Region Replication)
aws s3api put-bucket-replication \
  --bucket thanos-source \
  --replication-configuration file://crr-config.json

# 2. 定期 Bucket 快照
# 备份到另一个 Bucket
thanos tools bucket replicate \
  --objstore.config-file=source.yml \
  --objstore.target-config=backup.yml \
  --resolution=raw \
  --max-time=7d

# 3. 增量备份脚本
#!/bin/bash
# 每日增量备份到不同 Bucket
backup_bucket="thanos-backup-$(date +%Y%m%d)"
aws s3 sync s3://thanos-prod/ s3://$backup_bucket/

灾难恢复流程:

恢复步骤:

1. 确认故障范围
   - 单 Prometheus 故障 → 从对象存储恢复
   - 整个 Thanos 集群故障 → 重建集群
   - 对象存储不可用 → 使用备份

2. 重建 Thanos 集群
   helm install thanos ./thanos -f values.yaml

3. 恢复数据
   # 从备份 Bucket 恢复数据
   thanos tools bucket replicate \
     --objstore.config-file=backup.yml \
     --objstore.target-config=prod.yml \
     --resolution=raw

4. 验证数据完整性
   thanos tools bucket verify --objstore.config-file=prod.yml

5. 恢复查询服务
   # Query 自动发现 Store Gateway
   # 数据恢复后自动可查

RPO/RTO:

对象存储多 AZ:
  RPO: 近零(同步复制)
  RTO: 分钟级(切换 AZ)

跨区域复制:
  RPO: 15 分钟(异步复制)
  RTO: 分钟级(切换 DNS)

定期备份:
  RPO: 24 小时(日备份)
  RTO: 小时级(恢复数据)
26 Thanos 的元数据管理与标签操作是什么?

答案:

Thanos 支持对对象存储中的数据块进行标签操作,用于 Compactor 选择、数据隔离和管理。

标签操作:

# 查看块标签
thanos tools bucket inspect \
  --objstore.config-file=objstore.yml

# 为块添加标签
thanos tools bucket label \
  --objstore.config-file=objstore.yml \
  --metric=__block_id \
  --value=compactme

# 根据标签选择
thanos tools bucket label \
  --objstore.config-file=objstore.yml \
  --metric=environment \
  --value=production \
  --selector='__block_id=compactme'

Compactor 的标签选择:

# Compactor 仅处理特定标签的块
thanos:
  compactor:
    # 标签选择器
    block-sync-concurrency: 20
    # 忽略指定标签的块
    block-label-drop:
      - unneeded-label
    # 选择要压缩的块
    block-files-concurrency: 10

External Labels 配置:

# 每个 Sidecar/Receiver 的 externalLabels
thanos:
  sidecar:
    externalLabels:
      cluster: prod-us-east
      prometheus_replica: $(POD_NAME)
      replica: 0

  receiver:
    externalLabels:
      cluster: prod-us-east
      receiver: $(POD_NAME)
27 Thanos 的 Query Frontend 缓存策略是什么?

答案:

Thanos Query Frontend 为 Query 组件添加查询结果缓存层,提升高并发场景下的查询性能。

架构:

graph TD
    GF["Grafana"] --> QF["Query Frontend (HTTP)"]
    QF -->|缓存查询结果| Cache["Cache<br/>(Memcached/Redis/内存)"]
    Cache --> TQ["Thanos Query (gRPC)"]
    TQ --> SG["Store Gateway / Sidecar"]

缓存配置:

thanos:
  queryFrontend:
    enabled: true
    # 缓存后端
    cache:
      type: memcached
      config:
        addresses:
          - memcached:11211
        timeout: 500ms
        maxItemSize: 1MB
    # 缓存配置
    splitQueriesByInterval: 24h
    maxRetries: 3
    # 响应缓存
    responseCacheSize: 100MB
    responseCacheTTL: 10m

缓存命中策略:

缓存命中条件:
  - 完全相同的 PromQL 查询
  - 相同的标签匹配器
  - 相同的时间范围
  - 相同的 Step

缓存失效:
  - TTL 过期(默认 10 分钟)
  - 手动清理(DELETE /cache)
  - 缓存容量满(LRU 淘汰)
28 Thanos 的 Objstore 数据块生命周期是什么?

答案:

Thanos 数据块在对象存储中经历完整的生命周期,从上传到最终删除。

生命周期阶段:

阶段 1: 上载
  Sidecar/Receiver → 对象存储
  状态: 不可查询(未超过一致性延迟)
  延迟: 30 分钟(consistencyDelay)

阶段 2: 可用
  状态: 可通过 Store Gateway 查询
  持续: 直到被 Compactor 处理

阶段 3: 压缩
  Compactor 合并小 Block
  状态: 原始块被标记为删除
  查询: 过渡期内新旧块同时可用

阶段 4: 降采样
  Compactor 生成低分辨率数据
  状态: 原始数据可选保留
  查询: 根据时间范围自动选择

阶段 5: 删除
  超过保留期
  状态: 从对象存储中删除
  触发: Compactor 定期清理

时间线:

T+0h    Block 上传到对象存储
T+30m   一致性延迟结束,可查询
T+2h    小 Block 等待被合并
T+24h   首次 Compactor 处理
T+30d   原始数据保留期结束(可选删除)
T+180d  5m 降采样保留期结束
T+365d  1h 降采样保留期结束
29 Thanos 的压缩和降采样存储格式是什么样的?

答案:

Thanos 的降采样数据在保留时序特征的同时大幅压缩数据量,格式与原始 Prometheus Block 兼容。

降采样数据格式:

graph TD
    subgraph Raw["原始块 (Raw)"]
        R1["时间序列: 15s 分辨率<br/>样本: 20,000 点/天/序列<br/>大小: ~1MB/块"]
    end
    subgraph DS5m["5m 降采样块"]
        D1["时间序列: 5m 分辨率<br/>聚合函数: min/max/avg<br/>样本: 288 点/天/序列<br/>大小: ~50KB/块<br/>数据量: 原始 x 1/20"]
    end
    subgraph DS1h["1h 降采样块"]
        H1["时间序列: 1h 分辨率<br/>聚合函数: min/max/avg<br/>样本: 24 点/天/序列<br/>大小: ~4KB/块<br/>数据量: 原始 x 1/240"]
    end
    Raw --> DS5m --> DS1h

存储内容对比:

# 原始数据查询
avg by (instance) (rate(node_cpu_seconds_total[5m]))
# 返回: 15s 精度的时序数据

# 降采样数据查询(自动选择)
avg by (instance) (rate(node_cpu_seconds_total[5m]))
# 30-180d 范围: 返回 5m 精度的聚合数据
# > 180d 范围: 返回 1h 精度的聚合数据
30 Thanos 的升级策略和滚动升级方式是什么?

答案:

Thanos 各组件的升级策略不同,无状态组件支持滚动升级,有状态组件需注意数据兼容性。

升级顺序:

推荐升级顺序(从底层到上层):

1. 对象存储(无变化,S3/GCS 自动兼容)

2. Store Gateway(无状态,先升级)
   - 不影响现有查询
   - 新版本自动重启

3. Compactor(有状态,需注意)
   - 等待当前压缩任务完成
   - 升级后自动检测未合并的块
   - 数据格式兼容性检查

4. Ruler(有状态,滚动升级)
   - 多副本轮替
   - 规则文件兼容性检查

5. Sidecar(与 Prometheus 同 Pod)
   - 滚动升级 Prometheus + Sidecar
   - 检查 Sidecar 版本兼容性

6. Query(无状态,最后升级)
   - 确保 Store 组件已就绪
   - 新版本兼容旧版 Store API

滚动升级配置:

# K8s Deployment 滚动更新
query:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

store:
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1

compactor:
  # Compactor 建议先排空再升级
  lifecycle:
    preStop:
      exec:
        command: ["thanos", "tools", "bucket", "cleanup"]

升级前检查:

1. 阅读 Release Notes
   - API 变更
   - 配置废弃
   - 数据格式兼容性

2. 备份配置
   - Helm values
   - 对象存储配置

3. 验证兼容性
   - 多组件版本依赖
   - Store API 版本

4. 灰度升级
   - 先在测试环境验证
   - 关注关键指标