从运维和SRE角度看监控分析平台建设

本文涉及的产品
对象存储 OSS,20GB 3个月
阿里云盘企业版 CDE,企业版用户数5人 500GB空间
文件存储 NAS,50GB 3个月
简介: 运维和SRE团队,承载着重要的职责,其工作内容复杂而广泛,从应用部署、性能和可用性监控、告警、值班,到容量规划、业务支撑等都有涉及,随着云原生、容器化和微服务的快速发展,迭代节奏愈发加快,对于运维和SRE也提出了更多的挑战。

运维和SRE团队,承载着重要的职责,其工作内容复杂而广泛,从应用部署、性能和可用性监控、告警、值班,到容量规划、业务支撑等都有涉及。随着云原生、容器化和微服务的快速发展,迭代节奏愈发加快,对于运维和SRE也提出了更多的挑战,以下几个也是国内运维和SRE团队面临常见困境:



  • 支持业务线广
  • 业务线分布广泛,客户端、前端web、应用后端
  • 同时支持几个甚至数十条业务线


  • 人力严重短缺
  • 相对开发人员,不少公司运维和SRE团队人员不到1%,甚至更低


  • 线上稳定性压力大
  • 经常扮演"救火队员"的角色
  • 业务复杂,组件众多,快速排障和业务恢复的难度陡增


  • 缺乏统一而有效监控分析平台
  • 从不同的维度,对各类数据进行监控,脚本泛滥,工具纵多,烟囱林立
  • 各类数据落在不同的系统中,关联分析欠缺,无法快速进行根因定位
  • 阈值告警缺乏灵活性,一个系统可能出现数千告警规则,管理成本高昂,也容易造成告警泛滥,引起误判、漏判


因此,一套简单易用、高效、分析能力强的监控分析平台,对于提高运维和SRE工作效率,快速而准确进行根因定位,保证业务连续性至关重要。


监控分析平台需要解决的数据问题


运维和SRE为了保证业务稳定和支持业务发展,需要对大量的数据进行收集和分析,从机器硬件、网络指标到业务、用户行为等多方面数据,在完成数据采集后,还需要有一套合适的系统进行转换、存储、处理、分析,满足多样的需求。数据问题主要包括:


  • 数据多样
  • 各类系统数据 :cpu、mem、net、disk等通用硬件指标,系统syslog
  • 业务黄金指标:延时、流量、错误、饱和度
  • 业务访问日志 :Access Log
  • 应用日志 :  如Java应用日志、错误日志
  • 用户行为数据:web click
  • App埋点数据:Android、IOS app中埋点统计
  • 各类框架数据:如被广泛使用的k8s框架产生的数据
  • 服务调用链 :各类Tracing数据


  • 需求多样
    对于收集的各类数据,运维和SRE团队不光是为了保障业务稳定,还需要支持其他业务团队进行数据的使用,对于数据的使用也是多样的,常见需求如:
  • 监控、报警 :实时处理(流式,小批量),秒级~分钟级延时
  • 客服、问题排查:快速检索,如通过关键词过滤,秒级延时
  • 风控:实时流量处理,亚秒延时
  • 运营、分析:大规模数据分析,如OLAP场景,秒级到小时级延时


  • 资源需求估算难
    对于快速发展的业务,各类数据的规模在一开始是很难准确估算的,经常遇到:
  • 新业务接入,数据量无准确估算参考
  • 业务快速发展,数据暴增
  • 数据使用需求变动,原有存储方式,保存时间不符合使用需求


构建监控分析平台方案选择


