阿里妹导读
前言
为什么需要可观测性
一年前写过一篇介绍弹性计算管控监控告警体系的文章《弹性计算管控监控预警体系建设之路》 介绍的是弹性计算管控监控告警体系的发展和设计思路。监控告警本质只是故障发现的手段之一，当前主要聚焦在稳定性的故障/问题发现领域（当然告警是一种业界共识的故障发现媒介，一定程度会传递故障定位信息）。可观测性是贯穿整个软件生命周期的，从稳定性视角看，可观测性覆盖了从故障预防->故障发现->故障定位->故障恢复->故障改进验收的完整周期。
业务视角看可观测性问题
首先，从组织、业务、技术等几个视角来定义 ECS 管控在客观性上遇到的问题：
集成复杂性，当前能力非标，数据割裂，难以输出标准化的API用于业务集成
业务体感差，可观测性大盘，预警整体体感对研发不够友好，仍然是运维思维
基建能力弱，研发构建业务自定义的能力没有完整的方法或者平台支持
问题定位难，metric和trace能力不足，故障定位大部分场景依托于专家经验
对业务团队应用价值
应用视角，全软件生命周期（SDLC）观测，包括研发、测试、交付、运维等 稳定性视角，多场景观测能力、监控发现、告警通知、根因定位
容量视角，建设产品与组织视角的容量观测能力
定义现状，构建产品视角的容量观测能力 评估未来，为后续资源降本提供决策支持
可观测性体系目标
建立标准化机制与 SOP，通过遵循行业标准协议和最佳实践，确保数据模型、指标定义、日志格式等关键组件的一致性和互操作性。这将简化跨团队协作，降低技术壁垒，并提高整体运维效率，使得从不同维度获取的系统状态信息得以精准映射并整合到一个通用视图中，为故障快速响应奠定基础。
提供可集成性能力，支持与开源、阿里云产品工具、服务无缝对接，如日志收集平台、APM（Application Performance Management）、 tracing工具等。这样，在满足多样化需求的同时，也能保证所有相关数据源能够高效地融入观测平台，形成完整的端到端可观测链条，助力团队在面对复杂故障场景时迅速定位根源。
预留可扩展性，随着业务和技术的快速发展，可观测框架需要灵活适应不断增长的数据规模和新型应用场景。设计之初就要充分考虑模块化和水平扩展能力，以确保在系统扩容、新功能接入的情况下，仍能保持稳定高效的性能表现，满足未来可能出现的各种运维需求。
提供卓越的用户体验，直观易用的界面设计，实时准确的数据反馈，以及智能化的问题诊断辅助，都将大幅提升SRE和研发团队的工作效能。例如，通过对海量数据进行智能分析，结合 AIOps/LLMOps 技术提前预测潜在风险，甚至能够在故障发生之前即采取预防措施，显著降低系统的MTTR（Mean Time To Repair）。
可观测性技术体系建设
整体架构
Service，依赖服务层，当前 ECS 管控可观测性构建于阿里云公共云云产品以及部分内部服务之上，核心原则：Cloud First。 Data Center，数据中心，数据质量与覆盖度是决定上层业务是否可以标准化运维与实现智能化运维的关键，当前观测数据层主要包括 log、metric、trace、event、cmdb 以及业务数据与运维知识等。
Process Layer，通过 ETL 等工具对数据进行加工并统一存储，包括时序数据库、关系数据库、知识图谱、数仓等多种形态，核心在于统一建模、标准化与业务适配。
Operation Brain，运维大脑，专家经验与 AIOps/LLMOPs 的能力组合，核心解决业务运维领域最复杂“思考”能力落地问题，比如故障领域经典的根因定位、容量预测等。
Automation Center，运维编排与工具管理，直接支撑典型的业务运维场景，比如告警事件通知、变更事件广播、自动化扩容、限流自愈、自动化 profile 等，核心在于解决标准化、与业务覆盖问题。
核心设计
Cloud Frist，吃狗粮，优先考虑基于云产品（尤其是公共云）的开放集成能力构建可观测性，比如 ECS 管控可观测性核心依赖了 SLS、ARMS、云监控、DAS 等多个云产品的 OpenAPI 与 InnerAPI。 SDLC，建立覆盖软件开发生命周期的观测能力，观测不仅仅用来在运维阶段发现故障，同样可以用于业务规划、容量规划、研发质量、交付效能、成本优化等领域。 Platform，平台产品思维，我们不做解决单点局部问题的方案，要做可以解决一系列问题的平台解决方案，同时要尽可能推动实现 研发自助->自动化->智能化 的演进。
Cloud Frist：生于云，长于云
在ECS管控可观测性能力建设的漫长演进历程中，从内部monitor、sunfire，再到sls与prometheus生态结合并融入自主研发阶段，目前ECS管控观测已实现全链路“上云”，这一过程蕴含了几个关键性的洞察与思考，与大家分享一下：
观测数据构筑之重犹如基石（再次强调），组织视角下需洞见“恒定”与“变化”。在业务图谱中，业务核心数据可视作不变的“常量”，而观测技术则是持续迭代的“变量”。无论是昔日的Nagios、ELK，还是现今流行的prometheus生态系统，未来无疑会出现更为卓越的解决方案。然而，相对而言，业务的数据与核心关注点相对稳定， 比如在 ECS 团队，我们对保障 ECS及相关配件资源的有效交付与稳定运行（涵盖成功率、效率、规模承载力等关键指标）不会改变。
深度挖掘并充分利用云端产品潜能，旨在减少运维边际成本，达成高效运作。不论是SLS、ARMS，抑或是云监控服务中托管的prometheus、grafana等云原生工具集，它们所提供的强大功能足以支撑日常业务场景所需。独立运维乃至自主研发此类工具，其收益往往并不显著，尤其是在业务规模逐步扩大的背景下，独立运维的成本和风险将会呈现出上升趋势。
践行面向失效的设计哲学，以用户为中心，深知在不确定的世界中，“所有云产品皆有潜在不可靠性”。不妨提出一个挑战性的问题：倘若依赖的XXX云产品突发故障，我们将如何应对？近期AK故障引发的大量云产品异常事件，大量依赖云产品构建的观测能力在该场景也全部异常，这为我们提供了一个亟待深思的实例。当前我们团队正积极内省，并与云内监控团队密切沟通，共同探讨如何在云产品可能出现故障的情境下，仍能确保核心的观测能力和监控告警机制的有效性和可靠性，实现对未知风险的有效抵御。
Data Center：构筑运维基石
Log，ECS 管控所有服务以及业务日志，国内与海外双中心部署，统一存储在 SLS logstore。
Metric，ECS 管控度量指标数据， Prometheus 数据协议，存储在 SLS metric store，国内海外双中心存储。
Trace，基于 ARMS 与 SLS logstore 自研可编排、可扩展的全链路日志追踪服务。
Meta，基于 ECS 业务以及管控应用、架构、组织等信息建设统一的业务 meta 数据，基于 meta 数据与 Trace 构建知识图谱服务。
Event，事件中心覆盖了包括资源主动运维、变更、告警、数据库、异常检测、压测演练等多维的异动数据。
Business Data 与 knowledge 目前思路是提供标准化 meta 外的补充，可以作为大模型的语料输入。
Log：统一日志管理
日志查询托管，解决研发最高频的多账号日志查询需求，通过RAM 角色扮演方式在嫦娥运维平台内嵌 SLS 控制台，解决单浏览器多阿里云账号日志查询需求，同时支持 全局 logstore 搜索、收藏与分享功能，可以将 SLS 查询条件持久化，实现快速访问以及分享给他人，以上所述所有操作用户都无需感知阿里云账号。
日志资源管控，通过持久化 SLS meta 以及 SLS 的 OpenAPI 结合业务形态实现 SLS 机器组分发、Dashboard 跨地域同步、数据投递数仓等高阶运维能力，简化研发运维操作与成本。
Metric：统一指标体系
技术建设
异构多数据源支持，统一 Prometheus 数据协议写入，支持 logstore 转 metric store、ECS自研metrics框架写入、以及同步第三方 metric 数据等多种异构数据源接入，通过统一的 prometheus 数据协议标准，数据源与数据存储皆具备扩展性。
自定义 HTTP API 用于业务被集成，通过自定义 HTTP API 方式统一封装业务模型，提供适配 ECS 业务的使用方式，天然支持 region、应用等模型参数。同时，通过 prometheus 原生协议提供 的查询能力，这部分能力通过 SLS metric store 提供。
业务 labels 注入非常关键，如果说 ECS 管控 metrics 最核心的两个价值，其一是数据标准化，第二就是我们通过结合业务 Meta，针对每个 metric 都加入了业务视角的 labels，这个对于上层运维能力构建至关重要。
标准规范
数据存储规范
国内海外双中心存储，安全合规设计，ECS 管控 metric 数据不涉及用户面合规风险，权衡安全合规与运维成本考虑通过国内+海外双中心存储（当前通过数据同步链路汇总到上海，后续需要拆分）。
冷热数据分离，SLS 存储实时 metric 数据，最长保存一年，通过定时同步链路将数据回流到 MaxCompute，并经过 ETL 加工为业务需要的数据提供给 AIOps 与大模型使用。
指标分级规范
指标体系在实际建设过程中会有两个阶段，第一阶段，指标覆盖不全，体现在观测维度不够丰富、告警覆盖不全；为了解决第一阶段问题，业务侧通常会从多个维度层次进行指标补齐，进而指标的数量会膨胀，系统会遇到第二个问题，指标太多了，我们该怎么用？实际经验来看，系统需要重点关注的指标占总指标的比例不应该超过 30%，过多的重点指标意味着业务/问题题的定义不够清晰。所以在 ECS 管控我们定义了重点指标（核心指标、关键指标）占比控制在 30%以内。你可能会问，哪些指标可以定义为重点指标呢？我们的实践建议是从客户/业务视角出发，可以表征客户业务受损的指标。
指标分层规范
metric格式规范
完全遵循 prometheus metric format，time-series 存储，sample如下：
指标(metric)：metric name和描述当前样本特征的labelsets;
时间戳(timestamp)：一个精确到毫秒的时间戳，当前指标默认一分钟生成一次；
样本值(value)：一个float64的浮点型数据表示当前样本的值。
metic命名规范
labels 使用规范
labels 可以方便业务聚合，比如统计应用 A 在地域 cn-hangzhou 下所有 check health 异常的机器总量，就可以通过 labels 快速过滤。为了简化业务使用成本，对 metric labels 进行统一使用规范，针对通用的 labels 进行命名统一。
Event：事件驱动运维架构
异构数据源扩展支持，Event Center 本身不生产数据，只是数据搬运工。这里我们设计了统一的事件网关，多协议支持汇总多数据源的事件信息，并提供统一的过滤加工能力，统一标准化为 CloudEvents 协议。
CloudEvents协议标准，统一标准化事件协议，集成视角，可以将多源数据进行统一整合存储；被集成视角，CloudEvents 协议作为开源标准，可以更好的被内部甚至是生态其它产品进行集成，比如阿里云的 EventBridge 等。
高可用存储方案，使用 SLS+mongodb 双写方式，保障单数据源异常情况，服务整体高可用。
事件驱动运维架构，可以简单理解成 event-driven architecture 在运维领域的应用，但这并不只是一种技术实现或者架构模式的改变，更是 DevOps 工作方式的改变。
Trace：全链路追踪能力
当前 Trace 系统仍然在演进中，Trace 系统在实现上有以下几个关键设计：
Trace 埋点打通，如何解决一个 Request ID 可以打通全链路包括业务、中间件、线程池、数据库全链路，整个过程极具挑战。对内，要解决上述如线程池、数据库串联问题，当前我们通过 ARMS、DAS、自研能力进行串联，目前串联了部分，仍然覆盖中；对外，如何打通依赖方，这个不是一个单纯的技术问题，这里不做讨论。
编排调度能力，在全链路 Trace 埋点都标准化输出到日志的情况下，编排能力和调度能力将会非常关键。前者解决业务自定义扩展能力，简单来说，除了支持 ECS 的业务，同样可以支持其它云产品接入；后者，在调用链路很长情况下，权衡查询的体验与准确性，这里需要在并行调度能力上不断提升。
Dashboard：分层观测大盘建设
Dashboard 分层定义
观测大盘是为了快速准确辅助人工发现观测链路异常局点，所以核心是回到产品和业务本身，回到用户视角来定义。ECS 管控为例，业务特征是多地域单元化部署、业务形态复杂、依赖链路多。在观测大盘分层上，我们也从解决上述问题思考：
status 大盘，云产品维度的全地域健康状态，辅助人工发现当前异常地域。
核心指标大盘，覆盖地域维度核心指标，在定位到异常地域情况，辅助快速定位异常核心指标。
应用大盘，应用维度从核心指标、黄金指标、中间件、依赖服务等几个维度定义应用核心观测数据，用于在定位应用异常局点。
业务大盘，从业务视角出发，服务正常未必等同业务正常，核心在于从用户视角定义业务的健康状态，以及识别异常业务。
场景大盘，覆盖研发生命周期以及日常研发活动，比如 CI Dashboard、发布可观测性、重保（双十一大促）观测、容量大盘、以及垂直领域如数据、中间件整体的观测大盘。
技术建设
核心是 Data Center，当前包括 Log 与 Metrics，ECS 管控当前所有的 log 以及 metrics 都统一托管在 sls 的 logstore 与 metric store，同时基于 SLS 开放 API 实现了一定管控能力比如多地域同步。
充分利用云产品优势，回到最初架构设计 Cloud First 原则，ECS 管控在 Dashboard 建设上也充分利用了云产品优势。
通过 SLS 与云监控托管的 prometheus 与 grafana 能力，免去独立运维成本
通过 SLS 开放 API 实现了多地域 Dashboard 同步能力，简化多地域运维成本。
Alert： 智能告警平台
成熟度模型
笔者认为告警成熟度最高的级别 L4 是告警自愈，而 实现告警自愈需要一套高度体系化、高度集成化的平台工具链支撑，包括业务运维领域的 CMDB、全覆盖且准确的监控告警、可靠运维任务编排调度能力、以及对应 ITIL系统的支持，这也就是ECS管控SRE在整体运维架构里我们坚持要定义管控的运维知识图谱以及前期大量标准化体系和流程建设的原因。笔者认为，决定智能（无论是 AIOps 还是当下火热的 LLM Ops）运维能否最终场景化落地的必要条件是这些最基础的数据和能力。
技术建设
当前弹性计算的告警整体实现了标准化、统一化的管控，其中部分核心告警实现了一定的根因定位能力，当前整体正在向告警自愈方向演进，下面是我们统一告警平台整体的技术设计。
从产品设计角度看，有以下几个关键设计分享：
开箱即用，支持主流告警包括云监控、SLS、ARMS、POP、DAS 在内的七种数据源默认集成（大部分基于公共云开放能力集成），通用监控告警默认集成（比如云监控、数据库等），业务告警在SLS配置后默认自动消费生成配置。业务只需要按照自定义需求简单配置即可完成使用。
多源支持，支持云监控、SLS、ARMS、DAS、Grafana等多源异构告警集成，通过统一的网关模式进行集成，支持横向扩展。
丰富功能，支持告警抑制、关键关联、告警诊断、关联变更、ChatOps集成、移动端使用等丰富功能。
诊断支持，支持可插拔扩展的诊断架构，用户可以通过自定义告警诊断模版实现告警后的根因定位、工单路由等高阶能力；同时系统也提供了通用的公共组件，如热点日志分析、重保客户验证、多地域管控等。
业务打通，与弹性计算业务天然集成，配合嫦娥平台现有的meta数据可以实现告警精准投送，值班体系打通，以及业务诊断扩展，团队钉群定向投送，团队告警度量等业务视角高阶能力。
应用可观测性
ECS 管控整个稳定性保障以及运维自动化体系都是围绕“应用”来建设的，对于可观测性视角来说，应用维度的可观测性能力至关重要。前面提到的无论是 Data Center、Event、Trace、Dashboard、Alert 都会从有一个重要维度是应用。而应用可观测性建设部分我们完全依托于 ARMS 应用可观测性能力，通过应用接入 ARMS 以及配合 ECS 应用 Meta 嵌入了 ARMS 控制台简化使用成本。
status：云产品健康大盘
https://status.aliyun.com/#/?region=cn-beijing
而从阿里云内部组织研发视角来看我们同样需要能力可以感知到关注产品的全局健康状态，对于 ECS 管控来说这里的全局核心是指：全地域、全服务，全应用。云内监控团队建设了内部的云产品 status 大盘，ECS 管控作为首批集成的云产品，将 ECS 管控的观测能力通过标准化 prometheus metric 的方式输出。同时基于云内监控的开放能力在 ECS 运维平台嫦娥进行了系统集成。
AIOps 与 LLMOps
在可观测性领域，标准化、体系化、平台化更多解决的是规模化带来的运维成本，而随之而来的复杂性问题，难以通过传统的手段解决。比如规模性或者故障反馈链路很长情况，如何快速定位故障根因。
智能运维这个方向以及对于大型研发团队的价值，个人坚定不移地相信。当然 AIOps 甚至最近火热的 LLMOps 只是手段，一切要回到解决业务问题的命题才有价值。而前文提到的 Data Center 里包括 metric、log、trace、meta、知识图谱、业务知识等数据是构建智能运维的基石，也是 AIOps、LLMOps 等可以在业务团队落地的关键。
写在最后