查询指标和日志

TensorFusion 把指标和组件日志存进 GreptimeDB，每类数据就是一张普通的表。仪表盘或告警给的信息不够时，可以直接用 SQL 查这些表。本页说明怎么连接、有哪些表，并给出几条可以直接改着用的查询。

前置条件

有 GreptimeDB 所在命名空间的 kubectl 权限。Helm chart 默认在 greptimedb 命名空间装一个单机版 GreptimeDB（greptime.installStandalone: true）。
想在终端里查询的话，本机要有 mysql 客户端；只用浏览器则不需要。

如果 TensorFusion 接的是 GreptimeDB Cloud 或你自己的实例（greptime.isCloud: true 或 greptime.installStandalone: false），到那个实例里执行同样的查询，表结构一样。

有哪些表

表	写入方	一行数据是什么
`tf_gpu_usage`	hypervisor	一张物理 GPU 的实际用量：算力和显存百分比、温度、功耗、PCIe 和 NVLink 流量
`tf_worker_usage`	hypervisor	一个 worker 在一张 GPU 上的实际用量，以及算力被限流、显存冻结和恢复的累计次数
`tf_worker_resources`	controller	一个 worker 的请求值和限制值、QoS 等级和原始成本
`tf_gpu_metrics`	controller	一张 GPU 的总量、已分配量和可用量（TFLOPS 和显存）
`tf_gpu_allocation`	controller	一个 Pod 分到了哪些 GPU
`tf_node_metrics`	controller	一个 GPU 节点已分配的 TFLOPS 和显存，含绝对值和百分比
`tf_pool_metrics`	controller	整个资源池的同一组分配数据
`tf_system_metrics`	controller	每个资源池的累计计数：worker 数、节点数、分配成功和失败次数、扩容和缩容次数
`tf_system_log`	vector	TensorFusion 组件的一行日志

所有表的时间列都是 greptime_timestamp。由早期版本建出来的表可能仍是 ts，用 DESC TABLE <表名> 可以确认。各组件大约每分钟写一次指标。数据默认保留 30 天，由 Helm values 里的 dynamicConfig.metricsTTL 控制。

每张表的全部字段见指标参考。

采集 hypervisor 指标和日志

controller Pod 里始终带一个 vector sidecar，所以 controller 写的表和 controller 自己的日志不需要额外配置。

tf_gpu_usage、tf_worker_usage 两张表，以及 hypervisor 和 worker Pod 的日志，由每个 hypervisor Pod 里的 vector sidecar 上报。只有资源池设置了 componentConfig.hypervisor.enableVector: true，并且在 Pod 模板里为它声明了第二个容器，这个 sidecar 才会存在。chart 创建的 TensorFusionCluster 没有这两项配置，所以默认安装下这两张表是空的。

给 chart 创建的集群的第一个资源池打开 sidecar：

kubectl patch tensorfusioncluster tensor-fusion --type=json -p='[
  {"op":"add","path":"/spec/gpuPools/0/specTemplate/componentConfig/hypervisor/enableVector","value":true},
  {"op":"add","path":"/spec/gpuPools/0/specTemplate/componentConfig/hypervisor/podTemplate/template/spec/containers/-","value":{"name":"vector"}}
]'

两个操作缺一不可。只设 enableVector: true 而模板里仍只有一个容器时，controller 会丢弃模板里对 hypervisor 容器的配置。

这次修改会改变 hypervisor 的 Pod 模板，controller 随后分批替换各节点的 hypervisor Pod，过程见组件更新。完成后每个 hypervisor Pod 有两个容器：

kubectl get pods -n tensor-fusion-sys -l tensor-fusion.ai/component=hypervisor

chart 没有对应的 value。每次 helm upgrade 之后请再确认一遍这项配置还在。

查询示例

最近 10 分钟每张 GPU 的用量：

SELECT node, uuid,
       avg(compute_percentage) AS compute_pct,
       avg(memory_percentage)  AS vram_pct,
       max(temperature)        AS max_temp
FROM tf_gpu_usage
WHERE greptime_timestamp >= now() - '10m'::INTERVAL
GROUP BY node, uuid;

