《云原生可观测难点与最佳实践-徐彤.pdf》由会员分享,可在线阅读,更多相关《云原生可观测难点与最佳实践-徐彤.pdf(37页珍藏版)》请在三个皮匠报告上搜索。
1、可观测的难点和最佳实践 阿里云原生可观测持续发展之路徐彤(绍宽)徐彤(绍宽)阿里云原生可观测团队,高级技术专家,参与阿里云近5年来的可观测体系建设和演进业务实时监控(ARMS)混合云技术负责人,同时负责AIOps、Grafana等技术团队个人简介可观测技术成为战略趋势“可观测性以高度统筹与整合高度统筹与整合的方式将用户数字化操作所产生的可观测数据进行反馈并创造决策循环,提高组织决策有效性。如能在战略中予以规划并执行,可观测性将成为数据驱动型决策的最强支撑数据驱动型决策的最强支撑。”Frances Karamouzis第一阶段应用试点上云应用试点上云基础平台搭建基础平台搭建第三阶段全面上云全面上
2、云多云策略多云策略第二阶段云原生改造云原生改造重点系统上云重点系统上云 使用云上的使用云上的IAASIAAS服务,使服务,使用云主机替代部分本地机用云主机替代部分本地机器器 部分应用迁移到云上,或部分应用迁移到云上,或者在云上重新部署者在云上重新部署 部分数据库和存储使用云部分数据库和存储使用云上对应服务替换上对应服务替换使用云上的PaaS服务和企业SaaS服务、降低系统运维成本,提升系统稳定性按实际情况复用现有微服务框架和能力,引入PaaS组件(双模微服务、微服务管理框架、容器云平台和Devops平台企业现有运维能力技术栈平滑迁移基于第二阶段的适配经验,完成云原生适配,系统全面完成云化改造基
3、于性能、可用性、安全和成本考虑,通过多云实现更好的服务交付,去分散风险,降低成本,提升覆盖区域企业上云对可观测技术发展影响云的价值低高使用云的深度高调研论证Plan开发/测试Development预上线Pre Production生产运行Production对云原生可观测使用频率业务演进时间推移应用生命周期管理 无侵入、白屏化 所见所得运行环境日常监控辅助决策主动拨测A/B 流量比例测试金丝雀灰度发布压测调优部分应用/独立业务部署到云上,依赖的中间件等替换成云服务未立项(无预算)mvp 验证应用试点上云阶段对可观测平台的诉求 可观测无盲点 自动服务接入 自动应用拓扑 白屏下钻分析 灰度/压测场
4、景化视图 微服务埋点深度 代码粒度的profiling 主动拨测 智能巡检诊断 开箱即用云资源告警,智能阈值告警配置 Continue Profiling应用试点上云阶段客户特点应用量少,但是语言、框架丰富对于云上资源、SaaS服务稳定性缺乏信任对容器、云的理解尚浅,自运维难度高客户诉求不修改代码,对现有代码无侵入接入过程自动化,白屏化可观测覆盖无盲点,自身应用和云组件都能统一可观测有运维容器、微服务等最佳实践能降低上云门槛应用试点上云阶段对可观测平台的诉求可观测平台核心诉求点存储计算查询告警可视化智能化234567采集1多语言/框架支持,无盲点无盲点可观测,埋点深度覆盖微服务全过程无侵入,白
5、屏化,自动化接入能力动态、持续Profiling支持按需存储,自主可控提供多维度分析指标、链路数据能力提供白屏化查询、探索、下钻能力,方便观测应用、资源自身及上下游的状态对于云资源提供开箱即用的告警指导用户配置应用告警的最佳实践自动洞察调用拓扑,清晰看到应用调用关系、资源依赖关系云资源和已经接入的应用,提供统一视图场景化视图预置容器、云资源、微服务观测和诊断最佳实践无侵入自动化最佳实践运行在Linux内核中的虚拟机,可以加载到指定的HOOK点并获取运行时的上下文。无侵入无侵入:成本低,业务无需修改代码动态可编程动态可编程:无需重启应用,动态下发采集脚本高性能高性能:JIT编译成机器码执行高安全
6、性高安全性:内核级别的验证器关键点关键点1:基于基于ebpf完成自动采集能力完成自动采集能力架构感知架构感知,提供自动服务发现能力,网络拓扑能力进程指纹进程指纹,自动识别进程特征,推荐合适的增强探针协议识别协议识别,自适应应用层协议识别与解析链路跟踪链路跟踪,自动调用链路跟踪,支持异步场景流量染色流量染色,无侵入对数据包添加tag,可以实现灰度发布、业务场景的可观测 关键点关键点2:可观测的第四类数据收集可观测的第四类数据收集图片来源:https:/microsoft.github.io/code-with-engineering-playbook/observability/log-vs-m
7、etric-vs-trace/关键点关键点2:可观测的第四类数据收集可观测的第四类数据收集实现 profiling 的关键点:获取堆栈数据(爬栈):如何获取问题点(瓶颈)点的堆栈数据;生成火焰图;关键点关键点2:可观测的第四类数据收集可观测的第四类数据收集直接定位到方法,并且把每个方法的耗时统计出来,如上图右边所示的热点方法。过滤掉线程等相关条件关键点关键点3:智能告警提升告警配置效率智能告警提升告警配置效率 产生无效告警原因产生无效告警原因:不同应用、接口正常状态下的响应时间、调用量和错误率本身就不相同,成百上千的接口使用同一阈值天然会产生大量误告警 1.固定阈值遍历所有应用、接口 产生无效
8、告警原因产生无效告警原因:告警起初配置的时候没有问题,但是随着业务增长,rt、qps等业务指标或者是cpu使用率等机器指标平均水位线已经发生了变化,但没有更新阈值。2.敞口告警ARMS 团队对线上真实用户产生的6w+告警数据进行了实验,发现仅有1955次为真正有效告警,占比比例仅为3.05%关键点关键点3:智能告警提升告警配置效率智能告警提升告警配置效率原始时序数据数据分类算法时序预测算法上下边界用户自定义灵敏度、事件等智能告警多模型融合价值:算法有不同适用场景,为每种曲线寻找最合适的算法单一模型难以满足多种曲线类型 -自研数据分类算法+多模型融合 针对云上应用常见的微服务常见TOP20问题,
9、使用专家经验库+基线检测算法的方式自动定界故障,辅助用户决策 专家经验库通过不断收集内外用户反馈持续优化。(每周500+次反馈)平均客户满意度75%+并持续上升中。和提供云服务专业团队合作,提供的可观测经验输出。这包含超过 50 款阿里云主流云服务的运行指标、大盘和告警规则预置模板诊断场景应用运行态服务性能应用服务异常突增服务下游依赖问题服务中间件依赖问题单机fullgc问题单机磁盘使用率高问题单机网络重传率高问题中间件问题慢sql问题连接池满问题中间件服务端问题基础设施问题流量不均问题负载不均问题contanier短时间多次kill应用发布态应用发布异常发布后应用性能指标异常发布后应用系统指
10、标异常发布后应用异常指标异常应用发布失败应用启动失败异常分析应用资源不足失败分析关键点关键点3:智能化辅助决策,提供最佳实践:智能化辅助决策,提供最佳实践重点系统上云阶段客户特点应用量大,且包含核心应用,重视稳定性、性能等已经使用开源的可观测能力结合自身的运维体系完成云原生改造,使用大量云组件,paas平台等客户诉求开源技术栈兼容,不被单一云厂商锁定,自主可控确保数据完整性、准确性、系统高可用支持告警、查询、大盘等能力的统一可观测入口覆盖发布、压测、灰度等应用全生命周期场景下的可观测诉求重点系统上云阶段对可观测平台的诉求可观测平台核心技术点存储计算查询告警可视化智能化234567采集1支持开源
11、exporter兼容OpenTelemetry兼容Prometheus,保证高可用,高性能所有的数据计算利用开源能力,如promql、logql等进行数据获取兼容Grafana,支持企业所有数据源一键导入,通过Grafana完成所有可观测数据查询入口直接通过Grafana完成告警配置,要求兼容Alertmanger全部通过Grafana完成所有可视化,避免厂商锁定覆盖发布、压测、灰度等应用全生命周期场景下的可观测诉求基于事件的智能化运维能力开源影响出现性能和稳定性出现性能和稳定性问题问题,内存占用过内存占用过大大、重启极其缓重启极其缓慢慢、查询性能较差查询性能较差300150集群规模11000
12、开始使用开源分布开始使用开源分布式方案部署式方案部署,运维运维难度大增难度大增数据抓取热点问题数据抓取热点问题凸显凸显,数据容易数据容易倾斜倾斜3000采集端资源占用高采集端资源占用高、查询性能低查询性能低Prometheus开源的问题开源的问题:各个功能耦合,相互影响较大,出问题难排查 开源节点failover恢复较慢,甚至无法恢复;如果实现高可用的话,需要多副本共同采集,开销较大 在大数据量的情况下在大数据量的情况下,查询性能低查询性能低 查询与Compaction时资源波动较大,对此每个实例需要预留较多资源,每个用户独立租户的部署形态下,资源利用率低,成本较高 当用户到达数千至上万的规模
13、下,用户独享实例的运维工作量非常大关键点关键点3:查询性能优化查询性能优化 基础性能优化基础性能优化sum(rate(rpc_request_success)1m)/sum(rate(rpc_request_success)1m)+sum(rate(rpc_request_error)1m)典型计算成功率的promql,总数据量1亿数据点和200万时间线,10分片4步优化:算子下推协议优化DAG优化传输优化10个分片情况下,90%的场景下对于开源提升5倍;查询峰值内存占用降低90%;查询峰值CPU占用降低70%总结总结阿里云容器服务ACK集群阿里云ECS集群自建Kubernetes集群(ACK
14、注册集群)自建Prometheus阿里云云服务阿里云阿里云PrometheusPrometheus服务服务部署在ACK的开源组件指标ACK内的业务指标ACK基础组件指标部署在ECS上组件及业务指标自建K8S集群内的指标云服务指标将阿里云 Prometheus作为自建Prometheus存储源一键接入一键接入ARMS Prometheus AgentARMS Prometheus AgentRemote Write/Read EndpointRemote Write/Read Endpoint集成集成exporterexporter集成集成exporterexporter&服务发现服务发现for
15、 容器服务for VPCfor 云服务for Kubernetesfor 远程存储阿里云阿里云GrafanaGrafana服务服务采集能力提升采集能力提升通过采集存储分离架构,全面提升整体性能。采集组件优化,提升单副本采集能力,降低资源消耗。通过多副本横向扩展均衡分解采集任务,实现动态扩缩,解决开源水平扩展问题。存储能力提升存储能力提升支持数据自动重传,彻底解决丢弃逻辑弊病,确保数据完整性与准确性。凭借云存储能力实现数据存储量无上限,并确保系统高可用性。查询能力提升查询能力提升通过DAG执行优化、算子下推、缓存等手段,提升大规模数据下的查询性能。提供预聚合方式高效解决维度发散支持长时间区间数据
16、秒级查询。全面上云阶段客户特点可观测成本指数上升,且难以预估多region、多云的应用部署形态运维难度陡增,告警等配置繁琐易漏,MTTR居高不下,且难以度量客户诉求整体成本低于自建、且可预估跨region、跨云、多数据源统一可观测,统一入口一次配置,全球生效,高效协同,数字量化全面上云阶段对可观测平台的诉求可观测平台核心技术点存储计算查询告警可视化智能化234567采集1稳定性、低功耗、热升级、高性能、自监控海量运维数据存储成本优化,提升数据存储“ROI”稳定、低延时、齐全度支持跨region、跨云查询数据能力一次配置,全球生效智能阈值,降低噪声高效协同,数字量化跨region、跨云、多数据源
17、统一可观测,统一入口用云成本可视化三级辅助决策能力,降低MTTR成本统一智能关键点关键点1:存储成本控制:存储成本控制MetricMetric成本成本TraceTrace成本成本LogLog成本成本总成本成本分析成本分析成本分析高基数高搅动率长周期“大海捞针”全文索引Metric成本控制成本控制1.时间线(时间线(Time Series):一组不相同的label/value 的集合。temperaturecity=BJ,country=CNtemperaturecity=SH,country=CNhumiditycity=BJ,country=CN2.时间线高基数(时间线高基数(High Ca
18、rdinality)概念介绍3.高搅动率(高搅动率(High Churn Rate)。关键点关键点1:高基数、高搅动率场景下的优化:高基数、高搅动率场景下的优化高基数场景下的开源表现:默认使用 node exporter 作为指标数据源,单个 node exporter 实际产出的时间线数量控制在(6805)之间将采集周期定义为 10 秒钟,target 数量为 100,那么每秒钟产生的采样点数量,约为(680 x 100)/10=6800 个/秒;范围查询 默认每次发起 32 个 range 查询,时间跨度包括1小时、3小时、6小时、24小时。高搅动率场景下的开源表现:模拟100个node
19、exporter作为target,依然是一个小规模k8s集群的量级,每十秒钟抓取一次,即写入速率依然为6.8k/秒。原始时间线数量680 x100=680k,搅动率设置为十分钟汰换99%,即每十分钟会重新产生680 x100=68k时间线,每小时会新产生约41万时间线。每10秒钟发起一批范围查询,使用测试工具中默认的32条range query,查询时间范围从1h24h不等,查询超时时间为30秒关键点关键点1:高基数、高搅动率场景下的优化:高基数、高搅动率场景下的优化事件驱动的时间线智能收敛机制。1)高基数场景探测&事件生成:我们在时序数据库内部自动监测了时间线的变化趋势,发出高基数事件 2)
20、回调收敛服务,执行流式聚类:我们开发了负责收敛算法执行和收敛配置生成服务,该服务对外接收来自ARMS ITSM回调请求并开启流式聚类。3)聚类效果正反馈、算法迭代:在孙发服务执行聚类逻辑后,我们会自动检测聚类效果,过渡聚类的case会自动返回进行重新优化计算关键点关键点2:长周期场景下的优化:长周期场景下的优化长周期场景下的开源表现:使用ksm(kube state metrics)作为数据源,模拟了120个ksm,所以总时间线数量为 2500*120=30w。采集间隔为30s,每月产生的指标总量约为(30w/30)*60*60*24*30=260亿,每周产生的指标总量约为(30w/30)*6
21、0*60*24*7=60亿。查询语句:sum(kube_pod_container_resource_requests_memory_bytes)by(node,namespace)查询时间跨度:now-5d now查询step:10m(页面默认)五天数据查询耗时五天数据查询耗时16.3s七七天数据查询耗时天数据查询耗时53秒秒关键点关键点2:长周期场景下的优化:长周期场景下的优化使用Downsampling技术,对Sample点进行降采样,比如原来30秒间隔一个点,降采样为5分钟间隔一个点,减少Sample的个数,以应对大时间跨度查询场景,Downsampling之后的数据会有一些精度损耗,
22、但整体数据和趋势和原来保持一致计算前置、冷热分离计算前置、冷热分离 热数据实时分析:热数据实时分析:30分钟全量调用链实时查询&分析,满足在线诊断需求。冷数据精准采样:冷数据精准采样:根据链路特征自定义采样策略(Tail-based Sampling),只持久化存储需要的调用链(比如错慢调用),大幅降低存储成本。监控指标客户端预聚合:监控指标客户端预聚合:指标预聚合,监控告警的数据准确度不受调用链采样率影响,低成本实现精准统计。Trace成本控制成本控制关键点关键点3:FinOps成本洞察不同资源配型成本预估集群成本可观测成本控制成本预算制定成本控制与预警成本优化AHPA 基于AI的智能弹性伸
23、缩策略Koordinator 基于QoS的调度策略Public CloudIDC ACK 多维的集群成本洞察能力-公有云、多云、IDC混合云等多场景支持-支持集群、Namespace、节点池、应用等多维成本观测-资源维度分析,支持调度容量、资源使用率等相关性分析丰富的成本优化策略-适配不同场景的多种弹性策略:-HPA、节点自动扩缩、事件驱动的HPA、基于AI的弹性扩缩策略等-混部等场景提供基于QoS的调度策略-资源画像功能,智能资源浪费发现与应用规格自动适配智能成本控制-基于趋势判断的智能成本趋势预测-基于趋势的成本预算规划与预警关键点关键点4:GlobalView,全球全球Prometheu
24、s指标查询展示指标查询展示 在每个region中,每一个Storage Cluster为一个分布式部署的数据库集群,存储了用户在该地区中部署的对应的集群所上报的指标数据,同时Prometheus以分布式的方式部署了Prometheus Server用于查询对应地域中集群的数据。并对数据查询语句进行了优化,同时用户完全无需任何其他的组件部署。Global Prometheus Instance AGlobal Prometheus Instance Aregion1region2region3关键点关键点5:全球告警:全球告警1、引入告警规则模板概念与开源PrometheusRule CRD对标
25、,schema兼容开源。2、告警规则模板可以由开源PrometheusRule CRD导入。3、区域中心化+协作数据双源同步,联系人、告警规则、排班一次配置全球生效。4、告警规则模板支持根据标签自动应用到集群(标签控制器模式),新建集群自动应用告警规则模板关键点关键点7:高效协同:高效协同 告警展示信息单一,无法在告警上增加更丰富的信息,比如GC等级的客户?哪个集群等等信息 无法确定有没有人处理 无法一键屏蔽告警,处理问题的时候,还要处理告警风暴 修复后,没有沉淀,没有地方填写修复建议 缺乏有数字化复盘手段,对照文档感性复盘,对问题没有全局认知传统协作流程告警触发应急处理问题修复事后复盘传统协
26、作方式无法适应大规模集群的维护传统协作方式无法适应大规模集群的维护关键点关键点7:高效协同:高效协同自然的处理流程告警触发应急处理问题修复事后复盘关键点关键点8:辅助决策:辅助决策决策等级MetricLogTraceEventProfilling一级多维分析故障自动发现二级故障定界三级根因分析三级辅助决策机制,接入数据越多,智能化程度越高,辅助决策效果越明显关键点关键点7:辅助决策:辅助决策Grafana原生结合,用户直接在原生图表上加持辅助决策结论,自动分析TopN,占比,贡献度分析,自动下钻对应图表未来展望可观测左移可观测左移数字化运营数字化运营全栈可观测全栈可观测将可观测性融合至研发运维
27、环节中,使得问题获得更快反馈闭环;持续使用应用性能(APM)管理工具发现未知性能问题;使用用户体验管理工具模拟真实用户访问行为。通过可观测数据洞察IT成本,提升ROI;可观测技术和安全技术(如RASP和Cloud SIEM)的融合使用,降低IT风险;基于可观测数据协同各部门间合作,使用 ChatOps 方式与云交互。使用开源标准(如Prometheus Exporter/OpenTelemetry SDK)暴露服务运行指标;审计、事件信息汇总至云事件总线(EventBrdige)便于统一管理与分析;拥抱分布式云架构,提供云、边、端一体化的可观测视图。运维工程师/研发人员项目管理者/架构师/团队负责人基础云服务提供者