基于 APM 的智能运维体系在京东物流的落地和实践 付正全

2020-03-01 319浏览

  • 1.基于APM的智能运维体系在京东物流的落地和实践 付正全 京东物流 架构师
  • 2.
  • 3.自我介绍 付正全,京东物流架构师,国家认证信息系统项目管 理师,曾任浪潮集团系统架构师,专注监控平台研发 工作 8 年,研究过市场上数十家厂商的监控平台产品, 对 DevOps 和监控平台有比较深入的了解。目前负责 京东物流火眼监控平台的架构设计和开发工作。
  • 4.目录 ⚫业界智能运维发展现状及趋势 ⚫智能运维体系建设方法论 ⚫大规模实时监控平台的实践方案 ⚫智能故障定位与处理实践 ⚫ APM 在京东物流的落地实践 ⚫ 智能运维(AIOps)落地规划
  • 5.业界智能运维发展趋势
  • 6.新的问题 运维人数不变,管理机器数翻倍 网络拓扑日益复杂,资源云化,虚拟资 过去1:n → 现在1:10𝑛 源频繁弹性伸缩。不可靠的CMDB 1 2  3 正在消失的运维 运维从业者减少,运维专家匮乏 4 运维平台日趋复杂,缺乏统一规划 公司内部监控/运维系统繁多,形成数据孤岛
  • 7.越来越复杂的应用拓扑 前端网页 请求 无线客户端请求 服务调用 JDBC 应用B 服务调用 数据库 发消息 应用A 前端网页 请求 应用A 开放平台 API 请求 服务调用 服务调用 应用G 收消息 收消息 应用D 应用C 应用E 服务调用 服务调用 应用H 存取 JDBC JDBC 数据库 收消息 服务调用 应用F 消息服务器 读缓存 写缓存 分布式 缓存 难 系统问题定位 分布式 文件系统
  • 8.快速发展的APM APM (应用性能管理)市场规模逐年递增 APM市场规模(亿美元) 70 ◼目前,全球APM市场规模大约在60亿美元左右,预 计在五年内达到90亿美元 60 50 40 ◼APM成为ITOM成长最快的领域 30 ◼APM能够对企业的关键业务应用进行监测、诊断分 析、优化,最终能够提高应用的可靠性和质量,保证 良好的用户体验,降低IT成本 20 10 0 2014 2015 2016 2017 2018
  • 9.运维角色转变 背锅侠 被动响应 产品意识 技术运营 需求提炼 推广落地 产品化开发 业务数据分析 产品化落地 过程改进 业务增值 架构运维 事件处理 架构标准化 业务分析 架构实施 业务预测 架构优化 主动求变 救火员 运维价值凸显 新运维时代来临
  • 10.目录 ⚫业界智能运维发展现状及趋势分析 ⚫智能运维体系建设方法论 ⚫大规模实时监控平台的实践方案 ⚫智能故障定位与处理实践 ⚫ APM 在京东物流的落地实践 ⚫智能运维(AIOps)落地规划
  • 11.智能运维体系建设方法论 ◼统一规划、避免重复建设 ◼标准化是前提 ◼产品化设计、产品化开发 ◼服务驱动 ◼运维中台 ◼业务增值 ◼过程改进
  • 12.智能运维体系建设方法论 ◼闭环 ◼生命周期管理 ◼流程管理 ◼审计归档
  • 13.目录 ⚫业界智能运维发展现状及趋势分析 ⚫智能运维体系建设方法论 ⚫大规模实时监控平台的实践方案 ⚫智能故障定位与处理实践 ⚫ APM 在京东物流的落地实践 ⚫智能运维(AIOps)落地规划
  • 14.大规模实时监控平台V1.0 大规模监控平台架构
  • 15.大规模实时监控平台V1.0 多维度使用率分析助力企业降本增效 ◼多级部门、应用多维度统计 ◼日报、周报、同比、环比统计 ◼低资源使用率TOP统计 ◼低负载应用榜单 ◼低资源使用率应用优化建议 使用率报表
  • 16.大规模实时监控平台V2.0 ◼整合多端数据,解决数据孤岛问题 ◼性能分析、告警分析更加准确 ◼更全面评估应用健康状况
  • 17.大规模实时监控平台V2.0 整合各种应用维度的指标分析,提供更全面的应用数据分析和故障诊断 ◼系统指标 ◼调用链指标 ◼日志分析 ◼数据库指标 ◼JVM指标 ◼应用拓扑自动探测 应用健康报告
  • 18.大规模实时监控平台V2.0 日志处理架构
  • 19.大规模实时监控平台V3.0 产品规划
  • 20.大规模实时监控平台V3.0 预测分类: 故障预测、容量预测、性能预测 预测算法: LSTM、多元线性回归、决策树、随机森 林、神经网络、朴素贝叶斯分类、最小二乘 法、支持向量机 … 重点关注: 算法匹配度评分 Kpi自动分类并匹配预测算法 日历适配、基于节假日的机器学习算法 基于业务关联关系的预测算法 预测
  • 21.大规模实时监控平台V3.0 红绿灯 大屏 可视化
  • 22.目录 ⚫业界智能运维发展现状及趋势分析 ⚫智能运维体系建设方法论 ⚫大规模实时监控平台的实践方案 ⚫智能故障定位与处理实践 ⚫ APM 在京东物流的落地实践 ⚫智能运维(AIOps)落地规划
  • 23.智能故障处理 传 统 故 障 处 理 被动故障处理: 1. 事后处理:出先故障后开始处理,易造成业务中断; 2. 人工处理:基于工作流的故障上报和处理,层层通知手工定位故障原因,故障修复时间长; 3. 无计划性:多为突发情况,进行临时处理,难免有疏漏之处; 4. 报警爆炸:随着业务增长,报警越来越多,运维人员不堪其扰 主动故障处理: 1. 事前感知:通过故障预测算法,预测故障类型及发生时间,并提前通知项目负责人; 2. 自动处理:决策引擎根据预设的事件处理策略,自动执行处理指令以及基于机器学习的自动故障处理; 3. 定时巡检:平台化的定时巡检机制,给出应用健康报告,问题早发现早解决; 4. 报警收敛:对告警做告警筛选、过滤、合并操作,大大减少报警数量;
  • 24.故障快照 ◼出现告警自动抓取现场快照信息 ◼快照信息持久化保存 ◼根据自学习的知识库提供异常原因分析 ◼集成Arthas诊断工具,快速诊断问题
  • 25.根因分析
  • 26.基于双向过滤的告警通知 ◼为保证告警信息能够及时准确的传达给系 统管理员,监控模块需要实现灵活的告警通 知策略 方法告警 调用链告警 日志告警 业务告警 资产 资产 恢复 资产 轻度 中度 严重 业务告警 过 ◼双重过滤的通知方式:资源和通知联系人 分别应用通知策略,实现对通知的双重安全 过滤 通知处理引擎 滤 每天 每月 时间规则 每周 邮件 自定义 短信 咚咚 微信 过 滤 高级通知策略
  • 27.目录 ⚫业界智能运维发展现状及趋势分析 ⚫智能运维体系建设方法论 ⚫大规模实时监控平台的实践方案 ⚫智能故障定位与处理实践 ⚫ APM 在京东物流的落地实践 ⚫智能运维(AIOps)落地规划
  • 28.业界分布式跟踪系统 Google:Dapper Naver:Pinpoint Twitter:Zipkin 点评:Cat 阿里:EagleEye 京东:JTrace、JD-Hydra(已废弃)、Callgraph、SGM 新浪:Watchman 美团:MTrace 又拍云:Tail 其他: OpenTracing、 SkyWalking 服务厂商:Compuware、iMaster、博睿Bonree、听云、New Relic、云智慧、 OneAPM、AppDyn、Amics
  • 29.京东物流Jtrace分布式跟踪系统 定义了四个具体的设计目标 低消耗 应用级透明 延展性 智能分析
  • 30.JTrace数据结构 核心数据结构由Span, Trace, 和 TraceId组成: • • • •Trace:多个Span的集合;Span:RPC跟踪的基本单元; SpanEvent:内部方法调用基本单元TraceId:• TransactionId (TxId) : 全局唯一消 息的ID • SpanId • ParentSpanId (pSpanId)
  • 31.Jtrace应用示例
  • 32.架构设计 七大能力 : • 分布式事务跟踪,跟踪分布式应用消息 • 自动检测应用拓扑,帮你搞清楚应用的架构 • 水平扩展支持大规模服务器集群 • 提供代码级别的可见性以便轻松定位失败点和瓶颈 • 使用字节码增强技术,添加新功能无需改动代码 • 集成SQLAdvisor • 智能化采样率
  • 33.字节码增强技术JavaAgent:java -javaagent:myagent.jar=mode=testTest 功能: •可以在加载class文件之前做拦截,对字节码做修改 •可以在运行期对已加载类的字节码做变更,但是这种情况下会有很多的限制。 •还有其他一些小众的功能 • 获取所有已经加载过的类 • 获取所有已经初始化过的类(执行过clinit方法,是上面的一个子集) • 获取某个对象的大小 • 将某个jar加入到bootstrap classpath里作为高优先级被bootstrapClassloader 加载 • 将某个jar加入到classpath里供AppClassloard去加载 • 设置某些native方法的前缀,主要在查找native方法的时候做规则匹配
  • 34.java字节码框架 Agent内部是采用微内核+插件的方式 微内核: plugin 封装了通过ASM或Javassist字节码框架对类进行增强 插件: 插件中指定要增强的类和方法以及增强内容 plugin kernel plugin 优点 1. 要求更少开发资源 手工埋点 2. API可以更简单并最终减少 bug的数量 plugin 缺点 1. 开发人员必须修改代码 2. 跟踪级别低 1. 开发人员不需要修改代码 1. 开发难 自动埋点 2. 可以收集到更多精确的数据因 2. 开发人员要求高 为有字节码中的更多信息 3. 增加bug发生的可能性
  • 35.字节码增强的价值 隐藏API 一旦API被暴露给开发人员使用,我们作为API的提供者,就不能随意的修改API。这样的限制 会给我们增加压力。 而使用字节码增强技术,我们就不必担心暴露跟踪API而可以持续改进设计,不用考虑依赖关 系。 容易启用或者禁用 使用字节码增强的缺点是当JTrace自身类库的采样代码出现问题时可能影响应用。不过,可以通过 启用或者禁用JTrace来解决问题,很简单,因为不需要修改代码。 -javaagent:$AGENT_PATH/pinpoint-bootstrap-$VERSION.jar-Dpinpoint.applicationName=
  • 36.APM性能优化 • 使用二进制格式(thrift协议) • 使用变长编码和格式优化数据记录(thrift CompactProtocol) 677个,接入机器近9000台 目前接入应用 • 用常量表替换重复的API信息,SQL语句和字符串 • 处理大量请求的采样 经过数论压测计算Agent端会有3%的性能损失 • 使用异步数据传输来最小化应用线程中止 • 使用UDP协议传输数据 到目前为止还没有出现因为Agent出现性能问题。
  • 37.目录 ⚫业界智能运维发展现状及趋势分析 ⚫智能运维体系建设方法论 ⚫大规模实时监控平台的实践方案 ⚫智能故障定位与处理实践 ⚫ APM 在京东物流的落地实践 ⚫智能运维(AIOps)落地规划
  • 38.AIOP总体建设思路
  • 39.AIOPS落地规划
  • 40.
  • 41.