运维监控大数据的提取与分析

本文内容整理来自【敏捷运维大讲堂】蒋君伟老师的线上直播分享。分别从以下3个维度来分享:1、云时代监控分析的窘境;2、使用标签标记监控数据的维度;3、监控数据应用场景。

云时代监控分析的窘境

在虚拟化与容器技术广泛应用的情况下,运维对象大规模地增长,监控平台每天存储的指标都以亿计,所以监控数据如今已经成了大数据。传统的监控工具在这种场景下,对于数据的提取分析,已经力不从心,反而成为了运维的负担。

我们用一个典型的互联网档案分析应用举例说明:

这个应用支持容灾与负载均衡,它部署在三个数据中心,并同时提供服务;

应用按微服务思想设计,内部划分为多个技术组件,包括APIGateway、档案、登记、通知、支付及一些数据库服务

技术组件可弹性扩缩容

这样的应用目前很常见,它有这样一些特征:

变:架构变、实例变

由于研发每周都在迭代,可能随时都加增加新的技术组件种类,如增加一个MongoDB作为文档类数据存储;同时由于弹性扩缩容,每个技术组件的实例时刻也在变,比如下图,就减少了一个档案服务,增加了一个支付服务:

这给监控带来了难题:如何监控经常变化的目标? 答案是:监控配置自动化,随基础架构扩展,并标记监控目标。

在Zabbix与UYUN Monitor产品中,都可以使用自动部署与发现来实现自动扩展监控。Zabbix主要使用标记与自动分组的方式,而Monitor则使用标签的方式:

多:种类多、实例多

一个公司可能存在30多个这样的集群应用,它使用上百种技术组件,数千个虚拟机或容器实例。如此大的规模,带来了巨大的监控复杂度,新的难题是:我们变得更难预测的故障诊断场景!

我们举几个具体的场景来说明这点:

场景1:我想要知道所有的档案查询次数

档案查询次数是衡量整个应用业务量的一个重要指标,这个场景的难点是档案服务是多实例的,并且分布在多个数据中心。针对这个场景,我们的解题思路是:合计所有数据中心的所有档案服务的查询API调用次数,即下图中所有红色部份:

使用Zabbix时,可以按如下步骤:

创建一个档案服务group,包含所有数据中心的所有档案服务

创建一个item,使用汇聚 groupfunc 合计 group 内的所有查询API调用次数

使用UYUM Monitor时,则配置如下字符串即可:

m=sum:查询API调用次数{技术组件=档案服务}

实现效果:

场景2:我想知道APIGateway TCP连接数三个中心的各自占比

通过连接数占比,我们可以分析出各个数据中心的负载是否均衡。其解题思路是:独立合计每个数据中心的APIGateway TCP连接数,即如下红色部份:

使用Zabbix时,可以按如下步骤配置:

创建三个数据中心APIGateway group g1. 杭州东 APIGateway group g2. 杭州西 APIGateway group g3. 宁波 APIGateway group

创建对应item 分别统计其TCP连接数合计

使用UYUM Monitor时,还是配置如下字符串即可:

m=sum:TCP连接数{数据中心=*,技术组件=APIGateway}

实现效果:

场景3:我想知道各种服务的主机CPU平均利用率趋势

通过将一些技术组件的CPU利用率在一个趋势图中显示,我们可以利用指标间的正相关性,来分析组件间的影响,比如档案服务的CPU利用率升高时,提供其数据的Redis服务CPU使用率也在升高。其解题思路为:分别为每种服务求得其主机CPU平均利用率,并在一个趋势图中展示。

使用Zabbix时,可以按如下步骤配置:

创建各个技术组件对应的group,包含:是APIGateway、档案、登记、通知、支付、MySQL等等

创建对应item 分别统计其主机CPU利用率平均值

而使用UYUM Monitor时,依然是配置如下字符串:

起始时间=30分钟前&m=avg:主机CPU利用率{技术组件=*}

实现效果:

使用标签标记监控数据的维度

