做AI模型部署监控的人，大概率都参与过这种讨论：“Prometheus、Grafana、Datadog到底选哪个？”每次这种话题都能吵上几十层楼，支持哪个的都有。我自己的观点是：这个问题从一开始就问偏了，因为这三样东西根本不在同一个层次上。把它们的架构定位弄清楚之后，答案会自己冒出来。这篇文章就从一个架构师的视角，把AI模型部署监控场景下的工具选型链路整体过一遍，适合正在搭推理服务监控、做可观测性方案评审，或者帮机器学习平台组挑监控工具的朋友参考。1. 为什么AI模型监控选型要先看链路再看工具1.1 从通用监控到模型监控：指标结构发生了质变传统Web服务的监控思路很简单，翻来覆去就是那套RED和USE方法：请求速率（Rate）、错误数（Errors）、耗时（Duration），再配上一堆CPU、内存、磁盘这类利用率指标。这套模型在普通业务服务上已经非常成熟，任何监控工具都能给你搞定。但是模型推理服务上线之后，你真正关心的问题变了：模型服务的Pod是不是还活着，这是最基础的。GPU利用率是不是长期顶着上限跑？显存会不会被某个大Batch打爆？当前并发数是不是让推理队列开始堆积了？P95时延在输入序列变长的时候是怎么恶化的？线上模型版本的预测置信度有没有异常波动？不同模型版本在同样的流量下，吞吐差异到底有多大？这些问题里，只有一半是通用监控工具能覆盖的。像GPU利用率和推理时延这类指标，工具本身没有能力凭空生成，必须依赖推理引擎暴露出来。而目前主流推理引擎暴露指标的方式几乎是清一色的Prometheus格式，这一点会在后面第三章详细展开。这个生态位差异直接影响着你后续的落地成本和适配工作量。还有一个容易忽略的点：监控工具只是负责“把指标运过来、存下来、画出来、报警出去”。模型漂移计算、置信度统计这类逻辑，必须由模型服务自己算好再暴露出来，监控平台本身不会替你算。所以在选型时，不要指望换了工具就能自动获得模型健康度监控能力，工具解决的是数据链路问题，不是算法问题。1.2 三个工具的定位层次完全不同我用一个生活化的类比来说明。Prometheus是仓库管理员，负责把货物收进来、登记入册、按规则分门别类存放，你随时能查到哪批货在哪个货架。Grafana是展厅设计师，它不亲自去搬货，而是把各个仓库里的货物按照你的想法摆在同一个橱窗里，做出漂亮的陈列效果。Datadog则是整套物业公司，连门禁、访客、消防、保洁都给你包了，前提是你得按月交物业费。放到AI模型部署监控这个具体场景里：Prometheus解决的是“指标能不能稳定进得来、存得下、查得动”的问题。Grafana解决的是“多个来源的指标能不能在一张图上清晰对比、统一告警”的问题。Datadog解决的是“团队不想自己维护监控设施，能否开箱即用快速看到全局”的问题。这三件事不是竞争关系，而是互补关系。所以每次有人问“到底选哪个”，我都会反问：你的瓶颈在哪一层？如果你的指标根本进不来，再好的可视化也没有用。如果指标都进来了但你看起来费劲，那Grafana就是刚需。如果你连维护Prometheus服务器的人手都没有，那SaaS方案自然进入候选。2. Prometheus、Grafana、Datadog各自到底强在哪2.1 Prometheus：带标签的时序数据底座Prometheus本质是一个时序数据库加采集器加查询引擎的组合体。它不负责展示，但负责把时间序列数据按照指标名和标签体系组织起来。所谓标签，就是一组key-value，例如model_name="sentiment-v1"、model_version="v1.2"、instance_id="pod-abc123"。一个指标名加上一组标签，就构成一条独立的时间序列。AI模型监控场景里，这套标签体系非常顺手。比如你想看某个版本模型的P95时延，PromQL一句话就能算出来。如果想按部署环境切分，再加一个deploy_env="prod"的标签就行。相比传统监控那种只能按机器IP分组的模式，标签体系让模型维度、版本维度、环境维度的自由组合变得极其自然。它还有一个巨大的先天优势：与Kubernetes的集成深度。模型推理服务现在基本都跑在K8s上，Pod的IP会频繁变化，Prometheus通过服务发现机制可以自动发现新Pod并开始采集，不需要你手工注册目标。某个模型服务扩容到10个副本，Prometheus会自动把这10个目标全部纳管。这在Agent推模型方案里往往需要额外配置容器层采集规则。它的短板也很明显：长期存储和水平扩展需要额外组件。单个Prometheus实例适合中小规模，数据量上来之后内存压力大，通常要引入Thanos、VictoriaMetrics或Cortex来解决远程存储和全局查询。这个代价不算小，但很多团队的模型指标规模还远没到需要这套体系的程度，一台普通服务器就能扛住一整个推理平台的指标。2.2 Grafana：连接一切可视化与告警编排层Grafana最大的价值在于“数据源集成”。它不采集任何指标，却支持几十种数据源：Prometheus、Elasticsearch、云厂商监控、MySQL、甚至Datadog的指标也可以通过API接进来。这意味着你可以把基础设施指标、模型推理指标、业务日志分析结果放在同一张Dashboard上做关联对比。在模型监控实践中，这个能力非常实用。例如线上事故排查时，你往往需要同时看三个维度：模型服务的推理时延曲线、GPU节点负载、业务侧的错误日志数量。如果没有Grafana，你可能要来回切换好几个控制台，手动对齐时间轴。而Grafana把这些维度拉到同一视图里，各数据源共享同一个时间范围，鼠标滑到某个时间点就能同时看到所有指标的变化。Grafana的告警能力在过去几年也已经成熟，支持从多个数据源拉取数据做告警判断，并把结果统一路由。不过我这里要提醒一句：如果你的监控体系里已经有Prometheus和Alertmanager，我通常建议告警还是交给Alertmanager负责。原因很简单，避免两套告警引擎同时配置造成的重复通知和规则漂移。Grafana这层就专注于可视化，需要多数据源联合告警时再启用它的告警功能也不迟。2.3 Datadog：算法托底的全栈SaaS监控方案Datadog提供的是完整的一站式观测平台：基础设施监控、APM链路追踪、日志管理、安全检测、SLO跟踪、异常检测告警，全都有。部署方式是在每台主机或每个K8s节点上安装Agent，由Agent主动把数据推送到Datadog云端。对AI模型监控来说，Datadog能提供不少开箱即用的集成，比如GPU节点监控和主流云厂商的K8s服务集成都是比较成熟的能力。它也有面向模型监控的产品能力，但就我接触过的实际项目来看，真正到模型层指标时，大多数场景仍然需要你通过SDK上报自定义指标。它并不会因为你跑了个Triton模型服务，就把推理时延、吞吐、排队数这些自动给你补齐。Datadog的优势在于“快”。团队规模大、业务线多、需要快速搭建全栈可观测性的时候，装Agent、配集成、看大盘、设告警，这一套流程在商业化支持下可以走得非常顺。它的告警系统里有异常检测算法，能自动学习指标基线，对模型时延这类波动大、走势受流量明显影响的指标来说，确实比固定阈值的告警更省心。代价就是成本。它的计费维度是按主机数、日志量、自定义指标数、APM span数等多个口径累加的，规模上去之后账单增长非常快。我后面专门有一节会展开讲成本失控的教训。3. 五个关键维度的横向对比与选型理解3.1 数据采集形态：Pull模型与Agent推模型的哲学差异Prometheus采用拉取模型，由Prometheus服务器定时访问目标服务的/metrics端点，把数据抓回来。Datadog则是每台机器上装一个Agent，由Agent把数据主动推送到云端。这两种模式各有各的适用场景，但对K8s环境里的模型服务来说，拉取模型有一个很实在的优势：采集状态是透明的。Prometheus的Targets页面里，你能直接看到每个目标当前是UP还是DOWN。如果一个模型服务Pod挂了或者/metrics接口响应超时，Prometheus会明确告诉你采集失败，这也是一种监控信号。而Agent推模型如果Agent进程挂了、网络断了，云端的指标曲线就会静默中断，你往往要过一会儿才发现“怎么这条曲线没数据了”。当然，拉模型在需要跨越NAT或防火墙采集内网目标时会比较难受，那时候需要额外部署Pushgateway来中转。但模型推理服务绝大多数跑在K8s集群内部，Prometheus也部署在同一集群或同一VPC内，这个限制在AI模型监控场景里基本不构成问题。3.2 模型服务集成深度：从推理引擎到metrics端点这是选型中技术含量最高、也最容易被人忽略的一个维度。你选的监控工具如果和推理引擎的指标生态不匹配，那所有后续工作都会变成“给通用工具打补丁”。以目前主流推理引擎为例，它们的指标暴露方式基本都朝向Prometheus格式：推理引擎指标暴露方式采集方式典型指标NVIDIA Triton内置/metrics端点Prometheus直接拉取GPU利用率、推理请求数、推理耗时vLLM内置/metrics端点Prometheus直接拉取每秒token数、排队请求数、运行时内存TorchServe内置metrics APIPrometheus拉取或Agent适配请求耗时、模型加载状态、worker数量自定义FastAPI服务通过prometheus_client暴露Prometheus直接拉取自定义业务指标、耗时直方图这意味着什么？意味着如果你选用Prometheus作为数据底座，模型服务层的指标接入几乎不用额外开发。推理引擎已经把/metrics端点暴露出来了，Prometheus配一条抓取规则就能开始采集。而如果选用Datadog这类SaaS平台，理论上也能通过Agent自定义检查模块或DogStatsD上报来获取这些指标，但需要你为每个模型服务写额外的采集适配代码。这也是为什么很多团队最终选择开源方案的核心原因之一：生态已经替你铺好了路。3.3 告警编排与SLO闭环的差别模型服务的告警和普通Web服务有个明显区别：时延和吞吐指标的波动性更大，容易受流量洪峰影响。你设置的阈值一不小心就会被正常的业务高峰击穿，导致告警轰炸。Prometheus生态里，告警由Alertmanager负责。它的编排能力很强，支持路由分组、静默、抑制。你可以把模型告警按服务、按团队分组路由，也可以设置某个模型版本切流期间的静默窗口。但它的异常检测能力基本为零，依赖你手工设置PromQL表达式阈值。Datadog的告警与SLO体系则更“重”一些。它的异常检测算法会学习历史基线，产生动态阈值，对模型这种周期性明显、波动剧烈的指标确实更友好。同时SLO跟踪可以和告警联动，直接在界面上看到“过去30天模型P95时延SLO达成率还剩多少”。Grafana告警则是中间态，适合多数据源聚合判断的场景。比如说，你希望在Prometheus指标达到某个条件、且日志系统中同时间出现某种错误时才触发告警，Grafana的告警规则能更容易地表达这种跨源逻辑。不过我还是那个建议：中小团队保持单一告警引擎，别在一个监控体系里同时维护两套告警规则，否则排查告警风暴时会先把自己搞疯。3.4 多集群、规模扩展与成本增长模型推理平台发展到一定规模，往往要有多个K8s集群承载不同环境、不同租户的模型服务。这时候监控数据的统一查询就变成一个挑战。单机Prometheus在多个集群场景下会出现数据孤岛问题。解决的常规路径是引入Thanos或VictoriaMetrics，把多个Prometheus的数据汇聚到一个统一的查询入口；或者更简单一点，让Grafana同时接多个Prometheus数据源，用其“跨数据源联合查询”能力帮你在同一张面板里展示不同集群的数据。这种方案能撑到多久，取决于你要聚合的集群规模和查询复杂度。Datadog天然不需要你考虑跨集群问题，因为所有数据最终都在云端汇聚。多环境、多区域、多云的模型服务指标天然统一在一个租户空间里。如果你团队模型平台跨了好几个云厂商，又不想自己折腾联邦查询和远程存储，这种SaaS的聚合价值就体现出来了。成本方面，我按数量级说说我的经验。自建Prometheus加Grafana的硬件成本很低，几台服务器就能跑得很稳，真正贵的是维护这套系统的人力成本：写PromQL、调告警阈值、处理高基数问题、保证TSDB稳定，都需要持续投入。Datadog的成本是显性且可预测的订阅费用，但增长曲线很陡。一般情况下，几十台主机的规模起步费用还不算夸张，一旦日志、APM、自定义指标几个计费维度叠加，账单会比基础订阅费翻好几倍。3.5 让人又爱又恨的高基数问题标签体系是Prometheus的灵魂，也是它最容易踩爆内存的地方。我见过不止一个团队，因为给指标加了一个动态标签，直接把Prometheus内存打满。举个具体例子：假设你的平台有50个模型版本，每个版本3个副本，分布在3个环境里，标签组合是model_name x model_version x instance_id x deploy_env，一共450条时间序列。每个模型服务暴露50个指标，总时间序列规模大约2.25万条，这对Prometheus来说是小意思。但如果有人图方便，把请求ID作为标签加进去，情况立刻失控。假设每秒新增1000个请求，每个请求都产生一条新的标签组合，Prometheus每秒就要新增上千条时间序列，内存会像漏水一样往外流。正确的做法是把高基数数据放进日志系统或用Counter累加，而不是塞进标签里。Datadog那边也有类似问题，虽然它的标签系统不是严格采用高基数时序存储，但自定义指标上报量过大时，账单会给你颜色看。所以无论选哪个，设计指标标签时都应该只保留有限的、有业务筛选价值的维度，比如模型名、版本号、部署环境，而不是具体到某次请求或某个用户。4. 架构师视角的选型决策框架4.1 按团队规模和预算分档我给过很多团队做监控方案评审，发现一个规律：选型失败的原因往往不是工具不好，而是没有匹配团队的实际运维能力。这里我按团队规模简单分三类。小型团队，两三个人，运维能力有限，模型服务五六个以内。我一般直接建议Prometheus加Grafana的组合。理由很简单：免费、落地快、推理引擎原生指标能直接拉。哪怕团队成员之前没接触过Prometheus，花半天时间也能把最基本的面板和告警跑起来。中型平台组，有五到十五人的运维或MLOps团队，要支撑几十个模型服务的稳定运行。这时候仍然用Prometheus加Grafana，但需要把规范做起来：指标的命名规范、标签使用规范、告警规则代码化管理。如果跨集群查询的需求出现了，再考虑引入Thanos这类扩展组件。大型团队，有预算、有人力、又要求快速交付跨多云环境的可观测性。Datadog可以作为候选，但前提是数据合规允许数据进入第三方云平台。如果允许，它能大幅缩短搭建周期，让多个业务线共用一套监控体系。如果数据合规卡死，那不管它再好用，也只能在私有化方案里做取舍。4.2 按模型服务形态和场景选择AI模型部署的形态差异很大，这不只是部署方式的不同，还会直接影响监控指标的结构。实时在线推理服务，面向线上请求，最关心时延、吞吐、GPU利用率。这类场景Prometheus加Grafana已经完全够用。推理引擎暴露的指标覆盖度高，自建成本又低，没必要引入商业SaaS。LLM推理服务，比如用vLLM部署的模型，要监控每秒token生成速率、排队请求数、上下文长度分布、超时率。这些指标vLLM自己已经在暴露Prometheus格式了。你在自建体系里加一条抓取规则就能拿到数据，这种“原生适配”带来的便利性是很直观的。离线批量推理任务，关注的是吞吐能力和队列堆积，监控需求反而简单。这种情况下用不用SaaS都无所谓，关键在于指标能不能保留足够长的历史周期用于容量规划。多租户推理平台，需要做租户维度的指标隔离和权限控制。Prometheus本身没有租户隔离能力，要靠Grafana的文件夹权限和标签设计来实现。Datadog的RBAC体系更完善，对多团队协作更友好，但这又回到预算和合规问题。4.3 混合路径：开源打底、SaaS补充有一种很务实的做法值得推荐：先自建Prometheus加Grafana把地基打好，后续某个阶段再视预算和需求引入SaaS做补充。我实际接触过不少团队是这种思路。他们用Prometheus作为权威数据源，所有模型指标、告警规则、面板模板都在开源体系里沉淀成可维护的资产。后来因为跨云统一观察和更强大的异常检测需求，引入Datadog，但关键指标仍然保留在自建体系里。这样即使SaaS某个区域入口出现故障，自建监控仍然可以兜底，同时两套体系形成了双保险。这套做法的核心价值在于：指标名、标签设计、告警阈值这些你在开源体系里沉淀出来的资产，将来切到任何SaaS产品时都可以平移。迁移成本主要集中在数据采集链路，而不是指标口径的重新定义。5. 一套可直接落地的Prometheus+Grafana模型监控实操5.1 模型服务侧暴露监控指标以一个用Python写的模型推理服务为例。假设你用的是FastAPI或普通Python服务，通过prometheus_client暴露指标。这大概是最常见也最标准的方式。from prometheus_client import start_http_server, Histogram, Counter import random import time INFER_LATENCY = Histogram( "model_infer_latency_seconds", "模型推理耗时", buckets=(0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0), labelnames=["model_name", "model_version"], ) INFER_TOTAL = Counter( "model_infer_requests_total", "模型推理请求总数", labelnames=["model_name", "model_version"], ) def infer(model_name, model_version, x): with INFER_LATENCY.labels(model_name, model_version).time(): time.sleep(random.uniform(0.02, 0.1)) INFER_TOTAL.labels(model_name, model_version).inc() return x * 2 if __name__ == "__main__": start_http_server(8000) while True: infer("sentiment-v1", "v1.2", 10) time.sleep(1)这里有两个设计细节值得注意。第一，Histogram的buckets我选了从10毫秒到10秒的区间，这个区间覆盖了大多数在线推理服务的时延分布。如果你的模型很重、单次推理耗时普遍在秒级，需要把buckets整体调大到几十秒甚至几分钟。第二，标签只用了model_name和model_version两个维度，既方便查询又不会造成高基数问题。5.2 Prometheus采集配置与关键查询Prometheus端只需要配一条抓取规则。写一个最简单的prometheus.yml：global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: "model-service" metrics_path: /metrics static_configs: - targets: ["localhost:8000"]这里要特别提醒：localhost:8000只是一个示例，实际部署时targets要填模型服务真实可达的IP和端口。很多人在第一次搭的时候踩过这个坑——Prometheus跑在容器里，localhost指向的是容器自己，结果永远抓不到模型服务。更多情况下模型服务跑在K8s里，配置会写成基于kubernetes_sd_config的服务发现。那种写法的好处是Pod启停自动感知，不需要手动维护目标列表。但对本地实验和快速验证来说，static_configs完全够用。采集起来之后，几个最常用的PromQL查询：# 每分钟推理请求量 sum(rate(model_infer_requests_total[1m])) by (model_name) # P95推理时延 histogram_quantile( 0.95, sum(rate(model_infer_latency_seconds_bucket[5m])) by (le, model_name) ) # 请求错误率（假设你统计了error状态） sum(rate(model_infer_requests_total{status="error"}[5m])) / sum(rate(model_infer_requests_total[5m]))P95时延这个查询几乎每个模型监控面板上都有，它的含义是有95%的请求时延在返回的数值以内。直方图加分位数的组合，比单纯算平均时延更能反映尾部延迟的劣化情况。5.3 Grafana接线与告警规则Grafana这边要做的事情很简单：添加一个Prometheus数据源，填入Prometheus服务的地址。之后你就可以在Explore页面里直接执行上面的PromQL，或者创建一个全新的Dashboard，把查询一个个加进去。面板设置里有一个容易踩的坑：建议把“Min step”设置为15秒或更大，否则图表在查询长时间范围时会因为数据点过密而渲染很慢。另一个就是时区设置，多团队协同时统一用UTC或服务器本地时间，否则排查问题时大家对时间线会对不上。告警规则建议写成代码，放在Prometheus配置文件里统一管理。举一个实际的模型告警例子：groups: - name: model-inference-alerts rules: - alert: ModelPredictP99TooHigh expr: | histogram_quantile( 0.99, sum(rate(model_infer_latency_seconds_bucket[5m])) by (le, model_name) ) > 1.5 for: 10m labels: severity: page annotations: summary: "模型推理P99时延超过1.5秒"注意这里的for: 10m，意思是P99时延必须连续超过阈值10分钟才触发告警。这个参数非常关键，它能过滤掉瞬时尖峰造成的误报。我在实际运维中最常调整的就是这个值，流量波动大的模型服务，for设置5到15分钟都很常见。6. 常见问题与排查心得6.1 抓不到指标、高基数爆炸、告警误报模型监控落地过程中，几个高频问题我几乎在每次协助排查时都会遇到。第一个问题是Prometheus的Targets页面显示目标Down。遇到这种情况，先做的不是怀疑Prometheus配置，而是直接访问http://模型服务IP:端口/metrics看有没有响应。如果浏览器能打开，那问题通常在Prometheus到目标之间的网络链路或防火墙规则。如果打不开，优先看服务进程是不是没起来、端口是不是绑定了错误的网络接口。这个排查路径虽然听起来基础，但能省掉大量浪费在配置修改上的时间。第二个问题是高基数引发的TSDB内存暴涨。前面已经讲过动态标签的危害。真出问题时，用Prometheus内置的/api/v1/status/tsdb接口能查到当前时间序列排名前几的标签组合，快速定位是谁在制造高基数。定位到之后，把动态标签从采集端拿掉，Prometheus的内存会在下一个小时左右逐渐降下来。第三个问题是告警误报。除了调大for持续时间，还可以考虑在告警表达式中加宽时间窗口，比如用[5m]或[10m]的rate区间，吸收短时间内的抖动。另外，模型发布和切流的时候记得在Alertmanager里设置静默，否则版本切换期间的指标波动会把你半夜从床上叫起来。6.2 Datadog成本失控与SaaS协作的现实问题用Datadog的团队，最大的抱怨基本集中在两个字上：账单。模型推理平台是出了名的指标大户，GPU、时延、吞吐、日志一叠加，用量很容易超出预期。我的建议是，在正式采购之前，先拿自己实际的主机清单、日志量估计值、自定义指标数量去询价，而不是直接看官网标注的“单主机起价”。很多团队在初期只看了单主机价格觉得很划算，等到APM、日志、RUM等模块全部打开之后，账单就降不下来了。另外，SaaS模式还会遇到一个数据合规的硬约束。有些行业要求所有监控数据不得出公司内网，这种情况下无论Datadog多好用都只能放弃。这不是工具能力问题，而是架构边界的约束。自建Prometheus加Grafana反而是最稳妥的选择。6.3 场景速查表与落地建议我把前面讨论的内容浓缩成一张速查表，方便你在评审方案时直接对照。场景推荐方案核心理由1-2人团队，5个以内模型服务Prometheus + Grafana免费、快速，推理引擎原生指标可直接拉取中型推理平台，多K8s集群Prometheus + Grafana + Thanos数据不出内网，跨集群统一查询，成本可控大型团队，需要快速全栈可观测性Datadog开箱即用，异常检测和APM能力强，但要评估长线成本强合规私有化部署开源自建方案数据完全内网闭环，不存在出网风险已有Prometheus，想提升可视化体验接入Grafana纯叠加方案，不动采集链路，风险最低日常维护中还有一个小技巧：监控指标和告警规则也应该像代码一样做版本管理。把prometheus.yml、告警规则文件、Grafana面板JSON都放到Git仓库里，每次变更走MR评审。这个习惯能让监控体系的演进过程变得可追溯，也方便新成员快速了解平台里到底监控了什么。所以每次有人问我选型，我反而会先问他另一个问题：你的团队未来半年里，线上模型出问题时，你希望能在多长时间内定位到根因？这个问题想清楚之后，Prometheus、Grafana、Datadog这几个名字就不再是竞争关系，而是你手里可以用来组合的积木。先把数据链路和指标规范设计好，再根据预算、人力和合规要求决定用哪几块积木，这个顺序比单纯比较工具功能清单要靠谱得多。最后再分享一个经验：无论你最后选了哪个方案，指标命名、标签规范和告警阈值的沉淀，才是监控体系里最值钱的资产。工具可以换，但这些设计只要做得好，到了任何平台上都能复用。我自己做选型的时候，花最多时间的地方不是比功能，而是把指标口径梳理清楚，这个工作会在后续的每一个阶段给你带来回报。
做AI模型部署监控的人，大概率都参与过这种讨论：“Prometheus、Grafana、Datadog到底选哪个？”每次这种话题都能吵上几十层楼，支持哪个的都有。我自己的观点是：这个问题从一开始就问偏了，因为这三样东西根本不在同一个层次上。把它们的架构定位弄清楚之后，答案会自己冒出来。这篇文章就从一个架构师的视角，把AI模型部署监控场景下的工具选型链路整体过一遍，适合正在搭推理服务监控、做可观测性方案评审，或者帮机器学习平台组挑监控工具的朋友参考。1. 为什么AI模型监控选型要先看链路再看工具1.1 从通用监控到模型监控：指标结构发生了质变传统Web服务的监控思路很简单，翻来覆去就是那套RED和USE方法：请求速率（Rate）、错误数（Errors）、耗时（Duration），再配上一堆CPU、内存、磁盘这类利用率指标。这套模型在普通业务服务上已经非常成熟，任何监控工具都能给你搞定。但是模型推理服务上线之后，你真正关心的问题变了：模型服务的Pod是不是还活着，这是最基础的。GPU利用率是不是长期顶着上限跑？显存会不会被某个大Batch打爆？当前并发数是不是让推理队列开始堆积了？P95时延在输入序列变长的时候是怎么恶化的？线上模型版本的预测置信度有没有异常波动？不同模型版本在同样的流量下，吞吐差异到底有多大？这些问题里，只有一半是通用监控工具能覆盖的。像GPU利用率和推理时延这类指标，工具本身没有能力凭空生成，必须依赖推理引擎暴露出来。而目前主流推理引擎暴露指标的方式几乎是清一色的Prometheus格式，这一点会在后面第三章详细展开。这个生态位差异直接影响着你后续的落地成本和适配工作量。还有一个容易忽略的点：监控工具只是负责“把指标运过来、存下来、画出来、报警出去”。模型漂移计算、置信度统计这类逻辑，必须由模型服务自己算好再暴露出来，监控平台本身不会替你算。所以在选型时，不要指望换了工具就能自动获得模型健康度监控能力，工具解决的是数据链路问题，不是算法问题。1.2 三个工具的定位层次完全不同我用一个生活化的类比来说明。Prometheus是仓库管理员，负责把货物收进来、登记入册、按规则分门别类存放，你随时能查到哪批货在哪个货架。Grafana是展厅设计师，它不亲自去搬货，而是把各个仓库里的货物按照你的想法摆在同一个橱窗里，做出漂亮的陈列效果。Datadog则是整套物业公司，连门禁、访客、消防、保洁都给你包了，前提是你得按月交物业费。放到AI模型部署监控这个具体场景里：Prometheus解决的是“指标能不能稳定进得来、存得下、查得动”的问题。Grafana解决的是“多个来源的指标能不能在一张图上清晰对比、统一告警”的问题。Datadog解决的是“团队不想自己维护监控设施，能否开箱即用快速看到全局”的问题。这三件事不是竞争关系，而是互补关系。所以每次有人问“到底选哪个”，我都会反问：你的瓶颈在哪一层？如果你的指标根本进不来，再好的可视化也没有用。如果指标都进来了但你看起来费劲，那Grafana就是刚需。如果你连维护Prometheus服务器的人手都没有，那SaaS方案自然进入候选。2. Prometheus、Grafana、Datadog各自到底强在哪2.1 Prometheus：带标签的时序数据底座Prometheus本质是一个时序数据库加采集器加查询引擎的组合体。它不负责展示，但负责把时间序列数据按照指标名和标签体系组织起来。所谓标签，就是一组key-value，例如model_name="sentiment-v1"、model_version="v1.2"、instance_id="pod-abc123"。一个指标名加上一组标签，就构成一条独立的时间序列。AI模型监控场景里，这套标签体系非常顺手。比如你想看某个版本模型的P95时延，PromQL一句话就能算出来。如果想按部署环境切分，再加一个deploy_env="prod"的标签就行。相比传统监控那种只能按机器IP分组的模式，标签体系让模型维度、版本维度、环境维度的自由组合变得极其自然。它还有一个巨大的先天优势：与Kubernetes的集成深度。模型推理服务现在基本都跑在K8s上，Pod的IP会频繁变化，Prometheus通过服务发现机制可以自动发现新Pod并开始采集，不需要你手工注册目标。某个模型服务扩容到10个副本，Prometheus会自动把这10个目标全部纳管。这在Agent推模型方案里往往需要额外配置容器层采集规则。它的短板也很明显：长期存储和水平扩展需要额外组件。单个Prometheus实例适合中小规模，数据量上来之后内存压力大，通常要引入Thanos、VictoriaMetrics或Cortex来解决远程存储和全局查询。这个代价不算小，但很多团队的模型指标规模还远没到需要这套体系的程度，一台普通服务器就能扛住一整个推理平台的指标。2.2 Grafana：连接一切可视化与告警编排层Grafana最大的价值在于“数据源集成”。它不采集任何指标，却支持几十种数据源：Prometheus、Elasticsearch、云厂商监控、MySQL、甚至Datadog的指标也可以通过API接进来。这意味着你可以把基础设施指标、模型推理指标、业务日志分析结果放在同一张Dashboard上做关联对比。在模型监控实践中，这个能力非常实用。例如线上事故排查时，你往往需要同时看三个维度：模型服务的推理时延曲线、GPU节点负载、业务侧的错误日志数量。如果没有Grafana，你可能要来回切换好几个控制台，手动对齐时间轴。而Grafana把这些维度拉到同一视图里，各数据源共享同一个时间范围，鼠标滑到某个时间点就能同时看到所有指标的变化。Grafana的告警能力在过去几年也已经成熟，支持从多个数据源拉取数据做告警判断，并把结果统一路由。不过我这里要提醒一句：如果你的监控体系里已经有Prometheus和Alertmanager，我通常建议告警还是交给Alertmanager负责。原因很简单，避免两套告警引擎同时配置造成的重复通知和规则漂移。Grafana这层就专注于可视化，需要多数据源联合告警时再启用它的告警功能也不迟。2.3 Datadog：算法托底的全栈SaaS监控方案Datadog提供的是完整的一站式观测平台：基础设施监控、APM链路追踪、日志管理、安全检测、SLO跟踪、异常检测告警，全都有。部署方式是在每台主机或每个K8s节点上安装Agent，由Agent主动把数据推送到Datadog云端。对AI模型监控来说，Datadog能提供不少开箱即用的集成，比如GPU节点监控和主流云厂商的K8s服务集成都是比较成熟的能力。它也有面向模型监控的产品能力，但就我接触过的实际项目来看，真正到模型层指标时，大多数场景仍然需要你通过SDK上报自定义指标。它并不会因为你跑了个Triton模型服务，就把推理时延、吞吐、排队数这些自动给你补齐。Datadog的优势在于“快”。团队规模大、业务线多、需要快速搭建全栈可观测性的时候，装Agent、配集成、看大盘、设告警，这一套流程在商业化支持下可以走得非常顺。它的告警系统里有异常检测算法，能自动学习指标基线，对模型时延这类波动大、走势受流量明显影响的指标来说，确实比固定阈值的告警更省心。代价就是成本。它的计费维度是按主机数、日志量、自定义指标数、APM span数等多个口径累加的，规模上去之后账单增长非常快。我后面专门有一节会展开讲成本失控的教训。3. 五个关键维度的横向对比与选型理解3.1 数据采集形态：Pull模型与Agent推模型的哲学差异Prometheus采用拉取模型，由Prometheus服务器定时访问目标服务的/metrics端点，把数据抓回来。Datadog则是每台机器上装一个Agent，由Agent把数据主动推送到云端。这两种模式各有各的适用场景，但对K8s环境里的模型服务来说，拉取模型有一个很实在的优势：采集状态是透明的。Prometheus的Targets页面里，你能直接看到每个目标当前是UP还是DOWN。如果一个模型服务Pod挂了或者/metrics接口响应超时，Prometheus会明确告诉你采集失败，这也是一种监控信号。而Agent推模型如果Agent进程挂了、网络断了，云端的指标曲线就会静默中断，你往往要过一会儿才发现“怎么这条曲线没数据了”。当然，拉模型在需要跨越NAT或防火墙采集内网目标时会比较难受，那时候需要额外部署Pushgateway来中转。但模型推理服务绝大多数跑在K8s集群内部，Prometheus也部署在同一集群或同一VPC内，这个限制在AI模型监控场景里基本不构成问题。3.2 模型服务集成深度：从推理引擎到metrics端点这是选型中技术含量最高、也最容易被人忽略的一个维度。你选的监控工具如果和推理引擎的指标生态不匹配，那所有后续工作都会变成“给通用工具打补丁”。以目前主流推理引擎为例，它们的指标暴露方式基本都朝向Prometheus格式：推理引擎指标暴露方式采集方式典型指标NVIDIA Triton内置/metrics端点Prometheus直接拉取GPU利用率、推理请求数、推理耗时vLLM内置/metrics端点Prometheus直接拉取每秒token数、排队请求数、运行时内存TorchServe内置metrics APIPrometheus拉取或Agent适配请求耗时、模型加载状态、worker数量自定义FastAPI服务通过prometheus_client暴露Prometheus直接拉取自定义业务指标、耗时直方图这意味着什么？意味着如果你选用Prometheus作为数据底座，模型服务层的指标接入几乎不用额外开发。推理引擎已经把/metrics端点暴露出来了，Prometheus配一条抓取规则就能开始采集。而如果选用Datadog这类SaaS平台，理论上也能通过Agent自定义检查模块或DogStatsD上报来获取这些指标，但需要你为每个模型服务写额外的采集适配代码。这也是为什么很多团队最终选择开源方案的核心原因之一：生态已经替你铺好了路。3.3 告警编排与SLO闭环的差别模型服务的告警和普通Web服务有个明显区别：时延和吞吐指标的波动性更大，容易受流量洪峰影响。你设置的阈值一不小心就会被正常的业务高峰击穿，导致告警轰炸。Prometheus生态里，告警由Alertmanager负责。它的编排能力很强，支持路由分组、静默、抑制。你可以把模型告警按服务、按团队分组路由，也可以设置某个模型版本切流期间的静默窗口。但它的异常检测能力基本为零，依赖你手工设置PromQL表达式阈值。Datadog的告警与SLO体系则更“重”一些。它的异常检测算法会学习历史基线，产生动态阈值，对模型这种周期性明显、波动剧烈的指标确实更友好。同时SLO跟踪可以和告警联动，直接在界面上看到“过去30天模型P95时延SLO达成率还剩多少”。Grafana告警则是中间态，适合多数据源聚合判断的场景。比如说，你希望在Prometheus指标达到某个条件、且日志系统中同时间出现某种错误时才触发告警，Grafana的告警规则能更容易地表达这种跨源逻辑。不过我还是那个建议：中小团队保持单一告警引擎，别在一个监控体系里同时维护两套告警规则，否则排查告警风暴时会先把自己搞疯。3.4 多集群、规模扩展与成本增长模型推理平台发展到一定规模，往往要有多个K8s集群承载不同环境、不同租户的模型服务。这时候监控数据的统一查询就变成一个挑战。单机Prometheus在多个集群场景下会出现数据孤岛问题。解决的常规路径是引入Thanos或VictoriaMetrics，把多个Prometheus的数据汇聚到一个统一的查询入口；或者更简单一点，让Grafana同时接多个Prometheus数据源，用其“跨数据源联合查询”能力帮你在同一张面板里展示不同集群的数据。这种方案能撑到多久，取决于你要聚合的集群规模和查询复杂度。Datadog天然不需要你考虑跨集群问题，因为所有数据最终都在云端汇聚。多环境、多区域、多云的模型服务指标天然统一在一个租户空间里。如果你团队模型平台跨了好几个云厂商，又不想自己折腾联邦查询和远程存储，这种SaaS的聚合价值就体现出来了。成本方面，我按数量级说说我的经验。自建Prometheus加Grafana的硬件成本很低，几台服务器就能跑得很稳，真正贵的是维护这套系统的人力成本：写PromQL、调告警阈值、处理高基数问题、保证TSDB稳定，都需要持续投入。Datadog的成本是显性且可预测的订阅费用，但增长曲线很陡。一般情况下，几十台主机的规模起步费用还不算夸张，一旦日志、APM、自定义指标几个计费维度叠加，账单会比基础订阅费翻好几倍。3.5 让人又爱又恨的高基数问题标签体系是Prometheus的灵魂，也是它最容易踩爆内存的地方。我见过不止一个团队，因为给指标加了一个动态标签，直接把Prometheus内存打满。举个具体例子：假设你的平台有50个模型版本，每个版本3个副本，分布在3个环境里，标签组合是model_name x model_version x instance_id x deploy_env，一共450条时间序列。每个模型服务暴露50个指标，总时间序列规模大约2.25万条，这对Prometheus来说是小意思。但如果有人图方便，把请求ID作为标签加进去，情况立刻失控。假设每秒新增1000个请求，每个请求都产生一条新的标签组合，Prometheus每秒就要新增上千条时间序列，内存会像漏水一样往外流。正确的做法是把高基数数据放进日志系统或用Counter累加，而不是塞进标签里。Datadog那边也有类似问题，虽然它的标签系统不是严格采用高基数时序存储，但自定义指标上报量过大时，账单会给你颜色看。所以无论选哪个，设计指标标签时都应该只保留有限的、有业务筛选价值的维度，比如模型名、版本号、部署环境，而不是具体到某次请求或某个用户。4. 架构师视角的选型决策框架4.1 按团队规模和预算分档我给过很多团队做监控方案评审，发现一个规律：选型失败的原因往往不是工具不好，而是没有匹配团队的实际运维能力。这里我按团队规模简单分三类。小型团队，两三个人，运维能力有限，模型服务五六个以内。我一般直接建议Prometheus加Grafana的组合。理由很简单：免费、落地快、推理引擎原生指标能直接拉。哪怕团队成员之前没接触过Prometheus，花半天时间也能把最基本的面板和告警跑起来。中型平台组，有五到十五人的运维或MLOps团队，要支撑几十个模型服务的稳定运行。这时候仍然用Prometheus加Grafana，但需要把规范做起来：指标的命名规范、标签使用规范、告警规则代码化管理。如果跨集群查询的需求出现了，再考虑引入Thanos这类扩展组件。大型团队，有预算、有人力、又要求快速交付跨多云环境的可观测性。Datadog可以作为候选，但前提是数据合规允许数据进入第三方云平台。如果允许，它能大幅缩短搭建周期，让多个业务线共用一套监控体系。如果数据合规卡死，那不管它再好用，也只能在私有化方案里做取舍。4.2 按模型服务形态和场景选择AI模型部署的形态差异很大，这不只是部署方式的不同，还会直接影响监控指标的结构。实时在线推理服务，面向线上请求，最关心时延、吞吐、GPU利用率。这类场景Prometheus加Grafana已经完全够用。推理引擎暴露的指标覆盖度高，自建成本又低，没必要引入商业SaaS。LLM推理服务，比如用vLLM部署的模型，要监控每秒token生成速率、排队请求数、上下文长度分布、超时率。这些指标vLLM自己已经在暴露Prometheus格式了。你在自建体系里加一条抓取规则就能拿到数据，这种“原生适配”带来的便利性是很直观的。离线批量推理任务，关注的是吞吐能力和队列堆积，监控需求反而简单。这种情况下用不用SaaS都无所谓，关键在于指标能不能保留足够长的历史周期用于容量规划。多租户推理平台，需要做租户维度的指标隔离和权限控制。Prometheus本身没有租户隔离能力，要靠Grafana的文件夹权限和标签设计来实现。Datadog的RBAC体系更完善，对多团队协作更友好，但这又回到预算和合规问题。4.3 混合路径：开源打底、SaaS补充有一种很务实的做法值得推荐：先自建Prometheus加Grafana把地基打好，后续某个阶段再视预算和需求引入SaaS做补充。我实际接触过不少团队是这种思路。他们用Prometheus作为权威数据源，所有模型指标、告警规则、面板模板都在开源体系里沉淀成可维护的资产。后来因为跨云统一观察和更强大的异常检测需求，引入Datadog，但关键指标仍然保留在自建体系里。这样即使SaaS某个区域入口出现故障，自建监控仍然可以兜底，同时两套体系形成了双保险。这套做法的核心价值在于：指标名、标签设计、告警阈值这些你在开源体系里沉淀出来的资产，将来切到任何SaaS产品时都可以平移。迁移成本主要集中在数据采集链路，而不是指标口径的重新定义。5. 一套可直接落地的Prometheus+Grafana模型监控实操5.1 模型服务侧暴露监控指标以一个用Python写的模型推理服务为例。假设你用的是FastAPI或普通Python服务，通过prometheus_client暴露指标。这大概是最常见也最标准的方式。from prometheus_client import start_http_server, Histogram, Counter import random import time INFER_LATENCY = Histogram( "model_infer_latency_seconds", "模型推理耗时", buckets=(0.01, 0.025, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0), labelnames=["model_name", "model_version"], ) INFER_TOTAL = Counter( "model_infer_requests_total", "模型推理请求总数", labelnames=["model_name", "model_version"], ) def infer(model_name, model_version, x): with INFER_LATENCY.labels(model_name, model_version).time(): time.sleep(random.uniform(0.02, 0.1)) INFER_TOTAL.labels(model_name, model_version).inc() return x * 2 if __name__ == "__main__": start_http_server(8000) while True: infer("sentiment-v1", "v1.2", 10) time.sleep(1)这里有两个设计细节值得注意。第一，Histogram的buckets我选了从10毫秒到10秒的区间，这个区间覆盖了大多数在线推理服务的时延分布。如果你的模型很重、单次推理耗时普遍在秒级，需要把buckets整体调大到几十秒甚至几分钟。第二，标签只用了model_name和model_version两个维度，既方便查询又不会造成高基数问题。5.2 Prometheus采集配置与关键查询Prometheus端只需要配一条抓取规则。写一个最简单的prometheus.yml：global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: "model-service" metrics_path: /metrics static_configs: - targets: ["localhost:8000"]这里要特别提醒：localhost:8000只是一个示例，实际部署时targets要填模型服务真实可达的IP和端口。很多人在第一次搭的时候踩过这个坑——Prometheus跑在容器里，localhost指向的是容器自己，结果永远抓不到模型服务。更多情况下模型服务跑在K8s里，配置会写成基于kubernetes_sd_config的服务发现。那种写法的好处是Pod启停自动感知，不需要手动维护目标列表。但对本地实验和快速验证来说，static_configs完全够用。采集起来之后，几个最常用的PromQL查询：# 每分钟推理请求量 sum(rate(model_infer_requests_total[1m])) by (model_name) # P95推理时延 histogram_quantile( 0.95, sum(rate(model_infer_latency_seconds_bucket[5m])) by (le, model_name) ) # 请求错误率（假设你统计了error状态） sum(rate(model_infer_requests_total{status="error"}[5m])) / sum(rate(model_infer_requests_total[5m]))P95时延这个查询几乎每个模型监控面板上都有，它的含义是有95%的请求时延在返回的数值以内。直方图加分位数的组合，比单纯算平均时延更能反映尾部延迟的劣化情况。5.3 Grafana接线与告警规则Grafana这边要做的事情很简单：添加一个Prometheus数据源，填入Prometheus服务的地址。之后你就可以在Explore页面里直接执行上面的PromQL，或者创建一个全新的Dashboard，把查询一个个加进去。面板设置里有一个容易踩的坑：建议把“Min step”设置为15秒或更大，否则图表在查询长时间范围时会因为数据点过密而渲染很慢。另一个就是时区设置，多团队协同时统一用UTC或服务器本地时间，否则排查问题时大家对时间线会对不上。告警规则建议写成代码，放在Prometheus配置文件里统一管理。举一个实际的模型告警例子：groups: - name: model-inference-alerts rules: - alert: ModelPredictP99TooHigh expr: | histogram_quantile( 0.99, sum(rate(model_infer_latency_seconds_bucket[5m])) by (le, model_name) ) > 1.5 for: 10m labels: severity: page annotations: summary: "模型推理P99时延超过1.5秒"注意这里的for: 10m，意思是P99时延必须连续超过阈值10分钟才触发告警。这个参数非常关键，它能过滤掉瞬时尖峰造成的误报。我在实际运维中最常调整的就是这个值，流量波动大的模型服务，for设置5到15分钟都很常见。6. 常见问题与排查心得6.1 抓不到指标、高基数爆炸、告警误报模型监控落地过程中，几个高频问题我几乎在每次协助排查时都会遇到。第一个问题是Prometheus的Targets页面显示目标Down。遇到这种情况，先做的不是怀疑Prometheus配置，而是直接访问http://模型服务IP:端口/metrics看有没有响应。如果浏览器能打开，那问题通常在Prometheus到目标之间的网络链路或防火墙规则。如果打不开，优先看服务进程是不是没起来、端口是不是绑定了错误的网络接口。这个排查路径虽然听起来基础，但能省掉大量浪费在配置修改上的时间。第二个问题是高基数引发的TSDB内存暴涨。前面已经讲过动态标签的危害。真出问题时，用Prometheus内置的/api/v1/status/tsdb接口能查到当前时间序列排名前几的标签组合，快速定位是谁在制造高基数。定位到之后，把动态标签从采集端拿掉，Prometheus的内存会在下一个小时左右逐渐降下来。第三个问题是告警误报。除了调大for持续时间，还可以考虑在告警表达式中加宽时间窗口，比如用[5m]或[10m]的rate区间，吸收短时间内的抖动。另外，模型发布和切流的时候记得在Alertmanager里设置静默，否则版本切换期间的指标波动会把你半夜从床上叫起来。6.2 Datadog成本失控与SaaS协作的现实问题用Datadog的团队，最大的抱怨基本集中在两个字上：账单。模型推理平台是出了名的指标大户，GPU、时延、吞吐、日志一叠加，用量很容易超出预期。我的建议是，在正式采购之前，先拿自己实际的主机清单、日志量估计值、自定义指标数量去询价，而不是直接看官网标注的“单主机起价”。很多团队在初期只看了单主机价格觉得很划算，等到APM、日志、RUM等模块全部打开之后，账单就降不下来了。另外，SaaS模式还会遇到一个数据合规的硬约束。有些行业要求所有监控数据不得出公司内网，这种情况下无论Datadog多好用都只能放弃。这不是工具能力问题，而是架构边界的约束。自建Prometheus加Grafana反而是最稳妥的选择。6.3 场景速查表与落地建议我把前面讨论的内容浓缩成一张速查表，方便你在评审方案时直接对照。场景推荐方案核心理由1-2人团队，5个以内模型服务Prometheus + Grafana免费、快速，推理引擎原生指标可直接拉取中型推理平台，多K8s集群Prometheus + Grafana + Thanos数据不出内网，跨集群统一查询，成本可控大型团队，需要快速全栈可观测性Datadog开箱即用，异常检测和APM能力强，但要评估长线成本强合规私有化部署开源自建方案数据完全内网闭环，不存在出网风险已有Prometheus，想提升可视化体验接入Grafana纯叠加方案，不动采集链路，风险最低日常维护中还有一个小技巧：监控指标和告警规则也应该像代码一样做版本管理。把prometheus.yml、告警规则文件、Grafana面板JSON都放到Git仓库里，每次变更走MR评审。这个习惯能让监控体系的演进过程变得可追溯，也方便新成员快速了解平台里到底监控了什么。所以每次有人问我选型，我反而会先问他另一个问题：你的团队未来半年里，线上模型出问题时，你希望能在多长时间内定位到根因？这个问题想清楚之后，Prometheus、Grafana、Datadog这几个名字就不再是竞争关系，而是你手里可以用来组合的积木。先把数据链路和指标规范设计好，再根据预算、人力和合规要求决定用哪几块积木，这个顺序比单纯比较工具功能清单要靠谱得多。最后再分享一个经验：无论你最后选了哪个方案，指标命名、标签规范和告警阈值的沉淀，才是监控体系里最值钱的资产。工具可以换，但这些设计只要做得好，到了任何平台上都能复用。我自己做选型的时候，花最多时间的地方不是比功能，而是把指标口径梳理清楚，这个工作会在后续的每一个阶段给你带来回报。