由于数据来源广、样式杂,需求多,运维和SRE团队往往需要使用和维护多套系统,组合使用,才能满足多样的监控和业务需求,常见的开源组合如:


  • Telegraf+Influxdb+Grafana
    Telegraf是一个轻量级的采集框架,通过丰富插件对操作系统、数据库、中间件等各类指标进行采集,配合Influxdb对时序数据进行高效读写、存储、和query,最终可在grafana上进行可视化展示和交互式查询
  • Promethues
    在云原生k8s的生态中, Prometheus基本上作为时序数据的标配,配合灵活的exporter可以非常方便完成Metric采集,同时Promethues也可以和Grafana集成
  • ELK
    在日志数据多维度查询和分析上,ELK套件是最常用的开源组件,提供快速、灵活、强大的查询能力,可满足研发、运维、客服的大部分查询需求
  • Tracing  类
    在微服务、分布式的系统中,请求调用链路复杂,没有一套合适的Tracing系统,很难进行高效的问题根因定位,从最开始的Zipkin、Jeager到逐渐形成行业标准的OpenTelemetry,国内的SkyWalking都是不错的Tracing 系统, 而这些Tracing并未提供数数据存储组件,需要配合ES或者Cassandra来存储Tracing数据
  • Kafka + Flink
    对于数据清洗,风控等常见需求,需要构建一套实时数据通道和流式系统,支撑数据的全量实时消费,如普遍使用的kafka和flink的组合
  • ClickHouse/Presto/Druid
    在运营分析,报表等场景,为了追求更高的实时响应性,通常还会将数据导入OLAP引擎,在秒级到分钟级内完成海量数据分析需求,以及各类Adhoc的查询


不同的组件面向不同的数据类型和处理需求,数据需要在其中进行流转,有时候同一份数据需要同时保存在多个系统中,增加系统复杂度的同时,也增加了成本。


当数据越来越多,使用需求越来越广的时候,保障这些组件的稳定性、满足多种业务性能需求、进行有效的成本控制,又要对大量业务线进行高效支撑,都是非常繁重而又有挑战的工作。


监控分析平台的挑战


能够维护好多套系统,并有效支持众多业务线,面临的挑战可不小,如:


  • 稳定性保障
  • 依赖系统 : 数据在多套系统中流转,系统之间又存在依赖关系,单某系统出现问题时,对其他系统造成影响,如下游ES系统写入变慢后,用于缓存数据的Kafka集群存储水位变高,可能导致集群写满;
  • Burst问题 :在互联网环境下,流量Burst是非常常见的情况,对于监控分析平台也一样,当大量数据需要写入系统的时候,如何保证系统不被压垮,同时保证读取功能正常运转,就非常有挑战
  • 资源隔离:不同数据的优先级有高低,如果过分依赖资源物理隔离将导致集群资源严重浪费和运维成本极大提高,而当数据共享资源时,需要尽可能保证相互之间不受干扰,如某些系统中,一次超大规模的查询,可能拖垮整个集群,这对于系统整体而言是不可接受的
  • 技术门槛:各类系统都有大量参数需要调优,面对不同的场景和需求,调优模式也不尽相同,需要投入大量的时间和精力,根据实际情况进行对比和优化


  • 性能可预期
  • 数据规模:  数据规模对于系统的性能有非常大的影响,如时序数据在千万~亿级时间线下读写, ES在10亿~100亿行数中的查询性能保证,都非常有挑战
  • Qos控制:任意一个系统,硬件资源都是有限的,需要对不同数据的qps、并发进行合理的分配和管理,必要时进行降级处理,否则某个业务的使用可能导致其他业务性能受损,而这在开源组件中,一般都很少考虑


  • 成本控制
  • 资源成本:各类组件的部署都需要消耗硬件资源,特别是当数据同时存在多个系统中的时候,硬件的资源消耗将更加严重;  另外一个常见问题是,业务往往很难准确对数据量进行估算,很多时候,会采用相对保守手段,来降低系统水位,这又造成资源浪费
  • 接入成本:支持各业务线数据接入也是一个繁重的工作,涉及到数据格式的适配、环境管理、配置设置和维护、资源的估算等一些列工作,需要有工具或平台帮助业务线自主完成,否则运维和SRE将陷入大量的琐事中
  • 支持成本:对各系统的使用,难免会遇到各类问题,必要的技术支持必不可缺,但问题种类多样,如使用模式不合适、参数配置不合理等,也有遇到开源软件本身bug导致的问题,这对于维护这些系统的运维和SRE来说,又是一笔额外的代价
  • 运维成本:  各系统的软硬件难免会出故障,硬件替换、缩扩容、软件版本升级,也需要投入不小的人力和精力
  • 费用分摊:只有地将资源消耗清晰准确分摊到实际业务线,运维和SRE,才能更有效利用资源,制定合理的预算和规划。这也就需要能提供有效计量数据进行费用分摊。


从上面的挑战来看,为了保证系统连续性和支撑好业务,运维和SRE团队维护好多套系统,可并不是一个轻松的事。下面以某公司实际场景为例,看看实践中可能遇到的问题和需要注意的内容。


实际场景模拟