我们可以看出,Zabbix与Monitor针对一些数据的提取方式是不一样的。Zabbix更多的是使用Group分组的方式,来梳理某些维度同类型的信息,这种方式是我们过去惯用的,组织一棵树来抽象世界。

但是,世界其实是平的,各种事物实际上是平等存在的,只是它们有着各自的特性而已。所以,我们所需要的只是按需用这些特性标签来提取它们。举例来说,下图就可以看到两个主机的各种标签:

使用UYUN Monitor时,可以按很多种不同的方式来建立标签,包括:

1、安装代理时指定

2、查看主机信息时指定

3、以及通过自定义脚本推送指标时指定 推送到本机代理:

在为监控对象建立好这些标签后,我们就可以充分使用标签带来的便利,随需查询,不预设场景。

监控数据应用场景

新一代的监控系统,其本质实际上是一个监控大数据收集与分析平台,它不限定监控底层的数据来源以便全面覆盖运维对象,通过海量存储与灵活的数据提取能力,为上层的各种运维场景,提供如大屏可视化、报警、分析报表等功能。

UYUN Monitor 也提供了多种上层的运维分析功能,包括:

1、个性丰富的仪表盘,能灵活提取各类监控数据按多种方式展现

2、指标的阈值检查策略,能对集群指标进行综合汇聚与告警

3、第三方数据查询OpenAPI,提供数据的二次消费入口

可以看出,面对云时代,我们对监控系统的要求已经产生了变化,监控系统实际上已经转变 为一个监控大数据收集与分析平台,它不限定监控底层的数据来源以便全面覆盖运维对象, 通过海量存储与灵活的数据提取能力,为上层的各种运维场景,提供如大屏可视化、报警、 分析报表等功能。

本次主题《监控大数据的提取与分析》的分享希望对大家有所帮助,优云敏捷运维大讲堂面向运维领域的技术分享、最佳实践将不定期与大家见面,敬请期待。

讲师介绍

蒋君伟

IT运维领域资深专家,产品总监,拥有10年运维实战经验

时间: 2024-10-07 05:31:07

运维监控大数据的提取与分析的相关文章

徒手教你制作运维监控大屏

公司业务的不断发展,紧接而来的是业务种类的增加.服务器数量的增长.网络环境的越发复杂以及发布更加频繁,从而不可避免地带来了线上事故的增多,因此需要对服务器到应用的全方位监控,提前预警. 建立在Zabbix上的服务器监控.基础应用监控(mysql.redis.ES等).预警功能 基本满足底层的监控预警要求,超过设定的阀值就会提前通知相关人员去解决. 有了Zabbix为什么还需要Grafana? Zabbix图表聚合功能非常薄弱,这不是它的强项,而且数据源只限定自己的收集器,图表展示类就是Grafa

运维工具大宝典之商用软件篇

在前一篇<运维工具大宝典之开源工具篇>中,云智慧对比分析了国内流行开源运维监控软件的优劣.在文末我们提到了开源产品在服务和安全等方面的短板,而正因为有这些问题,所以国内企业,特别是中大型行业企业往往因此而拒绝开源产品,选择服务更有保障,产品安全性.稳定性更高的商用运维平台.本文就将为您对比评测国内主流的商用运维监控软件.监控宝推荐星级:★★★★★监控宝是云智慧为用户提供IT性能监控(IT Performance Monitoring)的SaaS产品,包含网站监控.服务器监控.中间件监控.数据库

[转载]系统运维秘诀大分享专题

系统运维秘诀大分享专题 本专题整合收录了有关系统运维/系统管理员工作和个人成长方面的各种心得分享.经验总结.以及必须牢记的一些准则,适合所有在运维领域有追求的技术人阅读.有些分享的层次比较深,有些则是运维的基础课,但通过翻看他人的心得,相信你总能有所收获. 1 Dormando的系统运维秘诀三部曲... 4 1.1 技术篇... 4 1.1.1 为变化而设计.... 4 1.1.2 使用自动的,可重复的构建过程.... 4 1.1.3 使用冗余.... 4 1.1.4 使用备份.... 5 1.