每个节点分配出去了多少：

SELECT node, pool,
       avg(allocated_tflops_percent) AS tflops_allocated_pct,
       avg(allocated_vram_percent)   AS vram_allocated_pct
FROM tf_node_metrics
WHERE greptime_timestamp >= now() - '10m'::INTERVAL
GROUP BY node, pool;

最近 1 小时内触到算力上限的 worker：

SELECT workload, worker, node, uuid,
       max(compute_throttled_cnt) - min(compute_throttled_cnt) AS throttled
FROM tf_worker_usage
WHERE greptime_timestamp >= now() - '1h'::INTERVAL
GROUP BY workload, worker, node, uuid
HAVING throttled > 0;

最近 1 小时各资源池的调度失败次数：

SELECT pool,
       max(total_allocation_fail_cnt) - min(total_allocation_fail_cnt) AS failures
FROM tf_system_metrics
WHERE greptime_timestamp >= now() - '1h'::INTERVAL
GROUP BY pool;

controller 最近 30 分钟里带 error 的日志：

SELECT greptime_timestamp, pod, message
FROM tf_system_log
WHERE component = 'operator'
  AND greptime_timestamp >= now() - '30m'::INTERVAL
  AND message LIKE '%error%'
ORDER BY greptime_timestamp DESC
LIMIT 50;

component 取自 Pod 标签 tensor-fusion.ai/component 的值：operator、hypervisor 或 worker。

查不到数据时

现象	原因	处理
`tf_gpu_usage`、`tf_worker_usage` 为空或不存在，其他表有数据	hypervisor 的 vector sidecar 没打开	见采集 hypervisor 指标和日志
所有 `tf_*` 表都没有新数据	controller 的 vector sidecar 连不上 GreptimeDB	查看 `kubectl logs -n tensor-fusion-sys deploy/tensor-fusion-sys-controller -c vector`，并核对 Helm value `greptime.host`
早于某个时间点的数据没有了	超过了 `dynamicConfig.metricsTTL` 的保留期	调大该值后升级 release

下一步

配置告警：告警规则就是针对这些表的 SQL 查询。
优化 GPU 效率：用这些数据调整工作负载的资源配置、回收空闲节点。
问题处理手册：按现象排查问题。

前置条件

有 GreptimeDB 所在命名空间的 kubectl 权限。Helm chart 默认在 greptimedb 命名空间装一个单机版 GreptimeDB（greptime.installStandalone: true）。
想在终端里查询的话，本机要有 mysql 客户端；只用浏览器则不需要。

连接 GreptimeDB

临时查询用自带的 dashboard，写脚本用 MySQL 协议。

Dashboard

kubectl port-forward -n greptimedb svc/greptimedb-standalone 4000:4000

浏览器打开 http://localhost:4000/dashboard，数据库选 public。

MySQL 客户端

kubectl port-forward -n greptimedb svc/greptimedb-standalone 4002:4002
mysql -h 127.0.0.1 -P 4002 -u root public

单机版没有设密码。连上后列出所有表，确认连接正常：

SHOW TABLES;

结果里应该有下面这些 tf_* 表。

有哪些表

表	写入方	一行数据是什么
`tf_gpu_usage`	hypervisor	一张物理 GPU 的实际用量：算力和显存百分比、温度、功耗、PCIe 和 NVLink 流量
`tf_worker_usage`	hypervisor	一个 worker 在一张 GPU 上的实际用量，以及算力被限流、显存冻结和恢复的累计次数
`tf_worker_resources`	controller	一个 worker 的请求值和限制值、QoS 等级和原始成本
`tf_gpu_metrics`	controller	一张 GPU 的总量、已分配量和可用量（TFLOPS 和显存）
`tf_gpu_allocation`	controller	一个 Pod 分到了哪些 GPU
`tf_node_metrics`	controller	一个 GPU 节点已分配的 TFLOPS 和显存，含绝对值和百分比
`tf_pool_metrics`	controller	整个资源池的同一组分配数据
`tf_system_metrics`	controller	每个资源池的累计计数：worker 数、节点数、分配成功和失败次数、扩容和缩容次数
`tf_system_log`	vector	TensorFusion 组件的一行日志