业务背景 :


  • 公司有100多应用,每个应用有Nginx访问日志,以及Java应用服务日志
  • 各应用日志规模变化巨大,从单日1GB到1TB不等,每天新增10TB数据,需保存7天至90天, 平均15天
  • 日志数据主要用于业务监控和报警、线上问题排查,以及实时风控使用


业务架构选型:


  • Filebeats :实时采集数据,发送至kafka
  • Kafka : 数据临时存储,供实时Flink实时消费,和导入ES
  • Flink : 对业务数据实时分析,进行实时监控、风控
  • ES :  日志查询分析,问题排查


在以上看似最简单和直白的架构中,也隐藏了大量细节需要关注,以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可能无法加载,需要使用工具或手动将有问题的数据清理掉,但这也会导致部分数据丢失


以上是在使用和运维ES集群中,经常会遇到和需要注意的问题,稳定维护好ES集群可真不是一件容易的事情,特别是当数据逐步扩大到数百TB,又有大量使用需求的情况下。同样的问题也存在其他系统中,这对于平时工作极其繁忙的运维和SRE同学是不小的负担。


云上一体化服务选择


针对运维和SRE工作中对于监控分析平台的需求,以及平台搭建过程中遇到的种种问题, 阿里云SLS团队希望在云上提供一套简单易用、稳定可靠、高性能而又具有良好性价比的解决方案,以支持运维和SRE更高效地工作。SLS从原本只支持阿里+蚂蚁的内部日志系统开始,逐步完善,演进成为同时支持Log、Metric、Tracing的PB级云原生观测分析平台:


  • 极其简便接入
  • Logtail : 多年百万级服务器锤炼,简便、可靠、高性能,web端可视化管理
  • SDK/Producer : 各类移动端 java/c/go/ios/android/web tracking接入
  • 云原生 :云上ACS原生支持,自建CRD一键接入


  • 实时消费和生态对接
  • 秒级扩容能力,支持PB级数据实时写入和消费
  • 原生支持flink/storm/spark streaming等主流系统


  • 海量数据查询分析力
  • 百亿规模秒级查询
  • 支持SQL92、交互式查询、机器学习、安全特色函数


  • 数据加工
  • 先比传统ETL,可节省90%的开发代价
  • 纯托管、高可用、高弹性扩展


  • Metric 时序数据
  • 云原生Metric接入,支持亿级时间线的Prometheus存储


  • 统一的Tracing方案
  • 完美支持OpenTelemetry协议,兼容Jaeger、Zipkin等OpenTracing协议、OpenCensus、SkyWalking等方案


  • 完善的监控和报警
  • 站式完成告警监控、降噪、事务管理、通知分派


  • 异常智能诊断
  • 高效的无监督流式诊断和人工打标反馈机制,大大提高了监控效率很准确率

相比开源多套系统的方案, SLS采用了All in one的模式,在一个系统中,完整支持了运维和SRE工作中对于监控分析平台的需求,可以直接替代搭建kafka、ES、Prometheus、OLAP等多套系统的组合,这样带来了明显的好处:


  • 运维复杂度
  • 云上服务,开箱即用,0运维成本,无需再维护和调优多套系统
  • 可视化管理,5分钟完成接入,业务支持代价大大降低


  • 成本优化
  • 数据只保留一份,无需将数据在多套系统中流转
  • 按量使用,无预留资源的浪费
  • 提供完善的技术支持,人力成本大大降低


  • 资源权限管理
  • 提供完整的消费数据,助力完成内部分账和成本优化
  1. 完整的权限控制和资源隔离,避免重要信息泄露


SLS 希望通过自身的不断进步,为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务,助力运维和SRE更高效工作,更有效支持业务快速发展。