江西畅行高速IT运维监控平台--PIGOSS BSM

案例所属行业:高速公路行业 项目实施时间:2014年 1.1    项目背景     江西畅行高速工程(以下简称"畅行高速")与高速公路周边系统的建设基于用户的消费账户支付系统和结算系统.既包括高速公路的收费,也包括高速公路周边的连锁超市的消费,互联网业务为江西畅行高速周边服务. 目前,江西畅行高速进行网络建设和核心生产平台应用系统的建设.随着江西畅行高速信息化应用的不断推广,核心生产平台的稳定运行对项目的影响越来越大.随 着更多江西畅行高速业务系统上线运行和日常办公对业务系统的日益依

【解决方案】IDC、MA服务商IT运维监控解决方案

       文章摘自 pigoss 官网 http://www.netistate.com  如需转载,请标明出处! IDC与MA服务商现状 目前,大部分传统IDC服务商仍然处于卖场地.卖资源的阶段,通过租赁有限的场地和资源,同质化竞争和低价竞争愈演愈烈严重.如何为用户提供差异化增值IT运维服务成为新一代IDC的竞争目标. 同 样,大部分传统MA服务商的经营模式为提供维保服务,成熟.有经验的工程师便成为了众多MA服务商的重点争夺人才,人力成本不断攀升.技术人员巨大的人才 缺口,注定了专家级工程

【IT运维监控】讨论哪种运维监控工具才是IT运维人员的最爱?

选择运维工具的几大要素:一是看我哪些指标需要监控,二是看我监控到什么 三是看这种运维监控工具能监控到什么程度 有可能,这几个问题IT运维人员自己都没有弄的很明白,那么我们先看一下整个运维行业目前的现状: 目前来说,传统企业的IT运维大部分还是用户在使用过程中发现故障,然后通知运维人员,再邮运维人员确定是什么问题,采用哪种方式可以解决.大部分的运维人员目前还是充当的只是一个救火员的身份,没有起到真正的IT运维监控的作用.运维人员的大部分时间和经历都花在了处理简单而重复的问题上,导致同事及领导的不满

最简单也最难:运维监控的最后1公里

谈运维我们不得不提监控,监控是运维的起点,也是难点.随着IT架构逐渐复杂化,从前端到IT底层,中间涉及浏览器.网络.服务器.操作系统.中间件.应用.数据库等,每个环节厂商不尽相同.当出现异常需要定位哪个环节出了问题的时候,排查就耗时耗力,若使用优云监控产品,以上难题不再是问题.优云全栈运维监控覆盖了所有环节的监控,真正做到监控无盲区,运维无隐患. 运维最后一公里是指高度可视化.优云除了提升监控能力还注重可视化,深知可视化是运维的亮点更是本质,为了让每个环节监控的数据更好的展现出来,优云拥有一批在

Storm流计算从入门到精通之技术篇(高并发策略、批处理事务、Trident精解、运维监控、企业场景)

对这个课程有兴趣的可以加我qq2059055336和我联系 Storm是什么? 为什么学习Storm? Storm是Twitter开源的分布式实时大数据处理框架,被业界称为实时版Hadoop. 随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍,比如网站统计.推荐系统.预警系统.金融系统(高频交易.股票)等等, 大数据实时处理解决方案(流计算)的应用日趋广泛,目前已是分布式技术领域最新爆发点,而Storm更是流计算技术中的佼佼者和主流. 按照storm作者的说法,Storm对于实

运维工具大宝典之开源平台篇

from http://cio.it168.com/a2015/1128/1782/000001782714_all.shtml [IT168技术]在运维工具大宝典系列第一篇文章<运维工具大宝典之运维需求篇>中,云智慧对上云企业的运维需求进行的汇总,其中第6条“对开源的强烈需求”主要是来自运维人员,特别是技术大牛,他们喜欢一切尽在掌握的感脚,而这就需要开源运维工具. 目前流行的开源运维工具如Zabbix.Nagios等大部分来自国外,虽然这些开源产品功能非常强大,但对技术要求很高,而且缺少足够