每张表的全部字段见指标参考。

采集 hypervisor 指标和日志

controller Pod 里始终带一个 vector sidecar，所以 controller 写的表和 controller 自己的日志不需要额外配置。

给 chart 创建的集群的第一个资源池打开 sidecar：

kubectl patch tensorfusioncluster tensor-fusion --type=json -p='[
  {"op":"add","path":"/spec/gpuPools/0/specTemplate/componentConfig/hypervisor/enableVector","value":true},
  {"op":"add","path":"/spec/gpuPools/0/specTemplate/componentConfig/hypervisor/podTemplate/template/spec/containers/-","value":{"name":"vector"}}
]'

两个操作缺一不可。只设 enableVector: true 而模板里仍只有一个容器时，controller 会丢弃模板里对 hypervisor 容器的配置。

这次修改会改变 hypervisor 的 Pod 模板，controller 随后分批替换各节点的 hypervisor Pod，过程见组件更新。完成后每个 hypervisor Pod 有两个容器：

kubectl get pods -n tensor-fusion-sys -l tensor-fusion.ai/component=hypervisor

chart 没有对应的 value。每次 helm upgrade 之后请再确认一遍这项配置还在。

查询示例

最近 10 分钟每张 GPU 的用量：

SELECT node, uuid,
       avg(compute_percentage) AS compute_pct,
       avg(memory_percentage)  AS vram_pct,
       max(temperature)        AS max_temp
FROM tf_gpu_usage
WHERE greptime_timestamp >= now() - '10m'::INTERVAL
GROUP BY node, uuid;

每个节点分配出去了多少：

SELECT node, pool,
       avg(allocated_tflops_percent) AS tflops_allocated_pct,
       avg(allocated_vram_percent)   AS vram_allocated_pct
FROM tf_node_metrics
WHERE greptime_timestamp >= now() - '10m'::INTERVAL
GROUP BY node, pool;

最近 1 小时内触到算力上限的 worker：

SELECT workload, worker, node, uuid,
       max(compute_throttled_cnt) - min(compute_throttled_cnt) AS throttled
FROM tf_worker_usage
WHERE greptime_timestamp >= now() - '1h'::INTERVAL
GROUP BY workload, worker, node, uuid
HAVING throttled > 0;

最近 1 小时各资源池的调度失败次数：

SELECT pool,
       max(total_allocation_fail_cnt) - min(total_allocation_fail_cnt) AS failures
FROM tf_system_metrics
WHERE greptime_timestamp >= now() - '1h'::INTERVAL
GROUP BY pool;

controller 最近 30 分钟里带 error 的日志：

SELECT greptime_timestamp, pod, message
FROM tf_system_log
WHERE component = 'operator'
  AND greptime_timestamp >= now() - '30m'::INTERVAL
  AND message LIKE '%error%'
ORDER BY greptime_timestamp DESC
LIMIT 50;

component 取自 Pod 标签 tensor-fusion.ai/component 的值：operator、hypervisor 或 worker。

查不到数据时

现象	原因	处理
`tf_gpu_usage`、`tf_worker_usage` 为空或不存在，其他表有数据	hypervisor 的 vector sidecar 没打开	见采集 hypervisor 指标和日志
所有 `tf_*` 表都没有新数据	controller 的 vector sidecar 连不上 GreptimeDB	查看 `kubectl logs -n tensor-fusion-sys deploy/tensor-fusion-sys-controller -c vector`，并核对 Helm value `greptime.host`
早于某个时间点的数据没有了	超过了 `dynamicConfig.metricsTTL` 的保留期	调大该值后升级 release

下一步

配置告警：告警规则就是针对这些表的 SQL 查询。
优化 GPU 效率：用这些数据调整工作负载的资源配置、回收空闲节点。
问题处理手册：按现象排查问题。

前置条件

连接 GreptimeDB

有哪些表

采集 hypervisor 指标和日志

查询示例

查不到数据时

下一步

目录

查询指标和日志

前置条件

连接 GreptimeDB

有哪些表

采集 hypervisor 指标和日志

查询示例

查不到数据时

下一步

目录