本文是对 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 告警都集中到 ElasticsearchAIOps 如何基于历史告警数据降低 MTTRSlack 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?regionEMEA意思是获取 EMEA 区域 Cisco 设备的 SNMP 采集配置这个接口可以按不同维度过滤region site device type tag maintenance state collector type4. Telegraf 自动 reloadTelegraf 会周期性请求配置 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 AgentSlack 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
本文是对 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 告警都集中到 ElasticsearchAIOps 如何基于历史告警数据降低 MTTRSlack 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?regionEMEA意思是获取 EMEA 区域 Cisco 设备的 SNMP 采集配置这个接口可以按不同维度过滤region site device type tag maintenance state collector type4. Telegraf 自动 reloadTelegraf 会周期性请求配置 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 AgentSlack 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
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