目录
相关文章
|
27天前
|
运维 监控 安全
构建高效运维体系:从监控到自动化的全方位实践
本文深入探讨了构建高效运维体系的关键要素,从监控、日志管理、自动化工具、容器化与微服务架构、持续集成与持续部署(CI/CD)、虚拟化与云计算以及安全与合规等方面进行了全面阐述。通过引入先进的技术和方法,结合实际案例和项目经验,为读者提供了一套完整的运维解决方案,旨在帮助企业提升运维效率,降低运营成本,确保业务稳定运行。
|
2月前
|
运维 Prometheus 监控
OceanBase 的运维与监控最佳实践
【8月更文第31天】随着分布式数据库解决方案的需求日益增长,OceanBase 作为一种高性能的分布式数据库系统,在众多场景下得到了广泛应用。为了确保 OceanBase 集群的稳定运行,合理的运维与监控是必不可少的。本文将探讨 OceanBase 的日常运维管理与监控策略,并提供相应的代码示例。
82 2
|
4月前
|
运维 Prometheus 监控
监控与日志分析:运维的双剑合璧
【6月更文挑战第21天】监控与日志分析在IT运维中至关重要。监控守护系统健康,通过性能指标、服务状态和安全事件预警确保稳定性;日志分析则用于问题追踪,通过错误、访问和安全日志定位故障。监控工具如Prometheus与日志分析工具如ELK堆栈协同工作,统一平台、合理告警、定期分析和团队协作是高效运维的关键。这两者的结合助力运维人员迅速响应和解决问题,维护系统稳定。
|
1天前
|
运维 监控 安全
构建高效运维体系:从监控到自动化的全面指南在当今数字化时代,运维作为保障系统稳定性和效率的重要环节,其重要性不言而喻。本文将深入探讨如何构建一个高效的运维体系,从监控系统的搭建到自动化运维的实施,旨在为读者提供一套完整的解决方案。
本文详细介绍了高效运维体系的构建过程,包括监控系统的选择与部署、日志分析的方法、性能优化的策略以及自动化运维工具的应用。通过对这些关键环节的深入剖析,帮助运维人员提升系统的可靠性和响应速度,降低人工干预成本,实现业务的快速发展和稳定运行。
|
1月前
|
存储 弹性计算 运维
自动化监控和响应ECS系统事件
阿里云提供的ECS系统事件用于记录云资源信息,如实例启停、到期通知等。为实现自动化运维,如故障处理与动态调度,可使用云助手插件`ecs-tool-event`。该插件定时获取并转化ECS事件为日志存储,便于监控与响应,无需额外开发,适用于大规模集群管理。详情及示例可见链接文档。
|
29天前
|
存储 运维 监控
构建高效运维体系:从监控到自动化的全方位实践指南
在当今数字化时代,企业对运维(Operations)的需求日益增长。运维不仅仅是保持系统运行那么简单,它涉及到监控、日志管理、故障排除、性能优化和自动化等多个层面。本文将从实际操作的角度出发,详细探讨如何构建一个高效的运维体系。通过具体案例,我们将了解不同运维工具和方法的应用,以及它们是如何帮助企业提高生产效率和降低运营风险的。无论你是刚接触运维的新手,还是经验丰富的专家,这篇文章都将为你提供宝贵的参考和启示。
|
11天前
|
运维 监控 安全
构建高效运维体系:从监控到自动化的实践之路
在当今信息技术飞速发展的时代,运维作为保障企业信息系统稳定运行的关键环节,其重要性日益凸显。本文将探讨如何通过构建高效的运维体系,实现从被动响应到主动预防的转变,以及如何利用自动化工具提升运维效率和质量。我们将从运维的基本概念出发,逐步深入到监控、自动化和安全管理等方面,为企业提供一套实用的运维优化方案。
34 0
|
1月前
|
存储 运维 监控
构建高效运维体系:从监控到自动化的全方位实践
在当今信息技术飞速发展的时代,运维作为保障信息系统稳定运行的关键环节,其重要性不言而喻。本文将围绕如何构建一个高效的运维体系进行深入探讨,内容涵盖从监控、日志分析到自动化运维工具的选择与应用,以及在实际工作中的经验和案例分享。通过本文的介绍,读者将能够了解到如何在复杂多变的技术环境中,确保系统的高可用性、高性能和安全性,为业务连续性提供坚实保障。
|
2月前
|
存储 运维 监控
监控与日志管理:保障系统稳定运行与高效运维的基石
【8月更文挑战第16天】监控与日志管理是保障系统稳定运行和高效运维的基石。它们不仅能够帮助企业及时发现并解决问题,还能够为性能调优、资源优化和业务决策提供有力支持。因此,在构建系统架构时,企业应高度重视监控与日志管理的规划和实施,确保它们能够充分发挥作用,为企业的发展保驾护航。同时,随着技术的不断进步和应用场景的不断拓展,监控与日志管理也将持续演进和创新,为企业带来更多的价值和便利。
|
2月前
|
运维 Kubernetes 监控