在政府企业数字化转型的背景下，诸多大型政企客户选择混合云作为业务上云的整体方案。然而，混合云客户场景下的可观测领域，却面临着和公有云场景和大型互联网企业内部场景截然不同的几大困难：异构的基础设施和混合云架构下复杂的应用和云平台网络环境让监控系统本身难于部署和稳定运行，面向传统应用架构和旧应用极高的改造成本让指标、链路、日志监控难以落地；基于云平台监控和客户自建及第三方应用级监控工具相互割裂难以整合，客户侧技术栈老旧、云原生化程度不足等。

面对这些技术挑战，我们在面向业务指标实施计算和应用基础监控的阿里集团监控平台的基础上，通过全方位监控架构升级和开源架构融合，以及多项的监控能力创新，打造了面向混合云客户的一体化监控平台，并在数十家大型政企客户侧落地了面向混合云的全景可观测能力，显著提升了客户侧云上业务故障发现、定界及处理的时效性，保障了诸多关系到国计民生的云上政企业务应用的稳定运行。

演讲提纲：

1. 在混合云场景下落地可观测能力的技术挑战
   • 政企行业云上数字化业务需要全景可观测能力
   • 异构的基础设施和混合云架构下的监控规模化挑战
   • 传统应用架构及技术栈之下落地指标、链路、日志全景监控的挑战
   • 云平台运维和应用运维割裂背景下的一体化故障处理的挑战
   • 将监控工具能力转化为监控业务效果的挑战
   • 混合云全景可观测监控平台技术演进方案
2. 面向大型互联网企业的企业级监控平台技术架构
   • 混合云全景可观测技术能力布局和技术要点
   • 传统业务指标实时计算架构和 Promethues 架构的融合技术方案
   • 应用指标监控架构和应用链路监控架构的融合技术方案
   • 面向行业客户的黄金指标智能异常检测技术方案
   • 混合云一体化监控事件定级技术方案
   • 面向混合云异构基础设施的监控规模化改造和小型化改造方案
3. 混合云全景可观测平台落地案例及效果
   • 全景监控能力落地案例展示
   • 云+应用一体化监控定级落地案例展示
4. 混合云全景可观测技术展望和规划

你将获得：

• 听众能够了解到对大型互联网内部的中台产品进行架构升级的技术方案和设计思路；
• 听众能够学习到云原生可观测性领域下指标监控、链路监控架构的差异和融合方案；
• 听众能够学习到在客户生产环境落地的智能监控算法设计和实现的思路；
• 听众能够学习到如何通过白盒化、结构化的方式处理海量复杂的多层监控报警事件；

随着云计算技术和基础设施的成熟，以及新的架构范式的出现，应用部署介质逐渐从物理机/虚拟机转变为容器部署，由此带来新的监控场景：监控对象具有自动伸缩的能力、监控对象具有明显更多的维度信息、监控对象之间存在拓扑关系。传统的监控概念已经无法满足新的架构范式，可观测性概念的引入带来了新的解决问题的视角。通过重新审视指标、链路、日志三类数据，重点关注应用视角，实现自上而下的观测分析能力，为业务快速排障提供一站式的系统支持。实现此目标面临如下挑战：

• 如何解决多云环境下，网络隔离与数据差异导致的采集上报复杂性问题？
• 如何实时处理多维度高基数的指标数据，快速发现异常点位，并定位到相关链路与日志？
• 如何构建接入层、应用层、数据层、基础设施层的指标关联，实现应用的全景可观测？

演讲提纲：

1. 简述 TT 在可观测性领域的演进过程
   • 多云环境以及异构的基础设施带来的挑战
   • 业务云原生化带来的监控指标维度爆炸问题
   • 传统的 Zabbix 监控遇到哪些技术瓶颈
2. 基于 Prometheus 构建分布式监控平台
   • 引入 Prometheus 能够解决什么问题
   • 针对 Prometheus 的集群方案进行对比
   • 基于 Prometheus 构建分布式监控平台
3. 以应用为入口重构监控平台的研发视角
   • 云原生带来对监控视角的重新思考
   • 以应用为入口重构监控平台的研发视角
4. 一站式应用可观测平台的展望与规划
   • 打通接入层、应用层、数据层、基础设施层的监控能力
   • 打通指标、链路、日志的排障过程
   • 简述TT在应用可观测平台上的展望与规划

你将获得：

• 听众能够了解到大规模 Prometheus 集群如何完成联邦的技术方案；
• 听众能够了解到 TT 对于打通指标/链路/日志三类数据的方案构思；
• 听众能够了解到 TT 如何以研发视角进行监控系统的重构。

近年来云原生可观测性领域变得非常活跃，有人会问，可观测性不就是监控吗？不全是。引用可观测性业界大咖 Baron Schwarz 给出的定义："监控告诉我们系统的哪些部分是不工作的，可观测性告诉我们那里为什么不工作了"。

目前可观测性的三大支柱依然是 Trace（追踪）、Log（日志）、Metric（指标）

Trace 追踪方面，当前主流开源方案面临 TraceSDK 接入成本高，JavaAgent 接入风险高等问题，而后端存储又面临因高 TPS 写入带来的高成本问题，我们对比 Skywalking、Pinpoint、Opentelemetry、ElasticAPM 等开源解决方案后，最终选择 Skywalking 作为我们的基础原型，在 JavaAgent 现有基础上抽取我们埋点 TraceSDK，提供两种埋点方式供业务接入，同时服务端采用 TiDB 作为追踪数据的存储，并持续优化例如 Batch 写入、写入前压缩、写入前合并等手段，最终实现微众银行全链路追踪方案。

Log 日志方面，当前主流开源方案 ELK 面临存储成本高、日志高峰容易丢数据、数据脱敏等一系列问题，我们从最初的 ELK 定制最终转向 LOKI+Grafana 的日志系统方案，并加入 WeMQ 消息中间件缓存模块、MSS-LOGIMPORT 日志导入模块来解决日志存储成本、数据定制脱敏等问题，最终实现微众银行低成本日志平台方案。

Metric 指标方面，当前云原生主流指标方案是 Prometheus，我们主要实现 Prometheus + JavaAgent 结合，来实现行内指标数据统一采集、统一存储查询并基于 WeMQ 实现指标数据共享和指标告警。

演讲提纲：

1. 云原生可观测性背景
2. 云原生可观测性之追踪
   • 追踪系统的核心挑战
   • 微众银行追踪技术选型
   • 微众银行追踪定制改造
   • 微众银行追踪最终效果
3. 云原生可观测性之日志
   • 日志系统的核心挑战
   • 微众银行日志系统技术选型
   • 微众银行日志定制改造
   • 微众银行日志系统最终效果
4. 云原生可观测性之指标
   • 指标系统的标准实现
   • 微众银行指标系统实现方案
5. 未来展望

你将获得：

• 通过 Skywalking 的改造实现追踪数据采集的落地，实现高性能数据写入以及节省存储成本
• 通过开源系统 LOKI 的改造，实现低成本日志系统

介绍 TiDB 中可观测性的技术实现，包括如何统计每种 SQL 语句的 CPU 资源使用率，statements_summary， 慢日志，以及 Continuous Profiling。

演讲提纲：

1. TopSQL 的实现，统计 SQL 的 CPU 资源使用率
2. Statements_summary 的实现
3. 慢日志系统表的实现
4. Continuous Profiling 的实现

你将获得：

• 学习到 CPU Profiler 的实现原理和 demo
• 了解可观测性对系统的性能影响该如何解决