Prometheus 监控 OpenTSDB 深度实战：让 HBase 上的时序引擎透明可观测

---

OpenTSDB 是构建在 HBase 之上的经典分布式时序数据库，承载着监控、物联网等海量历史数据。但自身性能与健康常被忽视——TSD 延迟、HBase RPC 超时、JVM GC 停顿、连接数 等问题一旦发生，会直接污染监控数据本身。Prometheus 通过社区维护的 opentsdb_exporter，可以将 OpenTSDB 的内部统计转为标准指标，让这套基石般的存储层也暴露在统一的可观测性之下。本文将带你从零部署导出器，到构建可视化与告警，全面掌控 OpenTSDB 的运行状态。

---

1. 为什么需要监控 OpenTSDB？

• 写入路径健康：TSD 处理多少点、是否有丢弃或 RPC 错误。
• 查询性能：HTTP 查询延迟、并发连接数，直接影响 Grafana 面板加载速度。
• 资源使用：JVM 堆内存、线程数、GC 频率，HBase 客户端的连接池状态。
• 容量规划：已存储的数据点趋势、HBase region 负载等（通常结合 HBase 监控）。

---

2. 方案选型：opentsdb_exporter

OpenTSDB 本身提供 HTTP API 返回线程状态、统计计数等（通过 /api/stats、/api/threads），但输出为 JSON 且格式非 Prometheus 标准。社区方案是部署 opentsdb_exporter（prometheus-community/opentsdb_exporter 或类似项目），它会定期拉取 TSD 的统计数据并转化为指标。该导出器通常作为一个独立的轻量进程，连接到 OpenTSDB 的 HTTP 端口（默认 4242），然后暴露 /metrics 供 Prometheus 抓取。

---

3. 部署 opentsdb_exporter

3.1 使用 Docker（推荐）

docker run -d \
  --name opentsdb_exporter \
  -p 9123:9123 \
  -e OPENTSDB_TSD_URL="http://opentsdb-host:4242" \
  prometheuscommunity/opentsdb-exporter:latest

如果要监控多个 TSD 实例，可启动多个容器分别指定不同的 OPENTSDB_TSD_URL，或者使用导出器的多目标模式（若版本支持）。

3.2 二进制部署

从 GitHub releases 下载对应的二进制文件，并设置环境变量运行：

export OPENTSDB_TSD_URL=http://localhost:4242
./opentsdb_exporter --web.listen-address=:9123

访问 http://localhost:9123/metrics，应看到如 opentsdb_tsd_rpc_received_total、opentsdb_tsd_http_requests_total 等指标。

---

4. 配置 Prometheus 抓取

在 prometheus.yml 中添加 Job：

scrape_configs:
  - job_name: 'opentsdb'
    scrape_interval: 30s
    static_configs:
      - targets:
          - 'exporter-host:9123'
        labels:
          instance: 'opentsdb-prod'
          cluster: 'tsdb-cluster1'

如果有多个 TSD 节点，为每个实例启动单独的导出器并添加为多个 target。

---

5. 核心监控指标与 PromQL

导出的指标大多带有 opentsdb_tsd_ 前缀，直接反映 TSD 的内部计数器与测量值。

分类	关键指标	含义	PromQL 示例
RPC 流量	opentsdb_tsd_rpc_received_total	TSD 接收的 RPC 总数（Counter）	rate(opentsdb_tsd_rpc_received_total[1m]) 得 RPC 速率
	opentsdb_tsd_rpc_timed_out_total	RPC 超时次数	rate(... [5m]) > 0 表示有超时
HTTP 请求	opentsdb_tsd_http_requests_total	HTTP API 请求总数	rate(opentsdb_tsd_http_requests_total[1m])
	opentsdb_tsd_http_latency_seconds (Histogram)	HTTP 请求延迟分布	P99 延迟：histogram_quantile(0.99, rate(opentsdb_tsd_http_latency_seconds_bucket[5m]))
写入队列	opentsdb_tsd_rpc_queue_size	当前等待处理的 RPC 队列长度	持续 > 0 表示 TSD 繁忙
HBase 操作	opentsdb_tsd_hbase_rpc_latency_seconds (Histogram)	HBase RPC 延迟	P95 延迟过高需优化 HBase
	opentsdb_tsd_hbase_errors_total	HBase 操作错误总数	任何增长应立即告警
