冯富秋-阿里基于内核剖析的故障分析和智能运维实践.pdf

1、阿里基于内核剖析的故障分析和智能运维实现冯富秋 资深技术专家目前致力于阿里超大规模数据中心的稳定性和可靠性建设，新硬件与软件的协同设计等基础技术领域的研发与工程化落地。主要研究领域包括：SOC芯片的前端构建、仿真，电信级Linux内核研发，百万级系统智能运维，以及行业应用的全生栈软硬件技术及其融合应用。曾参与中国嵌入式系统学科体系建设，国家电网智能电网国家标准的制定。运维的趋势运维的现状和挑战更好的运维体验龙蜥运维SIG（兴趣组）运维的趋势FaaS、Serverless只关注自身的应用实现，开发更为专注。对整体运维环境无感知，无法应对任何的基础设施运维工作，对运维工作无所适从。容器化部署/Pa

2、aS只关注业务容器，但可感知系统相关指标。开发人员连带运维支持,对系统的了解低，运维难度大。传统机房以及IaaS方式用户感知操作系统以下组件，对全栈软件的理解度高。存在基础设施的运维人员，运维的成本高云原生倒逼智能化“零”运维New Future on Cloud运维的现状和挑战目前的运维产品现状配置部署管理系统监控社区工具New Future on Cloud系统配置、批量程序部署、批量运行命令等提供系统的基本指标监控以及基于基线的告警大量专业的社区工具Ansible/AWXGrafana/zabbixperf/ftrace配置部署管理系统监控社区工具目前的运维的挑战New Future o

3、n Cloud基于操作系统现有的数据接口、日记进行采集基于基线的告警存在大量的误报需要专业级别系统运维人员通过大量工具的组合应用。开环的执行过程无法对部署的系统进行稳定性评估不知其然只知其然而不知其所以然难知所以然AI计算任务TensorFlow框架Linux操作系统大量中间件的使用，让问题离根因越来越远New Future on Cloud微服务框架RPC框架GlibCPython计算存储网络传统IaaS提供商的视角传统运维平台的视角客户的应用视角进程A读写文件大量Page Cache形成内核的复杂性导致问题解决难度居高不下New Future on Cloud系统空闲内存急剧减少进程B申请

4、内存并访问内存回收可能引发的内存不足告警可能引发的内存访问时延更糟的是，我们没有办法知道，究竟在哪个时刻会引发问题。进程B的内存问题，很难让运维人员关联到进程A的写文件操作糟糕的是，不仅仅是案例所阐述的内存问题，在操作系统内部网络、IO、内存、调度皆大量存在类似问题。内存案例更好的运维体验应用自顶向下的分析实现诊断功能与客户应用表象的关联，任何的运维建议都是客户可直接理解和操作的。基于内核深度剖析智能一体化运维流程监控与深度问题诊断联动，知其然又知所以然；集群化的大数据、AI分析，实现智能基线、智能告警、智能问题分析。降低应用的运维门槛深度剖析问题成因智能化告警、监控诊断联动更好的运维体验Ne

5、w Future on Cloud发挥内核的全视角优势，深度分析进程间行为关联深度剖析内核自身，以直观、可读的形式剖析内核行为SysOM（System Operation&Maintenance）是由龙蜥社区系统运维 SIG 打造的一站式操作系统运维平台，致力于解决业内工具碎片化，门槛高的挑战。深入内核的运维SysOM运维中的内存难题无法掌握内存分布无法从系统中直接获取当前内存的分布和内存健康状况用户无法快速确定耗内存的应用或者容器无法快速找出内存使用Top进程或者容器无法快速诊断分析内存问题无法快速找到内存问题及其根因，分析需要大量数据和已知经验SysOM 2.0 内存诊断功能和实践场景OO

6、M诊断Cache分析内存大盘查询整个系统的内存健康，快速查看内核用户态的内存占比，进程使用分析主要使用场景：1、快速检查当前内存的健康程度2、快速发现内存消耗最大板块给出系统OOM时的内存状态和不同OOM的原因和建议，主要使用场景：1.系统或者cgroup下进程被杀掉，检测是否发生OOM2.查询OOM原因，并做出优化改进，预防下次发生给出多个维度cache分析主要使用场景：1、分析主机或者容器Cache占比多时的占比情况SysOM 2.0 内存诊断-内存大盘SysOM 2.0 内存诊断-OOM诊断SysOM 2.0 内存诊断-Cache分析常见调度问题调