APM应用性能监控的应用.pptx

APM应用性能监控的应用技术创新，变革未来大纲如何应对性能问题tutorabc对APM的一些实践TGOP私有云平台关注性能, 从现在开始!一个真实的调优案例线上某API服务高峰时段CPU用量超过95%. 期间API响应变慢.重启服务后, 问题依旧存在.之前通过添加新服务器缓解问题.考虑到近期业务量有大幅增长, 同时为节 约计算资源, 需要对服务进行优化.PS: 本地环境可以重现该问题.如何优化?选择工具Windows平台下对应的工具程序日志程序日志JProfiler(Java), top, netstat等VS Profiler, Perfmon, Sysinternals Suite等gdb, Perf {PMU, TracePoint}WinDbg, Perfview {ETW}问题分析: 本地测试得到的性能参数问题分析: PerfView采集ETW数据问题分析: XPerf查看CPU时间分布如果是Perf…/brendangregg/FlameGraph问题分析: 定位问题代码解决方案验证方案性能调优的挑战与应对挑战应对重现重现概率低, 依赖环境.监控覆盖足够的广度和深度.日志分析, 耗时耗力.日志具备多个维度的关联性.验证问题复杂, 牵涉知识点众多.合适的工具, 如Perf, Perfview等.解决方案需要进行验证.人的经验与技术积累.找出重现步骤, 对比测试, 有针对性 的进行监控.新的问题用户应用程序开发框架 & 运行时 操作系统网络 硬件我们需要掌控全局…用户/业务宏观追 踪日 志微服务/系统监 控应用程序实例微观基础设施/网络/硬件在tutorabc, 我们在实践自己的APM业务挑战遍及全球135个国家和地区的客户 群.遍布全球80多个国家, 100多座城 市的超过15,000名外籍顾问.每年提供超过1000万堂在线课程.为高质量客户群体提供高质量服务.技术挑战技术转型, 业务解耦.多语言开发, 多平台部署.遗留系统众多, 依赖关系复杂.目标: 全系统APM驱动APM系统构成反馈机制监控/日志/追踪监控墙streamingKafka业务系统Event Engine通知报警运维 人员ReactorReactor配置管理 & 自动化运维 & 虚拟化 & 资源池请求追踪数据整合展示与追踪 链关联的日志, 监 控和报警数据, 以 便于问题排查.系统全景实时展示各 个服务节点的状 态, 以及相互依赖 关系.动态采样根据宿主机(以及调用链上游 服务器)的负载调 整采样率.监控墙ChatOps一些建议监控, 日志和追踪数据要具备关联性, 便于后续分析.尽早建立CMDB, 方便对被监控的服务器和服务做分类, 打标签.重SDK, 去中心化.InfluxDB适合存储以数字为主的记录, 文本较多的记录存入ES.InfluxDB需要设置Series上限, 防止服务器内存耗尽.一些建议(续)Grafana报警功能使用单独的实例来运行.Grafana数据库Annotation表需要定期清理, 当数据量累积到30万以上时, 会严重影响页面性能.追踪系统无法跨越消息队列, 可以在发送消息前将TraceID/SpanID信息植入 消息内.追踪系统SDK一般支持跨线程追踪, 但是对Timer线程需要清除追踪上下文.追踪系统基于采样率模式, 所以无法指定追踪特定事件(比如登陆失败), 需 要调研基于事件的追踪模式.关于APM系统的一些数字服务实例1000+监控指标100+日志500+GB/天数据中心3每秒查询50+每秒写入(单节点)10,000+服务器600+iTutorGroup Open Platform开发框架VipCoder ServiceNodeSDK(Java, .NET)Portal平台入口平台运维平台管理资源管理租户管理路由管理服务治理核心系统中间件服务注册文件存储配置管理服务发现缓存系统消息服务健康检查消息队列发布系统状态同步任务调度其他APM追踪监控日志TGOP Portal展望改进追踪系统UI, 增强与日志和监控(报警)系统的集成体验.基于追踪系统, 实现分业务场景监控.基于大数据进行未来24小时流量预测, 做到主动预警而非被动告警.应用画像, 以利精准部署.资源池化, 提高利用率.总结未有监控, 不谈优化.合适即可, 演化迭代.工具重要, 人更重要. 少即是多, 见微知著.