本文是对 From Monitoring to Observability: Our Ultra-Marathon to a Cloud-Native Platform 的整理与翻译。
内容结构概览
本文会围绕 Uber 企业网络可观测性平台的云原生改造展开，主要包括：
- 为什么传统单体监控系统不再适合 Uber 企业网络
- 这套平台的边界：它关注 Uber Corporate Network，而不是生产业务遥测
- 新平台的目标：数据质量、可扩展性、可行动数据
- 为什么 Uber 选择开源技术栈
- Telegraf、Prometheus、Thanos、Grafana、Kibana、Elasticsearch 分别承担什么职责
- 为什么 Kubernetes 和微服务架构适合这套系统
- 全球多区域部署为什么重要
- Dynamic Config App 如何让 Telegraf 配置动态更新
- 为什么静态配置文件无法跟上全球企业网络变化
- ServiceNow、Elasticsearch 和 Dynamic Config App 如何形成配置闭环
- 从 Monitoring 到 Observability 的真正含义
- Alert Ingestion App 如何统一 Prometheus、MQTT、Meraki、HPE MIST 等告警来源
- FastAPI、Celery、Redis 在告警处理链路中的作用
- 如何过滤、聚合、去重、关联告警，避免 Slack 和 PagerDuty 被打爆
- 为什么把 firing 和 resolved 告警都集中到 Elasticsearch
- AIOps 如何基于历史告警数据降低 MTTR
- Slack bot 这类交互式 AI Agent 如何帮助工程师排障
- 这次迁移带来的收益：更快诊断、更强扩展性、更低授权成本
- 对普通企业网络、SRE、平台工程团队的启发
- 我的理解：可观测性不是“监控工具升级”，而是网络运营方式升级
一、从“穿登山靴跑马拉松”开始
原文用了一个很形象的比喻：管理 Uber 这种规模的全球企业网络，像跑一场超级马拉松。
路线很长，有时路况平稳，有时突然出现山路、天气变化、补给压力和意外情况。你不能只靠一双沉重但老旧的登山靴跑完全程。
Uber 过去使用的是传统、单体式监控系统。它足够稳，也能完成基本任务，但在现代网络规模下越来越显得笨重：
能看状态，但不够灵活 能收指标，但扩展吃力 能告警，但上下文不足 能运行，但随着规模扩大越来越累所以 Uber 的企业网络团队决定换一套“跑鞋”：用云原生、微服务化、开源技术栈，重建企业网络可观测性平台。
这篇文章的核心不是“换了几个工具”，而是讲 Uber 如何从传统监控，转向一个能动态适应网络变化、统一处理告警、支持 AIOps 的云原生可观测性平台。
二、先明确范围：这不是 Uber 生产业务遥测平台
在进入架构之前，原文先澄清了系统范围。
这套平台关注的是 Uber 的 Corporate Network，也就是企业网络。
它不是面向 Uber 生产业务服务的 telemetry platform，不是用来观测打车、外卖、支付、司机派单这些在线业务服务的应用指标。
它关注的是 Uber 内部企业网络基础设施，覆盖对象包括：
办公室网络 数据中心连接 云环境连接 内部服务网络 交换机 路由器 PDU IoT 传感器 网络连通性 网络延迟 设备健康状态 企业网络相关操作数据流也就是说，它的目标是让 Uber 内部网络基础设施具备和生产系统一样的可观测性、可靠性和自动化能力。
这个范围很重要。
因为企业网络的监控对象和应用服务不同。
应用服务通常暴露 HTTP、gRPC、业务指标、日志、trace。
企业网络里更多是 SNMP、设备 API、MQTT 传感器、厂商系统、网络拓扑、站点、地区、设备生命周期、维护状态。
所以 Uber 需要的不是单纯应用 APM，而是一套面向全球企业网络的观测平台。
三、目标：数据质量、可扩展性和可行动数据
新平台的愿景可以概括成三个关键词：
数据质量 可扩展性 可行动数据1. 数据质量
如果指标来源不准、设备状态滞后、标签混乱、告警重复，那么再漂亮的 dashboard 也没有意义。
企业网络观测的第一步是保证数据可信。
这要求系统能够跟随真实 inventory 变化，自动更新采集目标，避免手工配置长期漂移。
2. 可扩展性
Uber 的企业网络分布全球，覆盖多个区域和大量设备。
平台必须能横向扩展，而不是依赖一个巨大单体系统。
当新增站点、设备、区域、采集类型时，系统应该能自然扩展。
3. 可行动数据
传统监控经常只告诉你：
这个设备 down 了 这个接口丢包了 这个延迟高了但工程师真正需要的是：
为什么发生？ 影响范围多大？ 相关告警有哪些？ 之前是否发生过？ 应该找哪个团队？ 是否正在恢复？ 是否和某个维护窗口相关？可观测性的核心就是让数据变得可解释、可关联、可行动。
四、开源技术栈：每个组件各司其职
Uber 新平台建立在一组开源技术之上。
原文按功能列出了主要组件。整理如下：
| 功能 | 技术 | 职责 |
|---|---|---|
| 指标采集 | Telegraf | 采集 SNMP、API、MQTT 等多种来源数据 |
| 实时指标存储 | Prometheus | 存储和查询近期时序指标 |
| 长期存储与全局查询 | Thanos | 扩展 Prometheus，提供长期保存和跨区域查询能力 |
| 可视化 | Grafana、Kibana | 展示指标、告警、上下文和排障视图 |
| 元数据与搜索 | Elasticsearch | 存储 inventory、告警事件、上下文数据，支持检索和关联 |
这套组合很典型，也很实用。
Prometheus 负责核心时序指标。
Thanos 解决 Prometheus 单点和长期存储问题。
Telegraf 负责多协议采集。
Grafana 适合做时序 dashboard。
Kibana 和 Elasticsearch 更适合搜索、过滤、查看事件和上下文。
这里的重点不是某一个工具多强，而是这些工具组成了一条观测链路：
设备和传感器 ↓ 采集 ↓ 时序存储 ↓ 长期保存 ↓ 搜索和元数据 ↓ 告警和上下文 ↓ 可视化和排障五、云原生架构：Kubernetes、微服务和 API 化
为了让系统具备弹性和扩展能力，Uber 采用了云原生、微服务化架构，并部署在 Kubernetes 上。
这意味着每个组件都是模块化、容器化的服务，通过 API 交互。
这种设计有几个直接好处。
1. 高可用
组件异常时，Kubernetes 可以自动重启。
相比手工维护的单体监控系统，容器化部署更容易恢复。
2. 模块独立演进
采集、配置、存储、告警、可视化、AI 分析，可以各自迭代，不需要把所有逻辑塞进一个庞大系统。
3. 易于接入新系统
企业网络环境里经常有新厂商、新设备、新协议、新站点。
API 化架构更容易扩展集成。
4. 全球部署更自然
原文提到平台部署在多个全球区域，包括 USC、EMEA 和 APAC。
这非常重要。
网络监测如果只从一个区域发起，看到的延迟、连通性和可达性可能不准确。
把探针和采集组件部署到接近设备和站点的区域，可以获得更接近真实用户和真实网络路径的观测结果。
可以把这些区域部署理解成超级马拉松里的补给站：
不同区域都有采集能力 每个区域靠近本地设备 全球视角通过统一存储和查询整合六、架构主线：让每个组件都跟上网络变化
原文用“跑山赛”继续打比方：真正的挑战不是跑在一条永远不变的路线，而是地形不断变化。
企业网络也是这样。
设备会新增。
设备会下线。
路由器可能迁移到新区域。
某个站点进入维护状态。
某些设备类型需要新的采集插件。
某些区域要重新分配 polling workload。
如果采集配置是静态文件，那么每次变化都需要人工修改配置、提交变更、重启 agent 或重新部署。
这在小规模网络里可以忍。
在 Uber 的全球企业网络里不现实。
所以平台引入了一个关键组件：
Dynamic Config App它的作用是让监控配置跟随真实网络 inventory 自动变化。
七、传统静态 Telegraf 配置的问题
Telegraf 是非常灵活的采集 agent。
它可以通过 SNMP、API、MQTT 等方式采集设备和传感器指标。
但如果 Telegraf 的配置完全靠静态文件，就会遇到几个问题。
1. inventory 变化后配置滞后
设备新增了，但配置没加，监控就缺失。
设备下线了，但配置还在，采集器继续尝试访问不存在的设备。
设备区域变了，但采集器还在原区域轮询，导致延迟变高或路径不准。
2. 人工变更成本高
每次网络变化都要改配置。
全球网络变化频繁时，人工流程会成为瓶颈。
3. 容易出现漂移
真实 inventory 在一个系统里，监控配置在另一个系统里。
时间长了，两边必然不一致。
4. 无法快速全局扩展
如果要新增采集插件，或者调整某类设备采集逻辑，静态配置方式很难快速、统一、低风险地全球 rollout。
所以 Uber 需要一种动态配置机制，让 Telegraf 不再依赖固定文件，而是周期性从配置服务拉取最新目标。
八、Dynamic Config App：让配置跟着 inventory 走
Dynamic Config App 的设计思路是：
ServiceNow 作为 source of truth ↓ 持续刷新 inventory 数据 ↓ inventory 存入 Elasticsearch ↓ Dynamic Config App 根据查询条件生成 Telegraf 配置 ↓ Telegraf 周期性拉取配置 ↓ 发现 Last-Modified 变化后自动 reload这里有几个关键点。
1. ServiceNow 是源头
企业网络设备和状态的真实 inventory 来自 ServiceNow。
这保证监控配置不是人工单独维护的另一份真相，而是从系统 of record 派生出来的。
2. Elasticsearch 存储 inventory 并支持搜索
Elasticsearch 用来保存和检索设备元数据。
比如设备所在区域、站点、设备类型、维护状态、厂商类型等。
3. Dynamic Config App 提供参数化配置接口
Telegraf agent 启动时会带一些参数，通过 URL 拉取特定范围配置。
原文举了类似这样的形式：
/v1/snmp/cisco?region=EMEA意思是：
获取 EMEA 区域 Cisco 设备的 SNMP 采集配置这个接口可以按不同维度过滤：
region site device type tag maintenance state collector type4. Telegraf 自动 reload
Telegraf 会周期性请求配置 URL，并检查 Last-Modified。
如果发现配置更新，就自动 reload。
这样一来，新增设备、删除设备、区域调整、插件变更，都不需要手工修改 agent 配置，也不需要重新部署 agent。
九、Dynamic Config 带来的能力
原文总结了 Dynamic Config App 带来的几项能力，可以展开理解。
1. 即时重新分配 polling workload
如果某个区域新增大量设备，或者设备从一个区域迁移到另一个区域，采集工作可以自动重新分配。
这避免了某些 Telegraf agent 过载，某些 agent 空闲。
2. 按 tag、region、site、device type 过滤配置
企业网络采集不是一刀切。
不同设备类型需要不同插件。
不同区域可能有不同采集策略。
某些维护中的设备可能不应该触发告警。
某些站点可能需要特殊采集间隔。
通过动态过滤，配置变得更灵活。
3. 全球 rollout 新 collector 或插件变化
如果要新增采集器，或者调整某类插件配置，不需要每台 agent 手工变更。
Dynamic Config App 可以让 agent 下一次拉取配置时自动更新。
4. 始终和 live inventory 对齐
这可能是最重要的收益。
监控系统最怕“监控对象和真实对象不一致”。
动态配置把这个问题从人工流程变成自动同步。
监控系统不再是一张静态地图，而是会跟着真实网络变化更新。
十、从 Monitoring 到 Observability：区别到底在哪里？
原文里有一句非常清楚的对比：
Monitoring answers “Is it up?” Observability answers “Why does it feel slow uphill?”翻译一下：
监控回答：它还活着吗？ 可观测性回答：为什么它跑得慢？慢在哪里？发生了什么上下文变化？传统监控更像检查点。
它告诉你：
设备在线还是离线 接口是否 up 延迟是否超过阈值 CPU 是否高但它不一定告诉你：
为什么延迟升高？ 同一时间还有哪些相关告警？ 是否某个站点整体异常？ 是否某个第三方系统也报了事件？ 是否有维护窗口？ 是否某类设备同时出现类似问题？ 过去 24 小时趋势如何？ 是否正在恢复？可观测性强调的是上下文、关联和解释能力。
这就是 Uber 引入 Alert Ingestion App 的原因。
如果说 Telegraf 和 Dynamic Config App 是数据采集和配置适配的腿和肺，那么 Alert Ingestion App 就像教练和策略师：它把来自不同系统的事件统一接入、处理、去重、关联，帮助工程师理解事故，而不是只看到一堆孤立告警。
十一、Alert Ingestion App：统一接入多来源告警
Uber 的企业网络告警并不只来自 Prometheus。
还有很多第三方系统和网络平台会产生告警，例如：
Meraki HPE MIST MQTT sensors 其他 webhook integrations 网络 API Prometheus alerts如果每个系统都直接打到 Slack 或 PagerDuty，就会造成告警风暴。
工程师会看到：
同一个事件重复通知 同类设备同时报警刷屏 告警恢复又产生一堆消息 不同系统各说各话 缺少统一上下文Alert Ingestion App 的目标是把所有这些信号统一接入一个处理链路。
原文提到它基于：
FastAPI Celery Redis可以理解为：
- FastAPI 提供 HTTP/Webhook 接入层
- Celery 处理异步任务和并行加工
- Redis 支撑队列或任务状态等异步处理能力
这套组合让告警 ingestion 不阻塞、不串行，并能并行处理大量事件。
十二、Alert Ingestion App 做的不只是转发
如果 Alert Ingestion App 只是把告警从 A 系统转发到 Slack，那价值不大。
它真正做的是告警治理。
原文提到几个核心能力。
1. 过滤和优先级排序
不是每个信号都值得打扰工程师。
一些告警可能是低价值噪音。
一些事件可能只是另一个根因事件的下游表现。
一些状态变化不需要立即 page。
Alert Ingestion App 会过滤和优先级排序，让最重要的事件优先进入工程师视野。
2. 分组相似事件
如果一个站点断网，可能会导致大量设备同时报警。
如果每个设备都发一条 PagerDuty，工程师会被淹没。
更好的方式是把相似事件聚合成一个事件组。
这能显著降低告警风暴。
3. 增加上下文和关联
它不只是告诉你“某设备 down”，还会把相关信息聚合起来：
所属区域 所属站点 设备类型 相关告警 历史状态 是否有同站点事件 是否和第三方系统告警相关这样工程师更容易判断根因。
4. 实时更新同一条告警
原文特别提到，系统会 post alerts once，并在状态变化时 edit 它们。
这非常实用。
传统告警系统经常是：
firing 发一条 resolved 又发一条 中间状态变化再发几条结果聊天工具里全是重复消息。
更好的方式是：
同一个事件只创建一条消息 状态变化时更新这条消息这样能减少 Slack/PagerDuty 噪声，也让排障上下文更连续。
十三、所有告警进入 Elasticsearch：形成完整事件轨迹
Alert Ingestion App 会把各种来源的告警统一写入 Elasticsearch index。
包括：
Prometheus alerts MQTT sensors network APIs Meraki / HPE MIST 等第三方系统事件 firing 状态 resolved 状态 更新历史 关联上下文这样做的价值非常大。
首先，工程师可以搜索历史事件。
比如某个站点过去 24 小时告警趋势如何。
其次，事件不再散落在不同系统里。
过去你可能要看 Prometheus、Meraki 控制台、Slack、PagerDuty、设备 API。
现在可以在一个统一索引里看到完整轨迹。
第三，resolved 事件也被保存。
这点很重要。
很多系统只关注 firing alert，但 resolved 同样有价值。
它能告诉你事件何时恢复、恢复速度、是否重复发生、是否存在 flap。
第四，它为后续 AIOps 提供数据基础。
没有统一历史数据，就无法做趋势分析、根因分析、智能关联和自然语言查询。
十四、Dynamic Config + Alert Ingestion：从静态系统变成活系统
Dynamic Config App 解决的是：
采集目标和配置如何跟随网络变化Alert Ingestion App 解决的是：
告警如何从多源信号变成可理解、可行动的事件流两者结合，Uber 的企业网络平台就从传统静态监控，变成了一个动态可观测生态：
网络 inventory 变化 ↓ 采集配置自动更新 设备和系统产生告警 ↓ 告警统一接入、过滤、聚合、关联 所有事件进入统一索引 ↓ 工程师可以搜索、分析、追踪完整事故过程 历史数据积累 ↓ 支撑 AIOps 和 AI Agent这就是从 monitoring 到 observability 的真正转变。
不是 dashboard 多几个图，而是系统变得能自动适应、统一理解、长期学习。
十五、AIOps：从历史告警数据中加速定位根因
当所有 firing 和 resolved 告警都集中到统一数据集中后，Uber 就具备了进一步做 AIOps 的基础。
AIOps 可以理解成 AI for IT Operations。
它不是简单地让 AI 看 dashboard，而是基于历史运维数据、告警数据、网络事件和上下文，帮助工程师更快理解问题。
原文提到，AI engine 会处理所有告警来源，分析网络行为模式，帮助工程师更快定位根因，降低 MTTR。
MTTR 是 Mean Time To Repair，也就是平均修复时间。
降低 MTTR 的关键不是“告警更快响”，而是：
更快知道问题影响范围 更快看到相关事件 更快排除无关噪声 更快找到根因候选 更快知道历史是否发生过 更快找到处理路径AIOps 的作用正是在这些环节提高效率。
十六、交互式 AI Agent：Slack Bot 作为事故中的“配速员”
原文还提到一种更交互式的能力：Slack bot。
工程师可以用自然语言问问题，例如：
过去 24 小时这个 site code 的告警趋势如何？系统可以基于 Elasticsearch 中的历史告警数据和上下文返回答案。
这非常适合事故处理。
在事故中，工程师经常需要临时问：
这个站点以前出过类似问题吗？ 这类设备是否同时出现异常？ 过去一小时告警数量是否上升？ 哪些区域受影响？ 当前 firing 和 resolved 的比例如何？ 这个告警是否重复发生？如果每个问题都要人工去多个 dashboard 查询，效率很低。
AI Agent 的价值是把复杂查询变成自然语言交互。
它就像超级马拉松中的配速员，在最困难的阶段帮你保持节奏、补充信息、减少认知负担。
十七、这次迁移的收益：更快、更灵活、更省钱
原文最后总结了三类收益。
1. 更快诊断和恢复
通过 enriched data 和 intelligent, de-duplicated alerts，工程师可以更快诊断和解决问题。
这里的关键不是单纯“告警更快”，而是告警更少噪声、上下文更多、历史更完整。
这会直接影响 MTTR。
2. 更强扩展性
模块化、API-driven 的设计让平台更容易接入新设备、新厂商、新协议和新系统。
企业网络环境总会变化。
一个封闭单体系统很难跟上。
云原生微服务架构让系统更适合长期演进。
3. 更低授权成本
原文提到迁移后消除了数十万美元级别的 recurring licensing fees。
这说明新平台不仅在技术上更灵活，也在经济上更可持续。
从商业角度看，开源栈不是“免费午餐”，仍然需要工程投入和运维能力。
但在 Uber 这样的规模下，减少持续授权费用，并把资源投向更创新的平台能力，是非常合理的选择。
十八、为什么这不是简单“用开源替换商业软件”？
读到这里，很容易把这篇文章理解成：
Uber 用开源栈替换了老监控系统，省钱了。这只说对了一小部分。
真正重要的是，Uber 不是简单拿开源工具拼一拼，而是围绕自身企业网络需求构建了一套平台能力。
它包括：
动态配置 全球区域部署 多协议采集 时序指标存储 长期指标查询 统一告警 ingestion 告警去重与关联 Elasticsearch 事件索引 Slack / PagerDuty 噪声控制 AIOps 数据基础 自然语言排障入口如果只是把旧系统换成 Prometheus + Grafana，解决不了这些问题。
真正的迁移是从：
一个传统监控系统变成：
一套云原生、自动化、可扩展、面向 AIOps 的企业网络可观测性平台这才是文章标题里 “From Monitoring to Observability” 的含义。
十九、对企业网络团队的启发
很多企业网络团队仍然处在传统监控阶段。
典型形态是：
设备清单在一个系统里 SNMP 配置在另一个地方 告警来自多个厂商控制台 Slack 里一堆重复消息 PagerDuty 被告警风暴打爆 排障靠经验 历史事件不好搜索 变更和维护状态很难和监控联动Uber 的做法给出了一条演进路径。
第一，统一 source of truth
网络设备 inventory 应该有一个可信来源，比如 ServiceNow。
监控配置应该从 source of truth 派生，而不是单独维护。
第二，采集配置要动态化
设备变化频繁时，静态配置文件迟早会漂移。
动态配置服务可以大幅减少人工维护。
第三，多来源告警要统一 ingestion
不要让每个厂商系统直接打到聊天工具。
先进入统一告警处理链路，再过滤、分组、去重、关联。
第四，resolved 事件也要保存
恢复事件和 firing 事件同样重要。
它们是 MTTR、趋势分析、重复故障识别的基础。
第五，可观测性不是只看图
Dashboard 只是入口。
真正有价值的是指标、元数据、告警、事件、历史和上下文能互相连接。
第六，AI 不是凭空出现的
AIOps 的前提是高质量历史数据。
如果告警数据散乱、不一致、缺上下文，AI 也帮不上忙。
二十、对 SRE 和平台工程团队的启发
如果你做 SRE 或平台工程，这篇文章也有几个值得借鉴的点。
1. 监控平台要服务变化，而不是假设世界静止
服务、设备、区域、拓扑都会变化。
监控平台必须能自动跟随变化。
2. 配置管理是可观测性的基础
很多监控问题不是采集器不行，而是配置过期。
Dynamic Config App 这类组件非常关键。
3. 告警治理比告警数量更重要
一个系统告警很多，不代表它可观测性好。
如果工程师被噪声淹没，反而会变慢。
4. 中心化事件索引很有价值
把多来源事件统一存储，后续才能做搜索、关联、趋势、AIOps。
5. 云原生不只是部署方式
Kubernetes、微服务、API 化不仅是部署形态，也改变了平台如何扩展和演进。
6. 开源技术栈需要平台化封装
直接把 Prometheus、Grafana、Elasticsearch 摆上去不等于平台。
平台价值来自自动化、标准化、治理和集成。
7. 成本优化可以和能力升级同时发生
迁移开源栈既降低授权费用，又为 AIOps 留出空间。
但前提是有足够工程能力维护这套系统。
二十一、这篇文章和 Uber 其他工程文章的共同风格
Uber 最近的工程文章有一个共同特点：不是只讲“换了某个工具”，而是讲系统如何平台化。
例如：
限流系统文章：从零散 Redis 限流到服务网格里的 GRL + RLC 数据库负载管理文章：从静态限流到 Cinnamon 和统一 Load Shedding Engine OpenSearch gRPC 文章：从 REST/JSON 适配层到原生 gRPC transport Verify with Wallet 文章：从一次 API 集成到身份验证平台能力 这篇可观测性文章：从单体监控系统到云原生可观测性生态它们背后的工程思路一致：
先识别规模化瓶颈 再抽象成平台能力 再用自动化减少人工维护 最后为未来智能化和扩展留下接口这也是大型工程组织常见的成熟路径。
二十二、我的理解：可观测性不是“监控升级版”，而是运营方式升级
我觉得这篇文章最重要的地方，是它把 observability 讲成了一种运营方式变化，而不是工具列表。
传统 monitoring 更像：
我有一组设备 我定时采集它们 我设置一些阈值 超过阈值就告警现代 observability 更像：
我有一个不断变化的网络 设备和拓扑来自真实 inventory 采集配置自动跟随变化 指标和告警进入统一数据平台 告警会被过滤、去重、关联 工程师能看到事件上下文和历史轨迹 AI 可以基于历史数据辅助排障这两者差别很大。
一个是“看状态”。
另一个是“理解系统”。
企业网络越大，这种差别越明显。
在小网络里，靠人工经验和静态配置还能撑住。
在 Uber 这种全球企业网络里，静态监控会慢慢变成负担。
所以这篇文章其实是在说：
可观测性的核心不是更多指标，而是让系统状态、配置、告警、上下文和历史数据形成闭环。
二十三、如果自己要设计类似平台，可以怎么落地？
可以按以下路径逐步推进。
第一阶段：统一 inventory
先确认设备、站点、区域、维护状态、设备类型等基础数据在哪里。
没有 source of truth，后面会非常痛苦。
第二阶段：动态生成采集配置
不要让采集配置长期静态维护。
从 inventory 生成配置，并让 agent 周期性拉取。
第三阶段：统一指标采集和存储
可以用 Telegraf + Prometheus + Thanos 这类组合，也可以根据自己的技术栈选择替代方案。
重点是要区分实时指标和长期存储。
第四阶段：统一告警 ingestion
把 Prometheus、厂商平台、Webhook、MQTT、设备 API 的告警统一进入一个 ingestion service。
第五阶段：做告警治理
先不要急着上 AI。
先做：
过滤 去重 分组 优先级 状态更新 关联上下文这些基础能力比直接接大模型更重要。
第六阶段：构建统一事件索引
把 firing、resolved、更新历史、上下文都存起来。
这会成为排障、报表、复盘和 AIOps 的基础。
第七阶段：接入 AI 和自然语言查询
当历史数据足够干净、上下文足够完整后，再做 Slack bot、自然语言查询、根因提示、趋势分析，效果才会好。
二十四、总结
Uber 这篇文章讲述了他们如何把企业网络监控系统，从传统单体监控升级为云原生可观测性平台。
这套平台关注的是 Uber Corporate Network，也就是连接办公室、数据中心、云环境和内部服务的企业网络基础设施。它不属于 Uber 生产业务服务的 telemetry platform，而是专门用于观察交换机、路由器、PDU、IoT 传感器、网络连通性、延迟、设备健康和企业网络操作数据流。
Uber 新平台的目标是：
数据质量 可扩展性 可行动数据为此，Uber 选择了一组开源技术栈：
Telegraf：采集 SNMP、API、MQTT 等多来源指标 Prometheus：实时指标存储和查询 Thanos：长期存储和全局查询视图 Grafana / Kibana：可视化和排障视图 Elasticsearch：元数据、inventory、告警和事件搜索 Kubernetes：云原生部署、高可用和组件自动恢复系统部署在 USC、EMEA、APAC 等全球区域，让采集和探针更靠近真实设备和站点。
平台的第一个关键组件是 Dynamic Config App。
它以 ServiceNow 作为企业网络 inventory 的 source of truth，将设备和状态信息持续同步到 Elasticsearch，再根据 region、site、device type、tag 等参数动态生成 Telegraf 配置。Telegraf 周期性请求配置 URL，发现 Last-Modified 变化后自动 reload。这样，设备新增、删除、区域变更、维护状态变化、collector 或 plugin 更新，都可以自动反映到采集配置中，无需手工编辑配置或重新部署 agent。
平台的第二个关键组件是 Alert Ingestion App。
它基于 FastAPI、Celery 和 Redis，统一接入 Prometheus、MQTT sensors、Meraki、HPE MIST 以及其他 webhook integrations 的告警。它会对告警进行过滤、优先级排序、分组、去重、上下文关联，并在 Slack 或 PagerDuty 中尽量通过更新同一事件而不是重复发消息的方式减少噪声。所有 firing 和 resolved 告警都会进入统一 Elasticsearch index，形成完整事件轨迹。
正是 Dynamic Config App 和 Alert Ingestion App，把系统从传统 monitoring 推向 observability。
传统监控回答：
它是否 up？可观测性回答：
为什么它慢？ 影响范围是什么？ 有哪些相关事件？ 过去是否出现过？ 当前是否正在恢复？在统一历史告警和事件数据基础上，Uber 还可以引入 AIOps。AI engine 能分析历史网络行为模式，帮助工程师更快定位根因、降低 MTTR。交互式 Slack bot 则允许工程师用自然语言查询，例如询问某个 site code 过去 24 小时告警趋势，系统可以立即返回带上下文的答案。
迁移到这套云原生可观测性平台后，Uber 获得了几类收益：
通过丰富上下文和智能去重告警，让工程师更快诊断和解决问题 通过模块化、API-driven 架构，让平台更容易扩展和接入新系统 通过开源技术栈，消除数十万美元级别的持续授权费用 为未来 AI-driven network operations 打下数据和架构基础这篇文章最重要的启发是：
可观测性不是监控工具升级，而是运营方式升级。
它要求 inventory、采集配置、指标、告警、事件、上下文、历史和 AI 分析形成闭环。
对企业网络、SRE 和平台工程团队来说，Uber 的实践说明：
真正可扩展的观测平台，不应该依赖静态配置和分散告警，而应该能自动跟随真实环境变化，统一接入多来源信号，减少噪声，保留完整历史，并让工程师更快理解系统为什么出现问题。
参考资料
- From Monitoring to Observability: Our Ultra-Marathon to a Cloud-Native Platform
