AI系统可观测性选型Prometheus与Grafana的「分工」与「协同」——不是选谁而是怎么用对关键词可观测性、Prometheus、Grafana、AI系统监控、指标采集、可视化分析、分布式训练摘要AI系统的复杂度远超传统应用分布式训练的梯度同步延迟、LLM推理的Token生成速率、动态资源调度的GPU利用率波动……这些问题需要精准的指标采集与直观的可视化分析才能解决。但很多工程师会混淆Prometheus与Grafana的定位——前者是「指标管家」负责收集、存储AI系统的核心运行数据后者是「数据翻译官」把冰冷的数字变成能指导决策的可视化Dashboard。本文将拆解两者的核心价值用「家庭能源监控」的生活化类比讲清技术原理结合AI场景的真实案例分布式训练/LLM推理演示实践步骤并解答你最关心的问题AI系统到底需要Prometheus还是Grafana答案是——两者协同才能发挥可观测性的最大价值。一、背景AI系统的可观测性为什么比传统应用难10倍在聊工具之前我们得先理解AI系统的「特殊需求」——这些需求决定了为什么普通监控工具比如Zabbix无法胜任。1.1 AI系统的3大监控痛点传统Web应用的核心是「请求-响应」监控的是QPS、延迟、错误率而AI系统的核心是「数据处理模型计算」监控的维度更复杂分布式训练的「协同问题」比如Transformer模型的分布式训练需要多个GPU节点同步梯度All-Reduce操作。如果某个节点的网络延迟高会导致整个训练卡住——你需要知道「哪个节点的梯度同步慢了慢了多少」LLM推理的「资源瓶颈」比如ChatGPT类服务推理延迟不仅取决于GPU性能还与KV缓存命中率、Token生成速率强相关。你需要实时看到「缓存命中率降到多少时延迟会飙升」动态场景的「不可预测性」AI系统经常运行在K8s等动态环境中——训练Job会按需创建/销毁节点推理服务会自动扩缩容。传统监控的「静态目标配置」根本跟不上。1.2 目标读者谁需要这篇文章AI工程师想监控模型训练的效率定位训练慢的原因SRE/DevOps负责AI服务的稳定性需要快速排查推理延迟高的问题技术管理者想通过数据优化资源利用率比如避免GPU闲置。1.3 核心问题我们需要什么样的工具总结下来AI系统的可观测性工具需要满足3点支持多维指标能标记「模型版本、节点ID、训练阶段」等维度比如inference_latency{modelgpt-3, nodegpu-01, phasefine-tune}适应动态环境能自动发现K8s中的临时节点无需手动配置可视化关联分析能把「GPU利用率」「梯度同步时间」「训练速度」关联起来快速定位根因。二、核心概念Prometheus与Grafana不是竞争而是「分工」很多人会问「Prometheus和Grafana哪个好」其实这是个伪命题——它们解决的是可观测性的不同环节。我们用「家庭能源监控」做个类比Prometheus 智能电表 数据仓库它会定期上门Pull模式读取每个电器的用电量指标并按「电器类型、房间、时间」分类存储Grafana 家庭能源Dashboard它从电表Prometheus中读取数据生成「客厅空调用电量趋势图」「卧室灯耗电占比饼图」让你一眼看出「哪个电器在浪费电」。2.1 可观测性的「三要素」与工具定位先明确行业标准可观测性Observability由**指标Metrics、日志Logs、追踪Traces**三部分组成称为「3M」。Prometheus和Grafana的定位如下工具聚焦环节核心功能类比Prometheus指标采集、存储、查询时间序列指标智能电表仓库Grafana可视化连接数据源、生成Dashboard、配置告警能源监控屏2.2 用Mermaid流程图看数据流向AI系统的指标从产生到可视化需要经过4步AI系统训练框架/推理服务Exporter暴露指标Prometheus拉取存储指标Grafana可视化分析告警Alertmanager/ Grafana Alert关键角色解释ExporterAI系统的「指标翻译官」。比如PyTorch Exporter会把「GPU利用率」「梯度同步时间」翻译成Prometheus能理解的格式Prometheus定期从Exporter拉取指标默认15秒一次存储在时间序列数据库TSDB中Grafana连接Prometheus作为数据源用PromQL查询指标生成折线图、仪表盘等可视化告警当指标超过阈值比如GPU利用率30%Grafana或Prometheus的Alertmanager会发送通知邮件/钉钉。2.3 为什么AI系统必须用Prometheus传统监控工具比如Zabbix的「Push模式」系统主动发送指标不适合AI场景动态节点无法自动发现K8s中的训练Job会创建临时PodPush模式需要手动配置目标而Prometheus的「Pull模式服务发现」能自动识别新节点多维指标支持差Zabbix的指标是「扁平的」比如gpu_usage而Prometheus的指标带Labels比如gpu_usage{nodegpu-01, modelresnet50}能轻松按「节点、模型」筛选数据查询能力弱Zabbix的查询语言无法做复杂的时间序列分析比如「过去10分钟的平均GPU利用率」而PromQL支持丰富的聚合函数avg()、rate()。2.4 为什么AI系统必须用GrafanaPrometheus自带的Web UI只能做简单查询而Grafana的优势在于可视化定制和多数据源支持Dashboard模板Grafana社区有大量AI场景的现成Dashboard比如「PyTorch Distributed Training」「LLM Inference Monitoring」直接导入就能用变量与关联分析比如用model_version变量一键切换不同模型的指标用「热力图折线图」关联「GPU利用率」和「训练速度」多数据源整合除了PrometheusGrafana还能连接日志系统Elasticsearch、追踪系统Jaeger把「指标日志追踪」整合在一个Dashboard中——比如当「推理延迟升高」时直接查看对应时间的日志快速定位错误原因。三、技术原理从指标采集到可视化一步步拆解接下来我们深入技术细节用「LLM推理服务监控」的案例演示Prometheus与Grafana的工作流程。3.1 Prometheus指标的「采集-存储-查询」原理Prometheus的核心是时间序列数据库TSDB——每个指标都是「时间戳值Labels」的组合。比如LLM推理服务的「每秒Token生成数」指标tokens_per_second{modelgpt-3, instanceinference-01:9100, versionv1.0} → (1690848000, 120), (1690848015, 115)...3.1.1 步骤1用Exporter暴露AI指标Exporter是Prometheus与AI系统之间的「桥梁」。我们用Python写一个简单的LLM推理服务Exporter暴露3个核心指标inference_latency_seconds推理延迟Gauge类型动态变化inference_requests_total总请求数Counter类型递增tokens_per_request每个请求的Token数Gauge类型。代码实现prometheus_exporter.pyfromprometheus_clientimportstart_http_server,Gauge,Counterimporttimeimportrandom# 1. 定义指标带Labelsmodel_versioninference_latencyGauge(nameinference_latency_seconds,documentationLatency of LLM inference (per request),labelnames[model_version])inference_requestsCounter(nameinference_requests_total,documentationTotal number of inference requests,labelnames[model_version])tokens_per_requestGauge(nametokens_per_request,documentationNumber of tokens generated per request,labelnames[model_version])# 2. 模拟LLM推理服务defsimulate_inference():model_versionv1.0.0whileTrue:# 模拟延迟0.1~0.5秒、Token数50~200latencyrandom.uniform(0.1,0.5)tokensrandom.randint(50,200)# 3. 更新指标inference_latency.labels(model_versionmodel_version).set(latency)inference_requests.labels(model_versionmodel_version).inc()tokens_per_request.labels(model_versionmodel_version).set(tokens)time.sleep(1)# 每秒更新一次if__name____main__:# 启动Exporter端口9100start_http_server(9100)print(Exporter running on http://localhost:9100/metrics)simulate_inference()运行代码后访问http://localhost:9100/metrics会看到Exporter暴露的指标# HELP inference_latency_seconds Latency of LLM inference (per request) # TYPE inference_latency_seconds gauge inference_latency_seconds{model_versionv1.0.0} 0.314159 # HELP inference_requests_total Total number of inference requests # TYPE inference_requests_total counter inference_requests_total{model_versionv1.0.0} 42 # HELP tokens_per_request Number of tokens generated per request # TYPE tokens_per_request gauge tokens_per_request{model_versionv1.0.0} 1283.1.2 步骤2配置Prometheus拉取指标Prometheus通过prometheus.yml配置文件定义「要拉取哪些目标」。我们添加一个「LLM推理服务」的Jobprometheus.ymlglobal:scrape_interval:15s# 每15秒拉取一次指标scrape_configs:# Job名称LLM推理服务-job_name:llm_inferencestatic_configs:-targets:[localhost:9100]# Exporter的地址启动Prometheus后访问http://localhost:9090在「Graph」页面输入inference_latency_seconds就能看到指标的时间序列图。3.1.3 步骤3用PromQL查询指标PromQL是Prometheus的查询语言支持丰富的时间序列分析。比如计算过去1分钟的平均推理延迟avg_over_time(inference_latency_seconds[1m])计算QPS每秒请求数rate(inference_requests_total[1m])按模型版本筛选Token数tokens_per_request{model_versionv1.0.0}3.2 Grafana把指标变成「可行动的 insights」Prometheus的Web UI只能看简单的折线图而Grafana能把指标变成定制化的Dashboard甚至整合日志和追踪数据。3.2.1 步骤1连接Prometheus数据源打开Grafana默认地址http://localhost:3000账号admin/admin点击左侧「Configuration」→「Data Sources」→「Add data source」选择「Prometheus」输入Prometheus的地址http://localhost:9090点击「Save Test」。3.2.2 步骤2创建LLM推理服务Dashboard我们创建3个面板Panel分别展示推理延迟趋势用折线图展示inference_latency_seconds的变化QPS每秒请求数用仪表盘展示rate(inference_requests_total[1m])Token数分布用直方图展示tokens_per_request的分布。面板1推理延迟趋势选择「Time Series」可视化类型输入PromQL查询avg(inference_latency_seconds{model_versionv1.0.0}) by (model_version)设置「Legend」为{{model_version}}区分不同模型版本调整「Axes」→「Y Axis」的范围为0~0.5对应模拟的延迟范围。面板2QPS仪表盘选择「Gauge」可视化类型输入PromQL查询rate(inference_requests_total{model_versionv1.0.0}[1m])设置「Thresholds」为0~5绿色、5~10黄色、10红色——当QPS超过10时仪表盘变红。面板3Token数分布选择「Histogram」可视化类型输入PromQL查询histogram_quantile(0.95, sum(rate(tokens_per_request_bucket[1m])) by (le))这里需要先把tokens_per_request转换为直方图Histogram类型修改Exporter代码用Histogram代替Gaugefromprometheus_clientimportHistogram tokens_per_requestHistogram(nametokens_per_request,documentationNumber of tokens generated per request,labelnames[model_version],buckets[50,100,150,200]# 分桶50以下、50-100、100-150、150-200、200以上)3.2.3 步骤3配置告警当指标超过阈值时Grafana会发送通知比如钉钉/邮件。我们配置一个「推理延迟过高」的告警打开「推理延迟趋势」面板的「Edit」→「Alerts」设置「Condition」avg() OF query(A, 5m, now) IS ABOVE 0.4过去5分钟的平均延迟超过0.4秒设置「Notifications」选择已配置的钉钉机器人点击「Save」。3.3 数学模型Prometheus的时间序列存储Prometheus的TSDB采用按时间分片的存储方式每个分片对应2小时的数据每个时间序列的存储格式为S(metric_name,labels,[(t1,v1),(t2,v2),...,(tn,vn)]) S (metric\_name, labels, [ (t_1, v_1), (t_2, v_2), ..., (t_n, v_n) ])S(metric_name,labels,[(t1​,v1​),(t2​,v2​),...,(tn​,vn​)])其中metric_name指标名比如inference_latency_secondslabels维度标签比如model_versionv1.0.0t_i时间戳Unix时间v_i指标值浮点数。这种存储方式的优势是快速查询——比如要查询「过去1小时的inference_latency_seconds」Prometheus只需读取最近3个分片2小时×36小时覆盖1小时的数据。四、实际应用AI场景的2个经典案例理论讲完我们用2个真实场景演示如何用PrometheusGrafana解决问题。4.1 案例1分布式Transformer训练的监控问题分布式训练时某个节点的梯度同步延迟高导致整个训练速度变慢。目标定位延迟高的节点优化网络配置。4.1.1 步骤1暴露分布式训练指标用prometheus-pytorch-exporterPyTorch官方Exporter暴露以下指标pytorch_distributed_allreduce_latency_seconds梯度同步All-Reduce延迟pytorch_gpu_utilization_percentGPU利用率pytorch_train_samples_per_second每秒处理的样本数。4.1.2 步骤2Prometheus配置服务发现分布式训练的节点是动态创建的K8s Job需要用K8s的服务发现Kubernetes SDprometheus.ymlscrape_configs:-job_name:pytorch_distributedkubernetes_sd_configs:-role:pod# 发现K8s中的Podrelabel_configs:# 只选择带labelapppytorch-training的Pod-source_labels:[__meta_kubernetes_pod_label_app]regex:pytorch-trainingaction:keep# 将Pod的IP和端口作为目标地址-source_labels:[__meta_kubernetes_pod_ip,__meta_kubernetes_pod_container_port_number]separator::target_label:__address__4.1.3 步骤3Grafana Dashboard设计创建以下面板梯度同步延迟热力图用pytorch_distributed_allreduce_latency_seconds按「节点ID」分组热力图的颜色越深表示延迟越高——快速定位延迟高的节点GPU利用率折线图用pytorch_gpu_utilization_percent展示每个节点的GPU利用率——如果某个节点的GPU利用率低但延迟高说明网络有问题训练速度仪表盘用pytorch_train_samples_per_second展示整体训练速度——当延迟高时训练速度会下降。效果通过热力图发现「node-03」的梯度同步延迟是其他节点的2倍检查网络配置后发现该节点的网卡驱动未更新更新后延迟恢复正常训练速度提升30%。4.2 案例2LLM推理服务的缓存优化问题LLM推理的KV缓存命中率低导致延迟升高。目标监控缓存命中率调整缓存大小。4.2.1 步骤1暴露缓存指标用vllm高性能LLM推理框架的Exporter暴露以下指标vllm_kv_cache_hit_ratioKV缓存命中率vllm_inference_latency_seconds推理延迟vllm_gpu_memory_used_bytesGPU内存使用量。4.2.2 步骤2PromQL关联分析用PromQL查询「缓存命中率与延迟的关系」# 缓存命中率过去1分钟 avg(rate(vllm_kv_cache_hit_ratio[1m])) by (instance) # 推理延迟过去1分钟 avg(rate(vllm_inference_latency_seconds[1m])) by (instance)4.2.3 步骤3Grafana Dashboard设计创建「双轴折线图」左Y轴vllm_kv_cache_hit_ratio缓存命中率范围0~1右Y轴vllm_inference_latency_seconds推理延迟范围0~2X轴时间。效果发现当缓存命中率低于0.7时推理延迟会从0.5秒飙升到1.5秒。调整缓存大小从2GB增加到4GB后命中率提升到0.9延迟下降到0.3秒。4.3 常见问题及解决方案问题解决方案动态节点无法自动发现用K8s服务发现kubernetes_sd_configs或Consul服务发现指标太多查询慢用Prometheus的「relabel_configs」过滤不必要的指标或启用「remote write」将数据存储到云端比如Grafana CloudDashboard维护麻烦用Grafana的「模板变量」比如model_version或使用「Dashboard as Code」比如用JSON/YAML管理Dashboard五、未来展望AI可观测性的3大趋势随着AI系统的复杂度提升Prometheus与Grafana也在进化未来的可观测性会更智能、一体化、场景化。5.1 趋势1LLM驱动的智能分析Grafana正在整合LLM能力比如Grafana Copilot能自动生成PromQL查询、解释指标异常原因比如你输入「为什么推理延迟升高」Copilot会自动查询vllm_kv_cache_hit_ratio和vllm_gpu_memory_used_bytes并给出结论「延迟升高是因为KV缓存命中率从0.9降到0.6建议增加缓存大小」。5.2 趋势2多模态可观测性AI系统的「非结构化数据」比如模型输出的Embedding、特征向量也需要监控。未来Prometheus会支持「向量指标」存储Grafana会整合向量数据库比如Pinecone实现「指标向量」的关联分析比如当「用户反馈回答质量下降」时Grafana会自动关联「Embedding相似度指标」发现「最近的模型版本Embedding相似度下降了20%」从而定位问题。5.3 趋势3边缘AI的轻量级监控边缘AI比如手机、IoT设备上的模型的资源有限无法运行完整的Prometheus。未来会出现轻量级的Prometheus Agent比如Prometheus Remote Write Agent将边缘设备的指标发送到云端的Prometheus/Grafana Cloud实现「边缘-云端」的统一监控。六、总结不是选谁而是怎么用对回到最初的问题「Prometheus vs Grafana哪个更适合AI系统」答案是——两者缺一不可Prometheus是「指标地基」解决AI系统的「数据采集与存储」问题Grafana是「数据门面」解决AI系统的「可视化与分析」问题。关键结论如果你需要监控AI系统的核心指标比如GPU利用率、训练速度用Prometheus如果你需要把指标变成能指导决策的Dashboard用Grafana如果你想解决AI系统的复杂问题比如分布式训练延迟、LLM推理缓存优化用PrometheusGrafana。思考问题鼓励你进一步探索你所在的AI系统有哪些「独特的指标」需要监控比如模型的精度、特征的分布变化如何用Prometheus暴露这些指标如果你的AI系统是「边缘部署」的比如手机上的OCR模型如何调整Prometheus的采集策略如何用Grafana整合「指标日志追踪」实现「一键排查问题」参考资源Prometheus官方文档https://prometheus.io/docs/Grafana官方文档https://grafana.com/docs/PyTorch Exporterhttps://github.com/romainbsl/prometheus-pytorch-exporterVLLM Exporterhttps://github.com/vllm-project/vllm/blob/main/vllm/monitoring/prometheus_exporter.pyGrafana社区Dashboardhttps://grafana.com/grafana/dashboards/最后可观测性的核心不是「用什么工具」而是「理解你的系统需要什么数据」。Prometheus与Grafana只是工具真正的价值在于用它们发现AI系统的「隐性问题」——比如那些藏在分布式训练中的网络延迟、藏在LLM推理中的缓存瓶颈。希望这篇文章能帮你「用对」工具让AI系统的运行状态「尽在掌握」。