JVM/系统	jvm_memory_bytes_used / jvm_memory_bytes_max	堆内存使用/上限	使用率 > 85% 告警
	jvm_threads_current	当前线程数	异常飙升可能由死锁或连接泄漏引起
	jvm_gc_pause_seconds (Histogram)	GC 暂停时间	rate(jvm_gc_pause_seconds_sum[5m]) / rate(jvm_gc_pause_seconds_count[5m])
连接	opentsdb_tsd_connections_open	当前打开的连接数	接近配置的最大连接数时告警

指标名可能因导出器版本而异，请以实际 /metrics 输出为准。许多导出器还会暴露 Go 运行时指标。

重要计算示例：

• 写入点速率：rate(opentsdb_tsd_rpc_received_total[1m])
• HTTP 错误率：sum(rate(opentsdb_tsd_http_requests_total{code=~"5.."}[5m])) / sum(rate(opentsdb_tsd_http_requests_total[5m]))
• HBase 错误率：rate(opentsdb_tsd_hbase_errors_total[5m])

---

6. Grafana 仪表盘推荐

目前没有官方唯一指定 Dashboard，但社区有适配 opentsdb_exporter 的仪表板：

• OpenTSDB Dashboard：Dashboard ID 11327（基于 Prometheus 的 OpenTSDB 监控），包含 TSD 吞吐、延迟、队列、HBase RPC、JVM 内存等。
• 自建面板：可基于上述指标快速创建，重点展示写入速率、HTTP 查询 P99、JVM 堆使用率。

导入后选择数据源，将 instance 变量映射至你的 OpenTSDB 实例。

---

7. 告警规则实战

groups:
  - name: opentsdb_alerts
    rules:
      - alert: OpenTSDBExporterDown
        expr: up{job="opentsdb"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "OpenTSDB 导出器或 TSD 实例 {{ $labels.instance }} 不可达"

      - alert: OpenTSDBHighRpcQueue
        expr: opentsdb_tsd_rpc_queue_size > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "TSD RPC 队列持续积压，当前长度: {{ $value }}"

      - alert: OpenTSDBRpcTimeout
        expr: rate(opentsdb_tsd_rpc_timed_out_total[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "TSD RPC 出现超时"

      - alert: OpenTSDBHighHttpLatency
        expr: histogram_quantile(0.99, rate(opentsdb_tsd_http_latency_seconds_bucket[5m])) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "HTTP 请求 P99 延迟超过 2 秒"

      - alert: OpenTSDBHBaseErrors
        expr: rate(opentsdb_tsd_hbase_errors_total[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "TSD 访问 HBase 发生错误"

      - alert: OpenTSDBJvmHeapUsageHigh
        expr: (jvm_memory_bytes_used{area="heap"} / jvm_memory_bytes_max{area="heap"}) > 0.85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "TSD JVM 堆使用率超过 85%"

---

8. 进阶：多 TSD 集群、安全与 HBase 监控联动

8.1 监控多个 TSD

在典型的读写分离架构中，可能部署了多个 TSD 实例。为每个实例启动一个 opentsdb_exporter（或使用其多目标模式），并在 Prometheus 中配置所有 target。使用 instance 标签区分节点。

8.2 安全连接

如果 OpenTSDB 启用了 HTTPS 或认证，导出器通常支持环境变量设置 TLS 证书和 token。例如：

docker run -d \
  -e OPENTSDB_TSD_URL="https://tsd-host:4242" \
  -e OPENTSDB_TLS_INSECURE_SKIP_VERIFY=true \
  ...

更安全的做法是提供 CA 证书路径。

8.3 与 HBase 监控结合

OpenTSDB 的性能瓶颈常源于底层的 HBase。建议同时部署 HBase JMX Exporter 或 HBase metrics 抓取，将 HBase 的 region server 负载、compaction 队列、handler 线程数等同屏展示。这样当 TSD 写入变慢时，能迅速区分是 TSD 自身问题还是 HBase 抖动。

---

9. 总结

通过 opentsdb_exporter，OpenTSDB 的内部统计不再尘封于日志与 /api/stats 中，而是成为 Prometheus 生态中活跃的时序指标。无论是 TSD 的 RPC 压力、HTTP 延迟，还是 JVM GC 停顿，都能实时监控并触发告警。至此，从应用、中间件、数据库到底层的时序存储系统，你的全栈可观测性拼图已经完整闭环，为数据平台的稳定运行提供坚实保障。