其他
从运维和SRE角度看监控分析平台建设
凌云时刻
编者按:运维和SRE团队,承载着重要的职责,其工作内容复杂而广泛,从应用部署、性能和可用性监控、告警、值班,到容量规划、业务支撑等都有涉及,随着云原生、容器化和微服务的快速发展,迭代节奏愈发加快,对于运维和SRE也提出了更多的挑战。
国内运维和SRE团队面临常见困境
业务线分布广泛,客户端、前端web、应用后端 同时支持几个甚至数十条业务线
相对开发人员,不少公司运维和SRE团队人员不到1%,甚至更低
经常扮演"救火队员"的角色 业务复杂,组件众多,快速排障和业务恢复的难度陡增
从不同的维度,对各类数据进行监控,脚本泛滥,工具纵多,烟囱林立 各类数据落在不同的系统中,关联分析欠缺,无法快速进行根因定位 阈值告警缺乏灵活性,一个系统可能出现数千告警规则,管理成本高昂,也容易造成告警泛滥,引起误判、漏判
监控分析平台需要解决的数据问题
各类系统数据 :cpu、mem、net、disk等通用硬件指标,系统syslog 业务黄金指标:延时、流量、错误、饱和度 业务访问日志 :Access Log 应用日志 : 如Java应用日志、错误日志 用户行为数据:web click App埋点数据:Android、IOS app中埋点统计 各类框架数据:如被广泛使用的k8s框架产生的数据 服务调用链 :各类Tracing数据
对于收集的各类数据,运维和SRE团队不光是为了保障业务稳定,还需要支持其他业务团队进行数据的使用,对于数据的使用也是多样的,常见需求如:
监控、报警 :实时处理(流式,小批量),秒级~分钟级延时 客服、问题排查:快速检索,如通过关键词过滤,秒级延时 风控:实时流量处理,亚秒延时 运营、分析:大规模数据分析,如OLAP场景,秒级到小时级延时
对于快速发展的业务,各类数据的规模在一开始是很难准确估算的,经常遇到:
新业务接入,数据量无准确估算参考 业务快速发展,数据暴增 数据使用需求变动,原有存储方式,保存时间不符合使用需求
构建监控分析平台方案选择
Telegraf是一个轻量级的采集框架,通过丰富插件对操作系统、数据库、中间件等各类指标进行采集,配合Influxdb对时序数据进行高效读写、存储、和query,最终可在grafana上进行可视化展示和交互式查询
在云原生k8s的生态中, Prometheus基本上作为时序数据的标配,配合灵活的exporter可以非常方便完成Metric采集,同时Promethues也可以和Grafana集成
在日志数据多维度查询和分析上,ELK套件是最常用的开源组件,提供快速、灵活、强大的查询能力,可满足研发、运维、客服的大部分查询需求
在微服务、分布式的系统中,请求调用链路复杂,没有一套合适的Tracing系统,很难进行高效的问题根因定位,从最开始的Zipkin、Jeager到逐渐形成行业标准的OpenTelemetry,国内的SkyWalking都是不错的Tracing 系统, 而这些Tracing并未提供数数据存储组件,需要配合ES或者Cassandra来存储Tracing数据
对于数据清洗,风控等常见需求,需要构建一套实时数据通道和流式系统,支撑数据的全量实时消费,如普遍使用的kafka和flink的组合
在运营分析,报表等场景,为了追求更高的实时响应性,通常还会将数据导入OLAP引擎,在秒级到分钟级内完成海量数据分析需求,以及各类Adhoc的查询
监控分析平台的挑战
依赖系统 : 数据在多套系统中流转,系统之间又存在依赖关系,单某系统出现问题时,对其他系统造成影响,如下游ES系统写入变慢后,用于缓存数据的Kafka集群存储水位变高,可能导致集群写满; Burst问题 :在互联网环境下,流量Burst是非常常见的情况,对于监控分析平台也一样,当大量数据需要写入系统的时候,如何保证系统不被压垮,同时保证读取功能正常运转,就非常有挑战 资源隔离:不同数据的优先级有高低,如果过分依赖资源物理隔离将导致集群资源严重浪费和运维成本极大提高,而当数据共享资源时,需要尽可能保证相互之间不受干扰,如某些系统中,一次超大规模的查询,可能拖垮整个集群,这对于系统整体而言是不可接受的 技术门槛:各类系统都有大量参数需要调优,面对不同的场景和需求,调优模式也不尽相同,需要投入大量的时间和精力,根据实际情况进行对比和优化
数据规模: 数据规模对于系统的性能有非常大的影响,如时序数据在千万~亿级时间线下读写, ES在10亿~100亿行数中的查询性能保证,都非常有挑战 Qos控制:任意一个系统,硬件资源都是有限的,需要对不同数据的qps、并发进行合理的分配和管理,必要时进行降级处理,否则某个业务的使用可能导致其他业务性能受损,而这在开源组件中,一般都很少考虑
资源成本:各类组件的部署都需要消耗硬件资源,特别是当数据同时存在多个系统中的时候,硬件的资源消耗将更加严重; 另外一个常见问题是,业务往往很难准确对数据量进行估算,很多时候,会采用相对保守手段,来降低系统水位,这又造成资源浪费 接入成本:支持各业务线数据接入也是一个繁重的工作,涉及到数据格式的适配、环境管理、配置设置和维护、资源的估算等一些列工作,需要有工具或平台帮助业务线自主完成,否则运维和SRE将陷入大量的琐事中 支持成本:对各系统的使用,难免会遇到各类问题,必要的技术支持必不可缺,但问题种类多样,如使用模式不合适、参数配置不合理等,也有遇到开源软件本身bug导致的问题,这对于维护这些系统的运维和SRE来说,又是一笔额外的代价 运维成本: 各系统的软硬件难免会出故障,硬件替换、缩扩容、软件版本升级,也需要投入不小的人力和精力 费用分摊:只有地将资源消耗清晰准确分摊到实际业务线,运维和SRE,才能更有效利用资源,制定合理的预算和规划。这也就需要能提供有效计量数据进行费用分摊。
实际场景模拟
公司有100多应用,每个应用有Nginx访问日志,以及Java应用服务日志 各应用日志规模变化巨大,从单日1GB到1TB不等,每天新增10TB数据,需保存7天至90天, 平均15天 日志数据主要用于业务监控和报警、线上问题排查,以及实时风控使用
Filebeats :实时采集数据,发送至kafka Kafka : 数据临时存储,供实时Flink实时消费,和导入ES Flink : 对业务数据实时分析,进行实时监控、风控 ES : 日志查询分析,问题排查
容量规划:原始数据 * 膨胀系数 *(1 + 副本数) * (1 + 预留空间) , 一般膨胀系数取1.1 ~ 1.3, 1个副本,25%的预留(剩余空间,临时文件等), 实际磁盘空间最终是原始空间的 2.75~3.5倍。如果需要开启_all 参数设置的话,数据膨胀会更严重,也需要预留更多空间 冷热分离:所有数据全部保留到SSD上成本会过高,需要根据数据的重要程度和时间因素,可以将部分Index直接保存至HDD磁盘,或使用Rollover功能将Index迁移 Index设置 : 每个应用的2类日志,分别按照时间周期性创建Index,根据数据大小合理设置shard数, 单shard以30~50GB为宜,但是各应用的日志量很难准确估计,常在遇到写入或查询问题后再调整, 然而reindex的消耗又非常大 Kafka消费设置:通常使用logstash消费kafka再写入ES,需要kafka topic的patition数和logconsumer_threads相匹配,否则容易导致各partition消费不均 ES参数调优:对写入吞吐,可见性延时,数据安全性,以及查询性能等多方面因素进行综合评估和权衡后,结合集群CPU、内存,对ES一些列参数进行调优,才能更好发挥ES的特性,常见的参数包括线程数、内存控制、translog设置、队列长度、各类操作间隔interval、merge参数等 内存问题:通常JVM 堆内存大小在32GB以内,剩余的留个OS缓存使用,如果频繁gc 会严重影响性能,甚至直接导致服务不可用。
master节点内存占用和集群中shard数直接相关,一般集群shard需要控制在10W以内,ES默认配置中,单节点shard数上限为1000,需要合理控制index和shard数量 data节点的内存由索引数据规模决定,如ES的FST会长期驻留在内存,虽然在7.3及之后版本中,提供了堆外内存方式(mmap),但缓存被系统回收又会导致查询性能下降,如果使用的是更低版本,则只能控制单节点数据大小;
查询问题:影响查询性能的因素非常多,需要花费大量时间不断试错和积累,常见的如:
合理设置mapping,如text和keyword的选择,尽量避免无必要的nested mapping 避免过大的查询范围和复杂度(过深的group by等),以免急剧消耗系统资源;对结果集大小进行限制,否则复杂的聚合查询或模糊查询等,在过大数据集上甚至直接导致oom 控制segment数量,必要时进行force merge,也需要评估好force merge带来的大量IO和资源消耗 filter和query的合理选择,在无需计算得分场景下,filter可以更好使用query cache,速度要明显快于query script 脚本带来的性能和稳定性问题 合理使用好routing可以使得单次查询只扫描某个shard数据,提升性能
数据损坏:如果遇到异常的crash,可能导致文件损坏,在segment或translog文件受损时,shard可能无法加载,需要使用工具或手动将有问题的数据清理掉,但这也会导致部分数据丢失
云上一体化服务选择
Logtail : 多年百万级服务器锤炼,简便、可靠、高性能,web端可视化管理 SDK/Producer : 各类移动端 java/c/go/ios/android/web tracking接入 云原生 :云上ACS原生支持,自建CRD一键接入
秒级扩容能力,支持PB级数据实时写入和消费 原生支持flink/storm/spark streaming等主流系统
百亿规模秒级查询 支持SQL92、交互式查询、机器学习、安全特色函数
先比传统ETL,可节省90%的开发代价 纯托管、高可用、高弹性扩展
云原生Metric接入,支持亿级时间线的Prometheus存储
完美支持OpenTelemetry协议,兼容Jaeger、Zipkin等OpenTracing协议、OpenCensus、SkyWalking等方案
站式完成告警监控、降噪、事务管理、通知分派
高效的无监督流式诊断和人工打标反馈机制,大大提高了监控效率很准确率
云上服务,开箱即用,0运维成本,无需再维护和调优多套系统 可视化管理,5分钟完成接入,业务支持代价大大降低
数据只保留一份,无需将数据在多套系统中流转 按量使用,无预留资源的浪费 提供完善的技术支持,人力成本大大降低
提供完整的消费数据,助力完成内部分账和成本优化 完整的权限控制和资源隔离,避免重要信息泄露
你可能还想看
1. 如何做好一场技术演讲?
2. 空间数据模型之从CAD到BIM
3. 阿里云技术专家:大型团队如何从0到1自建SRE体系
4. 阿里云李飞飞:什么是云原生数据库
5. 阿里云祝顺民:因云而生的云原生网络
END