苏宁大企业级立体式监控的构建

微风

2019/03/24 发布于 技术 分类

文字内容
1. 云穆监控 苏宁大企业级立体式监控的构建 汤泳 苏宁易购IT总部监控研发中心总监 1/34
3. 个人简介 汤泳,苏宁易购IT总部监控研发中心总监,苏宁立体化智能监控体系首席架构师。 15年从业背景,数学与计算机科学系毕业,师从中科院自然语言处理黄和燕导 师,主导“云穆”立体式智能监控产品研发。这些产品服务于苏宁控股集团八 大产业4000+系统、10W+服务,保障电商平台日常和大促时段线上系统平稳运 行。目前,致力于苏宁AIOps能力建设。 构建核心系统如下: 用户体验监控 服务端调用链 实时日志分析 智能告警引擎 基础设施监控 多维度融合监控 2/34
4. 目录 1.背景介绍 BACKGROUND INFORMATION 2.监控体系化建设 SUNING MONITOR SYSTEM CONSTRUCTION 3.监控核心系统剖析 THE ANALYSIS OF MONITOR CORE SYSTEM 4.未来蓝图 THE FUTURE BLUEPRINT 3/34
5. 1.背景介绍 系统和服务的复杂性 基础环境的复杂性: 1. 4000+系统,数量还在增加 1. 多数据中心,每个数据中心会划分多个逻辑机房和部署环境 2. 系统间调用方式复杂:大部分使用RSF,也有其他 的方式如HESSIAN,ESB等 2. 一个系统服务器规模往往会很大,例如,缓存服务器就有 可能有上千台服务器 3. 苏宁业务的复杂:既有线上新业务又有线下老业 务,这些业务系统之间会有大量的关联。 3. 服务器类型复杂性:cloudstack,openstack, vmware,kvm,k8s下docker,swarm下的docker。 4/34
6. 目录 1.背景介绍 BACKGROUND INFORMATION 2.监控体系化建设 SUNING MONITOR SYSTEM CONSTRUCTION 3.监控核心系统剖析 THE ANALYSIS OF MONITOR CORE SYSTEM 4.未来的蓝图 THE FUTURE BLUEPRINT 5/34
7. 2.监控体系化建设:过去与未来 APP性能监控v2.0 异常监管系统 链路监控大盘 智能告警平台 APP性能监控v1.0 服务端性能监控 SNMON 监控系统 2014 2013 2016 2015 Zabbix 基础设施监控 AIOps中台建设 多维度时间序列存储 无人化智能监控体系 2018 2017 海量日志分析平台 服务端性能监控 调用链监控 2019 Prometheus基础设施监控 浏览器端性能监控 面向用户体验监控 态势感知告警引擎 OpenTrace标准 多维度融合监控 故障识别与应急 6/34
8. 2.监控体系化建设:蓝图 监控大盘 用户体验监控 影响用户 异常分析 多维度监控分析 数据、事件 日志监控 异常监控 日志分析 动态趋势 海量日志 实时分析 异常告警 端侧监控 移动端性能监控 配置变更事件 应用发布事件 智能告警平台 业务 精准告警 中台 定向发送 会员 PC端性能监控 Http请求 劫持分析 地域 崩溃 卡顿 服务端性能监控 页面性能 慢页面 Js错误 AJAX请求 调用链监控 堆内存 堆外内存 链路分析 依赖分析 GC 线程 系统拓扑分析 服务品质分析 SQL Redis 服务来源/流向 … … 决策分析平台 Ai系统 IT平台 专家系统 统一任务 调度平台 服务管理系统 服务契约管理 基础设施 监控 中间件监控 Web Server MQ Java Runtime Kafka Cache Database 容器监控 网络监控 主机监控 虚拟网络 虚拟机 物理网络 物理机 IDC动环 检测 远程服务调用 框架平台 服务依赖管理 WAF平台 服务状态管理 业务码语义管理 … … 分析 控制 7/34
9. 2.监控体系化建设:系统架构 监控元模型 指 标 跟 踪 事 件 Requests http rsf Service 1 事件 基 于 T A G 多 维 度 关 联 分 析 多策略 采样管理 …Service N 调用链Agent Flume Agent Kafka 事件分析存储 • Elasticsearch • Druid.io Kafka Tag关联 Trace分析存储 • Flink流式处理 • Elasticsearch • HBase OpenTracing 标准上报指标 Tag关联 处理告警 无人化干预 Pull 依赖数据 RCA(根本 原因)分析 指标分析存储 • Prometheus • thanos • M3Db 异常检测 For AIOps 根因定位 配置/事件 变更接入 多维度融合监控平台 自动应急干预 应急干预 决策分析 系统 Prometheus Agent 异常事件与体验的监控 监控闭环 Database 指标 Trace Tag元数据 管理 态势感知 告警引擎 + 智能告警 平台 jdbc 无人化监控与干预 基于对话式任务 型监控机器人 • • • 自然语言处理 OCR图像识别 监控知识图谱 动态告警 阈值算法 AI赋能 交互场景(豆芽) 8/34
10. 目录 1.背景介绍 BACKGROUND INFORMATION 2.监控体系化建设 SUNING MONITOR SYSTEM CONSTRUCTION 3.监控核心系统剖析 THE ANALYSIS OF MONITOR CORE SYSTEM 4.未来蓝图 THE FUTURE BLUEPRINT 9/34
11. 3.监控核心系统剖析:基础设施监控的困境与选型 早期选择Zabbix存在的问题 目前苏宁线上生产环境,Zabbix的监控出现了一些问题: - 面对10w+的虚机,水平扩展出现瓶颈, 采集频率分钟级,难以满足目前线上复杂的问题诊断 - 承载的压力大,数据导出困难, 尤其是聚合查询存在瓶颈 - 数据开放能力,尤其是不能直接对接Kafka,需要修改源码做Kafka的适配 微服务/容器化盛行的当下,从时序存储能力,多维标签化分析能力等视角出发,Zabbix并不是对 docker/k8s监控的最佳选择,迫切需要新的监控技术堆栈来适应日益复杂的动态的云环境。 Prometheus优势 轻松支持上万级别服务器采 集;自带shard功能,可支 持更大规模服务器采集。 自带TSDB数据存储功能,轻松支持 百万/s级别指标采集和存储,平均每 个采样点仅占 3.5 bytes。 02 01 提供原生PromQL,自带查询 函数满足各种统计场景。 04 03 采集探针资源占用少,覆盖 面广,并且非常容易扩展。 06 05 原生支持Kubernetes,etcd 所有的 metrics 都可以设置 任意的多维标签。 10/34
12. 3.1 基础设施监控:采集 CMDB 目标服务器信息下发 采集流程 探针管理 采集服务注册 Consul OSS探针文件存储 Promes-admin 探针管理指令 ACM 获取采集服务信息 监控采集服务器 Prometheus 查询数据 前台展示Grafana 探针指令脚本 采集探针数据(http方式) 监控目标服务器 获取最新探针 流程如下: 1 通过内部云平台申请目标服务器,该服务 器信息将会上传至CMDB。 2 CMDB获取到相应的目标服务器信息并下发 到promes-admin。 3 promes-admin模块下发 探针 管理指 令给 ACM模块,该模块下发探针指令脚本给监控 目标服务器。 4 监控目标服务器执行脚本,根据脚本中的 安装信息到oss探针文件存储中获取探针并安 装完毕。 5 探针安装完毕后,promes-admin在consul 中注册采集服务。 6 Prometheus 通 过 consul template 定 时 从 consul上拉取注册信息生成prometheus配置 (采集targets和labels)。 7 Prometheus通过http方式获取目标服务器 的采集数据。 8 Grafana前端通过调用prometheus的数据 多元化展示各种监控指标数据。 11/34
13. 3.1 基础设施监控:架构 ITSM 后台配置数据服务 PROMES_ADMIN 改造后的GRAFANA 监控数据 监控采集服务器 统一查询视图(Thanos Query集群) 采集服务注册 Prometheus shard1 Thanos-sidecar Consul ……….. Prometheus shardN Thanos-sidecar 生成告警信息 告警消息队列 AlertManager Nginx(proxy) ……….. 监控目标服务器 智能告警平台 告警事件下发 ACM 探针植入 Mysql 指标分发 Kafka 指标分发 远程存储 Nginx(proxy) HTTP-GET PG Others 探针安装更新 12/34
14. 3.1 基础设施监控:性能调优 优化方案 性能指标 普通vm换成了ssd。 node采集机器数量: 100000+台 原先监控10000台机器需要16c/32g的机器3台, 现在用ssd只需要一台。 redis : 原先普通vm采集I/O消耗100%,现在换成SSD 之后消耗10%以内,速度提升了9-10倍。 mysql : 9000+台 由联合节点聚合数据形式换成了thanos微服务 集群形式采集查询。 postgresql :600+台 采用thanos微服务集群模式,可以方便拓展shard 分片,水平拓展。 ping :100000+台 18000+台 prometheus采集数据,采用hash值取模分片形式, 可以自动化分片处理。 采集规模可以随着shard分片的水平拓展而增加。 13/34
15. 3.2 海量日志分析平台:规模 近4000+系统的应用日志、每天10TB+/450亿 条数据,24小时不间断索引服务,峰值 200W/s写入能力,秒级检索能力。 近1000+仪表盘覆盖完整的基于日志监控能力, 保障日常和大促时段线上系统的平稳运行。 CDN全量和异常日志的监控 核心链路(购物车、四级页等)Web日志监控 应用服务器、操作系统内核等日志监控 核心数据链路日志监控 … 14/34
16. 3.2 海量日志分析平台:v1.0 主要配置 ES集群中所有节点使用虚拟机 Kibana 索引按照天生成 数据节点负责数据的索引 Nginx 通过Nginx将用户的检索请求负载在数据节点 ES Cluster Master Data Data 运行状况 部分索引节点负载非常高 索引速度非常慢,经常出现Kafka堵塞情况 Master Data Data 查询响应非常慢 并发访问数为10左右时,ES已经不能支撑 flume Log source flume kafka 原因分析 部分虚拟机在同一个物理机上,数据节点间的资源竞争非常激烈 数据节点同时承担索引和检索,负荷重 索引时有非必须的字段被索引(比如_all) 按天生成的索引太大 单索引 15/34
17. 3.2 海量日志分析平台:v2.0 Kibana 主要优化 引入client节点,将检索的请求从数据节点转移到client节点。同时client Nginx 节点通过river从kafka中拉数据将数据导入ES 移除在同一物理机上的虚拟机,并增加了一批物理机 ES Cluster 关闭_all字段 Master Client Data Master Client Data 并且索引按照小时生成 根据日志类型划分不同的索引文件 运行状况 非大促期间,索引和检索速度基本能达到秒级,但是大促期间,出现日志 量膨胀以及访问人数过多时,索引和检索速度很慢 随着集群规模的增加,运维的工作量也急剧增加 flume Log source flume kafka 原因分析 多种类型的日志(例如偏统计分析的web日志,偏检索的应用日志)混在 一个大集群中,不同的日志间相互影响 缺少必要的降级功能 16/34
18. 3.2 海量日志分析平台:v3.0 Kibana 主要优化 Nginx 根据日志类型,将大集群拆分成不同的小集群 将data节点替换成物理机 Tribe Tribe 提供按照系统、文件路径、等级等应对大促期间的日志洪峰系统进行降级 的功能 ES Cluster1(统计型) Data Master ES Cluster2(检索型) Data Master 运行状况 非大促期间,索引和检索速度达到秒级。大促期间,通过必要的降级,能 client flume Log source 够保证重要系统的索引和检索速度达到秒级。 client Kafka hadoop 存在的问题 随着业务量的快速增长,简单的按照分析类型进行集群拆分已不能满足要 flume 求,并且增加机器资源容量并不是线性增加。 ES Cluster3(离线) 用户希望保留7天以前以及大促期间数据,集群容量以及性能也存在严重问 题 Master Data Kafka River 17/34
19. 3.2 海量日志分析平台:v4.0 Kibana 主要优化 Nginx 在③的基础上同时支持按照业务 Tribe 划分以及数据类型划分集群 Tribe 使用不同的硬件划分Hot/Cold节 点,业务低谷将历史数据迁移到 业务 Cluster1 Exception Log Cluster Type Cluster1 Hot Cold Hot Cold Data Data Data Data Data Data Data Data Master client Kafka1 Master 业务 Cluster N Master Data Cold节点 针对Exception等重点关注且长期 保留分析的数据单独存储。 client client Type Cluster N Kafka2 Offline Cluster Master 不同业务 Log flume 不同类型 Logflume hadoop Kafka Data client 18/34
20. 3.3 调用链监控:背景 为什么需要服务端调用链监控? 出现问题后,定位困难,需要对整个调用链路 有个完善的监控。 链路复杂,需要清晰的链路图谱反映服务之间 的依赖、调用关系。 整体系统性能及运行情况,需要明确的体现, 才能根据实际情况调整资源。 如何实现服务端调用链的串联? 调用上下文 : TraceId • 关联一次请求的不同Agent上的日志,保证全局唯一。 • TraceId = IP + Timestamp + 顺序数 + 进程号 调用上下文: RpcId • 标示一次请求的顺序和嵌套关系,也在各个系统间传递。 • 调用关系: 同步、异步、一对多调用 • 采用多级编号: 0、0.1、0.2、0.2.1 、…… 19/34
21. 3.3 调用链监控:架构 Agent 实时分析 kafka Flink 代码级定位:轻量级 Agent,以不高于 10%的 性能消耗,采集 JVMs、线程、 SQL、Kafka 等性能指标,可分析表示层、业务层、数据层 代码执行性能,给予最科学的代码优化参考。 系统的错误数和访问 量总数 关注链路和其中异常 链路的个数 ElasticSearch Portal HBase 离线分析 SparkSQL 报表统计 对比统计 Druid 侵入性低,安全稳定:对代码无侵入,对服务运 行无影响,有效保障代码和 数据的安全性。 全 方 位 性 能 监 控 : 支 持 主 流 Http Server (Apache/ Nginx) , Application Server (Tomcat/ Jboss/ Netty/ WAS),DataBase (MySQL/ Redis),MQ (Kafka),全面多 角度 监控分析。 支持自定义插件:开放的 API,支持用户自定义 插件采集和分析数据,灵活 度高,扩展性强。 20/34
22. 3.3 调用链监控:根因分析 核心思想参考:Root Cause Analysis of Anomalies of Multitier Services in Public Clouds 数据采集子系统 SPM Request Tracing Infra Metrics Data Collection History TSDB 构建VCG(VM 通信图) 检索CMDB 相似度计算 CMDB主数据 构建APG(异常 繁殖图) 提交请求 异常提交源 • 异常检测 • 告警 随机游走 根因定位子系统 配置变更列表 + 排名后的根 因列表 输出:多维度融合监控系统 IEEE/ACM 2018 线上环境两种类型的异常繁殖: • 同一个物理机上的多个虚机存在资源争抢造 成一个虚机上的异常(资源利用率)繁殖到 其他的虚机,引发服务调用的异常。 • 服务调用链路的多个服务组件间的异常繁殖, 与资源争抢无关,例如:错误的配置变更、 发布导致回退等。 构建VCG与APG: • 海量的服务调用,需要可伸缩的图数据库做 构建的支撑(JanusGraph)。 • 基于两种类型的异常繁殖,构建依赖关系图 最终从VCG->APG。 相 似 度 计 算 : 基 于 Pearson Correlation Coefficient定义相似度函数。 随机游走算法:高的相似度未必是真正的根因, 通过随机游走确定最大概率的根因列表。 21/34
23. 3.4 实时告警引擎:背景 做出具有态势感知的告警引擎 对产生的告警事件,能够实时下发告警通知。 对告警规则能够进行自由灵活的配置。 改变以往统一设置告警阈值的传统,依据动态增长趋势确定告警阈值。 告警通知智能收敛,避免告警风暴的产生。 技术实现 采用flink对告警规则进行实时流式计算。 使用ANTL动态解析告警规则语法。 根据自研告警状态机,管控告警事件生命周期。 实现动态计算同环比异常趋势生成告警事件。 22/34
24. 3.4 实时告警引擎:方案选型 方案 简述 实时流 式计算 (单条) 分布式 状态管理(中间数据等) 延迟 语言支持 Hadoop整合 Akka+Cassan dra 状态依赖于外部存储 (Cassandra不一定抗的住) 支持 支持 不支持,依赖外部存储 不确定 java 没有整合 Akka+Redis 状态依赖于外部存储(Redis), 支持 衍生出其他不可控的单点故 障,而且开发工作量和难度 大 支持 不支持,依赖外部存储 不确定 java 没有整合 Spark Streaming Spark Streaming 哪里都好,就是不支持真正 意义上的流式计算(单条) 不支持(小 批量) 支持 有状态(RDD) 秒级 Java Scala python 整合的比较好 Storm Storm为流式计算而生,但 是无法满足我们需要状态管 理的场景,需要引入外部存 储。 支持 支持 无状态 毫秒级 Jvm系 Ruby Python Perl jacascript 整合一般 Flink 流计算方面综合了上面两者 的优点,且基于pipeline模式 要优于spark 支持 支持 有状态,自己管理内存 毫秒级 Java Scala python 整合非常好 23/34
25. 3.4 实时告警引擎:规则语言 告警规则的抽象 SELECT avg(jvm_usage) AS jvm_usage_avg FROM some_agent WHERE avg(jvm_usage) > 200 FOR LAST 2 MINUTES 过去 2 分钟内,JVM 平均使用率大于200M则触发告警。 SELECT max(disk_usage) AS disk_usage_min FROM some_agent WHERE max(disk_usage) > 1000 FOR LAST 1 当磁盘使用量大于 1000G 的时候触发告警。 1. 2. 3. 4. SELECT 部分相当于指标(计算、实时)结果集 FROM 相当于数据源 WHERE 相当于触发告警条件 FOR LAST 相当于计算队列 24/34
26. 3.4 实时告警引擎:语法解析 告警规则语法解析树 Prog SELECT avg(jvm_usage) AS jvm_usage_avg FROM some_agent WHERE avg(jvm_usage) > 200 FOR LAST 2 MINUTES SELECT NameOp1 Raw SQL DSL Metrics (Map) Event Process Result … WHERE BoolExpr NameOp2 NameOp2 column Is Alarm (Boolean) FROM AS alias SQL AST Tree Buffered Event Queue Current Event Process Model(RuleTemplate) 25/34
27. 3.4 实时告警引擎:生命周期管理 告警事件生命周期 POLICY_CONTINUES_CRITICAL CRITICAL POLICY_OPEN_CRITICAL POLICY_CLOSE_CRITICAL POLICY_UPGRADED NORMAL POLICY_DOWNGRADED POLICY_OPEN_WARNING POLICY_CLOSE_WARNING WARNING POLICY_CONTINUES_WARNING 26/34
28. 3.4 实时告警引擎:环比告警 环比告警事件 SELECT responseTime , avg(responseTime) FROM tableA WHERE (responseTime - avg(responseTime)) / avg(responseTime) > 0.05 * period(now, -1, day, 5, min) period(calTime, delayNum, delayUnit, durationNum, durationUnit) calTime: 需要进行环比计算的时间节点描述; delayNum: 环比周期时间; delayUnit: 环比周期单位; durationNum: 窗体时间; durationUnit: 窗体单位 27/34
29. 3.4 实时告警引擎:架构 态势感知告警整体架构 Kafka Http ETL Module ETL(UOM) CEP Module Static Resources Dynamic Resources Management Module Management Raw Metric Message CEP Engine Kafka Http ETL(DSA) Rule Resource Alert event Alert state Machine Kafka Http Rule SQL Processor ETL(BPM) Apollo Alert System 28/34
30. 3.5 用户体验监控:价值模型 针对苏宁IT提出的“稳定、安全、极致、快”中的“极致”维度,UOM构建面向用户体验的感知能力: 首先通过对用户体验数据的采集和分析,将各产品的建设能力进行量化;其次利用量化的数据驱动各 团队提升产品“极致”能力,主动关怀用户;然后帮助产品团队快速定位异常及责任方,对影响用户 的异常进行定位、治理、考核及提升;最终实现用户所期待的超级体验。 用户维度,生成用户 画像,全面复现用户 在任一场景中的轨迹, 深入感知用户的体验 。 并触发相对应的用户 关怀。 产品维度,提供任一 场景下的用户体验分 析,给出用户体验感 知的趋势曲线,全面 刻画产品的体验状况, 定位到具体的负责人。 能力维度,用户的体 验感知都能溯源、定 位至对应的产品能力 环节,通过全覆盖的 串联分析链路能快速、 精准定位用户体验触 点关联的前中后台系 统。 运营维度,通过态势 感知引擎和机器学习 算法构成的智能告警 能捕捉任何用户体验 的变化状态,及时了 解产品健康状况,决 策产品异常治理方向 及目标。 29/34
31. 3.5 用户体验监控:架构 HIVE 数据采集 日志存储 ETL移动端 异常 Topic 大数据平台 对实时数据和历史数据 采用不同数据平台的异 常关联策略。 通过对异常数据计算动 态环比增长率,实时下 发告警事件 关联 调用链系统 YARN Topic 实时采集移动端和PC端 的异常日志数据。 HBASE FLINK Elastic Search Cluster 流式计算平 台 SPARK 事件 智能告警 STORM 用户体验监控 态势感知 用户轨迹 异常TOPN 异常对比率 异常字典 任一维度 异常详情 影响用户数 核心页面 权限管理 30/34
32. 3.5 用户体验监控:性能指标 每日数据处理量 10TB+ 服务端TPS 100w+ 移动端TPS 14w+ 智能告警通知 10-20秒 APP接入数量 3000+ 异常数据定位分析 秒级 31/34
33. 目录 1.背景介绍 BACKGROUND INTRODUCTION 2.监控体系化建设 SUNING MONITOR SYSTEM CONSTRUCTION 3.监控核心系统剖析 THE ANALYSIS OF MONITOR CORE SYSTEM 4.未来蓝图 THE FUTURE BLUEPRINT 32/34
34. 4.未来的蓝图 监控元模型 指 标 跟 踪 事 件 未来规划的能力 Requests http rsf Service 1 事件 基 于 T A G 多 维 度 关 联 分 析 多策略 采样管理 …Service N 调用链Agent Flume Agent Kafka Kafka 统一时序存储 • 时间序列数据 • 事件/日志存储 • 图操作/算法 多维度融合监控平台v2.0 自动应急干预 应急干预 处理告警 无人化干预 无人化监控与干预 基于对话式任务 型监控机器人 决策分析 系统 Prometheus Agent OpenTracing 标准上报指标 Pull 依赖数据 时间序列分析操作/算子、高效压缩比 高维数据聚合 分布式持久化 统一的表达式语言 事件检索 异常事件与体验的监控 监控闭环 Database 指标 Trace Tag元数据 管理 态势感知 告警引擎 + 智能告警 平台 jdbc • • • 自然语言处理 OCR图像识别 监控知识图谱 RCA(根本 原因)分析 配置/事件 变更接入 异常检测 For AIOps 根因定位 AIOps中台 • 流式处理 • 分布式模型训练 • 基线评估 • 结果修正 动态告警 阈值算法 AI赋能 交互场景(豆芽) 33/34
37. 想了解更多苏宁云产品,请关注公众号和官网信息。 https://www.suningcloud.com/ THANKS! 34/34