监控告警 2026 选型：Prometheus / Grafana / Datadog / 阿里云 SLS
分布式系统让"上线后看一眼日志就行"的时代彻底成为历史。一个普通的微服务架构可能涉及上百个 Pod、几十种中间件、跨区域多活部署，一次接口超时背后可能是数据库慢查询、消息积压、依赖服务返回 5xx 或 GC 暂停。要把这些线索串成可操作的告警，依靠的是一套完整的监控可观测性体系。Prometheus 与 Grafana 长期主导开源世界；Datadog、New Relic、Dynatrace 在商业 APM 市场上分庭抗礼；国内则有阿里云 SLS、腾讯云 CLS、火山引擎云监控承担云原生场景。本文从指标、日志、追踪三大信号出发，对比主流方案在能力、成本与国内适用性上的差异，给出 2026 年的实战选型建议。
三大信号：Metrics、Logs 与 Traces 的角色分工
指标（Metrics）是带时间戳的数值序列，比如 CPU 利用率、QPS、P99 延迟。它适合趋势观察、容量规划、异常告警，存储成本极低，但无法回答"这一次请求为什么慢"。
日志（Logs）是结构化或非结构化的事件流，能记录任意上下文，是排查具体问题的"一手资料"。劣势是体积大、检索成本高，需要索引才能保证查询速度。
追踪（Traces）记录一次请求在多个服务间的完整链路，每一段调用对应一个 Span，包含开始时间、耗时、依赖。追踪是定位分布式系统延迟根因的最佳工具。
三种信号不能互相替代。一个成熟的可观测性方案通常包含全部三种，并通过 trace_id 等关联字段彼此串联。OpenTelemetry 在过去三年迅速崛起，把三类信号统一进同一 SDK 与协议，是 2026 年事实上的接入标准。
Prometheus：拉模式时序数据库的事实标准
Prometheus 由 SoundCloud 在 2012 年开源，成为 CNCF 早期毕业项目，是目前 Kubernetes 集群的默认指标后端。它采用 Pull 模型，定期从目标 endpoint 拉取 /metrics，使用多维标签（label）的数据模型，配合 PromQL 提供强大的查询能力。
PromQL 的核心抽象是即时向量（instant vector）与区间向量（range vector）。常见模式包括 rate 计算变化率、histogram_quantile 估算分位数、sum by 聚合维度、predict_linear 做容量预测。一旦熟悉 PromQL，绝大多数告警与面板都可以表达得简洁优雅。
生态方面，Exporter 数量已经过千：node_exporter、kube-state-metrics、blackbox_exporter、mysqld_exporter、redis_exporter、jvm exporter 几乎能想到的中间件都有现成实现。Alertmanager 处理告警去重、分组、抑制、静默，与企业 IM（钉钉、飞书、企业微信）的集成已成标配。原生 Prometheus 单实例适合中小集群，规模化后建议引入 Thanos 或 VictoriaMetrics 实现长期存储与水平扩展。
Grafana：可视化、告警、统一面板
Grafana 已经超越"画图工具"，成为统一可观测性面板。它原生支持 Prometheus、Loki、Tempo、Mimir、InfluxDB、ElasticSearch、CloudWatch、SLS 等数十种数据源，可以在同一仪表板里展示指标、日志、追踪并通过 trace_id 互相跳转。
Grafana Labs 还提供完整的开源产品矩阵：Loki 做日志，Tempo 做追踪，Mimir 做大规模指标，Pyroscope 做持续剖析。这些组件与 Prometheus 协同，只用一份 Grafana 面板就能把基础设施层、应用层、业务层串联起来。Grafana Cloud 则是托管版本，免运维但按 Active Series 计费。
Grafana 的告警在 8.0 后从 Prometheus 内置告警迁移到 Grafana Unified Alerting，支持跨数据源的复合告警表达式。但许多团队仍在生产中保留 Alertmanager，因为它的去重与抑制规则更成熟。两种方案可以共存。
Datadog：商业 APM 的标杆
Datadog 是商业 SaaS 的代表。它的卖点是"一个 Agent 解决一切"——单个 Agent 同时采集主机指标、容器指标、APM、Trace、日志、网络流量、安全事件。Web 控制台高度集成，从指标点击直接跳到对应 Trace、再跳到 Trace 关联的日志，调试体验极佳。
Datadog APM 支持几十种语言运行时，自动埋点能力强；RUM 与 Synthetic Monitoring 把前端真实用户体验与主动拨测合二为一；Watchdog 提供基于机器学习的异常检测；Compliance Monitoring 做云资源合规审计。这些功能堆叠起来对企业极具吸引力，但也意味着账单复杂——主机数、Custom Metric 数、Indexed Log 数都单独计费，规模化后月费容易突破五位数美元。
国内访问 Datadog 默认走海外 Region，延迟与稳定性受国际网络影响。少数跨境企业会选择部分指标走 Datadog、核心日志走国内云，避免单点依赖。如果业务主要面向国内用户，纯 Datadog 方案的成本与合规性都不理想。
阿里云 SLS 与国内云监控对比
阿里云 SLS（日志服务）已经发展为日志、指标、追踪一站式可观测性平台。日志写入按 GB 计费，存储按月计费；指标存储与查询通过 Metric Store；Trace 服务支持 OpenTelemetry 协议直接接入。控制台开箱即用，索引可视化建立，告警规则模板丰富。
腾讯云 CLS 提供类似能力，强项是与腾讯云原生数据库、消息队列、负载均衡的深度联动；火山引擎云监控（VMP）则在抖音电商、字节跳动内部产品上经过大流量打磨，性能强、与火山生态产品集成深。华为云 LTS、AOM 也是同等级别玩家。
共同特点是：免运维、合规友好、与本厂商云资源（CCM、CDN、负载均衡、数据库）一键打通。劣势是 vendor lock-in 较重，迁出成本高。中小公司若主体上云，国内云的监控 SaaS 是性价比最高的选择；多云或混合云团队建议在云监控之上叠加 Prometheus 与 OpenTelemetry，把核心指标握在自己手中。
OpenTelemetry：跨平台统一接入
OpenTelemetry（OTel）是 CNCF 在合并 OpenTracing 与 OpenCensus 后推出的可观测性数据接入标准。它包含 SDK（覆盖主流语言）、Collector（部署在节点或集群中作为转发与处理层）、协议（OTLP，基于 gRPC/HTTP）、规范（Spec）四部分。截至 2026 年，Traces 与 Metrics 规范已稳定，Logs 规范也已 GA，主流厂商都支持 OTLP 接入。
OTel 最大的价值是解耦应用与后端。应用只需埋点 OTel SDK，把数据送给 Collector；Collector 再决定把数据发往 Tempo、Jaeger、Datadog、SLS、火山引擎等任意目标，甚至可以同时发多份。这彻底打破了"换监控平台就要重写埋点"的困境，也让多云架构有了统一的可观测性入口。
最佳实践是把 Collector 部署为 DaemonSet（每节点一份）+ Deployment（集群级别处理），结合 batch、tail-based sampling、attributes processor 实现成本与精度的平衡。Sample 率不要在 SDK 端做，统一交给 Collector，方便策略调整。
告警与值班：从触发到收敛
告警是监控的最终输出。Prometheus Alertmanager 与 Grafana Alerting 都基于路由树，根据 label 把告警分发到不同接收方（钉钉、飞书、企业微信、短信、电话）。Datadog、SLS、火山监控提供原生告警，与平台告警规则深度耦合。共同的痛点是：告警风暴、误报、值班疲劳。
2026 年的实战做法包括：基于 SLO（Service Level Objective）做告警，避免"CPU 大于 80%"这类无业务意义的阈值；引入预算消耗速率（burn rate）让告警在快速消耗预算时立刻响应、缓慢消耗时忽略；通过抑制规则让低优先级告警在高优先级触发时自动静默；用 PagerDuty、Opsgenie、PagerTree 等值班工具做轮班与升级。
国内团队往往直接对接钉钉/飞书/企业微信机器人，但这些 IM 机器人不具备完整的值班能力。规模化后建议引入开源 Cabot、Alerta 或商业 PagerDuty，把告警生命周期管理与人员排班分离开。
2026 年组合选型与成本控制
中小团队、Kubernetes 单集群、预算有限：选 Prometheus + Grafana + Loki + Tempo 自托管，OTel Collector 接入，Alertmanager 做告警。这是开源世界最经典的组合，社区文档丰富，几乎所有问题都能 Google 到答案。长期存储用 VictoriaMetrics 或 Thanos + 对象存储。
企业级、多集群、注重 SLO 与合规：在上述开源底座基础上引入 Mimir 或商业 Grafana Cloud，配合阿里云 SLS 或火山引擎做日志与追踪兜底，重要业务接入 APM SaaS（Datadog 或 New Relic）补足开箱即用的异常检测与 RUM。OTel Collector 让多后端共存不再痛苦。
国内云原生为主、希望免运维：直接采用阿里云 SLS + ARMS + Prometheus 托管版，腾讯云 TMP + CLS，或火山引擎 VMP + TLS。云厂商方案能快速上线，但记得在关键业务上保留 OTel 中间层，未来迁移成本可控。
最后，无论选什么组合，都要把基础工程打牢：统一服务命名与标签规范、明确 SLO 与错误预算、定期演练告警预案、为新服务落地"出生即可观测"的脚手架。监控不是上线后的附属物，而是与代码同等重要的工程产物。
常见问题
指标、日志、追踪到底哪个最重要？
三者解决不同问题，不能取代彼此。指标用于趋势监控与告警，存储成本最低；日志记录任意结构化或非结构化事件，定位具体问题最有用；追踪展示请求在多服务间的完整链路，是排查分布式延迟的关键。生产系统通常三者并存。OpenTelemetry 让三种信号通过统一 SDK 与协议输出，再分别送往合适的后端。
Datadog 真的那么贵吗？
随规模线性增长，确实可能让账单失控。Datadog 按主机、按 Custom Metric、按 Indexed Log 单独计费，复杂度高。一个中等规模 Kubernetes 集群每月几千甚至几万美元很常见。它的价值在于"开箱即用"——上百种集成、统一面板、强大告警与异常检测。预算紧张时可以只用其 APM 与 RUM，配合自托管 Prometheus 收集基础指标。
Prometheus 长期存储怎么解决？
Prometheus 自带 TSDB 默认只保留 15 天，长期存储推荐 Thanos、Cortex 或 VictoriaMetrics。Thanos 通过 Sidecar 将块上传对象存储（S3、OSS、COS），Querier 实现跨集群联邦；VictoriaMetrics 是单一二进制的兼容方案，写入吞吐与压缩比都极佳。两者都能让 Prometheus 数据保留几个月甚至几年，成本明显低于商业 SaaS。
国内云上选 SLS 还是自建 Loki？
取决于团队规模与成本敏感度。阿里云 SLS 提供日志、指标、追踪一站式 SaaS，控制台开箱即用，按写入量与存储计费；优势是无需运维与高可靠，劣势是日志量大时月费可能过万。Loki 自托管更便宜，与 Prometheus 体系契合，标签即查询的设计高度可控；劣势是需要团队具备 Loki 运维能力。中小公司优先 SLS，规模化后逐步迁移到 Loki + 对象存储。
OpenTelemetry 现在生产可用吗？
可以，且强烈推荐。截至 2026 年，Tracing 与 Metrics 规范已经稳定，Logs 规范也已 GA，主流语言 SDK 与 Collector 都成熟。使用 OTel Collector 作为中间层，可以一处采集、多处分发——既送 Tempo/Jaeger，也送 Datadog/SLS。它解决了"被某个监控平台锁定"的最大痛点，是云原生监控的事实标准。