智能运维(AIOps)中几处问题的解决方案与思路

栏目: 服务器 · 发布时间: 6年前

内容简介:运维人员必须随时掌握服务器的运行状况,除常规的服务器配置、资源占用情况等信息外,业务在运行时会产生大量的日志、异常、告警、状态报告等,我们统称为“事件”。通常每台服务器每个时刻都会产生大量这样的“事件”,在有数万台服务器的场合下,每天产生的“事件”数量是数亿级的,存储量可能是 TB 级别的。在过去,我们通常采用的方法是将日志保留在本地,当发现问题时,会登录出问题的服务器查看日志、排查故障,通过 sar、dmesg 等工具查看历史状态;监控 Agent 或者脚本也会将部分状态数据汇报到类似于Zabbix 这

1、海量数据的存储、分析和处理

运维人员必须随时掌握服务器的运行状况,除常规的服务器配置、资源占用情况等信息外,业务在运行时会产生大量的日志、异常、告警、状态报告等,我们统称为“事件”。通常每台服务器每个时刻都会产生大量这样的“事件”,在有数万台服务器的场合下,每天产生的“事件”数量是数亿级的,存储量可能是 TB 级别的。

在过去,我们通常采用的方法是将日志保留在本地,当发现问题时,会登录出问题的服务器查看日志、排查故障,通过 sar、dmesg 等 工具 查看历史状态;监控 Agent 或者脚本也会将部分状态数据汇报到类似于Zabbix 这样的监控软件中,集中进行监控和告警。

当服务器规模越来越大时,如何统一、自动化处理这些“事件”的需求就越来越强烈,毕竟登录服务器查看日志这种方式效率很低,而成熟的监控软件(比如 Zabbix、Zenoss 等)只能收集和处理众多“事件”当中的一部分,当服务器数量多了以后,其扩展能力、二次开发能力也非常有限。在具体实践中,当监控指标超过百万级别时,就很少再使用这种单一的解决方案了,而是组合不同的工具和软件,分类解决问题。

在通用设计方法中,有“大工具、小系统,小工具、大系统”的说法,这也符合 UNIX 的设计哲学,每个工具只做好一件事,一堆小工具组合起来可以完成很复杂的工作。如果使用的是一些大工具或者系统,表面上看功能很多,但是当你想处理更复杂的业务时,就会发现每一个功能都不够用,而且还很难扩展,它能做多“大”事取决于它的设计,而不是你的能力。

一个由典型的小工具组成的大系统,任何一个部分都可以被取代,你完全可以用自己更熟悉的工具来做,而且对工具或者组件的替换,对整体没有太大影响。

一提到海量数据的存储、分析和处理,大家就会想到各种各样的大数据平台。是的,大数据平台确实是用来处理海量数据的,但反过来不见得成立,对海量数据的分析和处理,并不总是或者只依赖大数据平台。

“分类”这个词听上去朴实无华,然而处理复杂问题最基本的方法就是分类,甚至“分类方法”也是机器学习非常重要的组成部分。“海量数据处理”这是一个宏大的命题,听上去让人一头雾水,但当你对“事件”或者需要处理的问题分类后,每一部分看上去就是一个可以解决的问题了。

如何对海量“事件”进行分类和处理。

  • 实时数据和非实时数据。

  • 格式化数据和非格式化数据。

  • 需要索引的数据和只需要运算的数据。

  • 全量数据和抽样数据。

  • 可视化数据和告警数据。

每一个分类都对应一种或多种数据处理、分析和存储方式。也可以说,当你对数据、需求完成分类后,基本的框架也就定了下来,剩下的工作就是集成这些工具。

2、多维度、多数据源

下图是一个多维度模型示例。真实世界的情况是(至少按弦理论学家所说的是),除我们可以感知的3个“延展维”外,还有6个“蜷缩维”,它们的尺寸在普朗克长度的数量级,因此我们无法感知到。

智能运维(AIOps)中几处问题的解决方案与思路

多维度模型示例

当然,运维数据中的“多维度”,还没有复杂到这样难以理解。

在相对复杂的业务场景下,一个“事件”除包含我们常用的“时间”(何时发生)、“地点”(哪个服务器/组件)、“内容”(包括错误码、状态值等)外,还应当包含地区、机房、服务池、业务线、服务、接口等,这就是多维度数据。

很多时候,数据分析人员可能要使用各种维度、组合各种指标来生成报告、Dashboard、告警规则等,所以是否支持多维度的数据存储和查询分析,是衡量一个系统是否具有灵活性的重要指标。

对多维度数据的处理,很多时候是一个协议/模型设计问题,甚至都不会牵扯具体的分析和处理框架,设计良好的协议和存储模型,能够兼顾简洁性和多维度。

不同的设计理念会对应不同的处理模型,没有优劣之分,只有哪个更合适的区别。

多数据源或者说异构数据源已经很普遍了,毕竟在复杂场景下并不总是只产生一种类型的数据,也不是所有数据都要用统一的方式处理和存储。

在具体的实践中,通常会混合使用多种存储介质和计算模型。

  • 监控数据:时序数据库(RRD、Whisper、TSDB)。

  • 告警事件:Redis。

  • 分析报表:MySQL。

  • 日志检索:Elasticsearch、Hadoop/Hive。

这里列出的只是一部分。

如何从异构的多数据源中获取数据,还要考虑当其中某个数据源失效、服务延迟时,能否不影响整个系统的稳定性。这考量的不仅仅是各种数据格式/API 的适配能力,而且在多依赖系统中快速失败和 SLA 也是要涉及的点。

多数据源还有一个关键问题就是如何做到数据和展现分离。如果展现和数据的契合度太高,那么随便一点变更都会导致前端界面展现部分的更改,带来的工作量可能会非常大,很多烂尾的系统都有这个因素存在的可能性。

3、信息过载

DDoS(分布式拒绝服务)攻击,指借助于客户/服务器技术,将多台计算机联合起来作为攻击平台,对一个或多个目标发动攻击。其特点是所有请求都是合法的,但请求量特别大,很快会消耗光计算资源和带宽,下图展示了一个 DDos 攻击示例。

智能运维(AIOps)中几处问题的解决方案与思路

DDoS 攻击示例

当我们的大脑在短时间内接收到大量的信息,达到了无法及时处理的程度时,实际上就处于“拒绝服务”的状态,尤其是当重大故障发生,各种信息、蜂拥而至的警报同时到达时。

典型的信息过载的场景就是“告警”应用,管理员几乎给所有需要的地方都加上了告警,以为这样即可高枕无忧了。

然而,接触过告警的人都知道,邮件、短信、手机推送、不同声音和颜色提醒等各种来源的信息可以轻松挤满你的空间,很多人一天要收上万条告警短信,手机都无法正常使用,更别谈关注故障了。

怎样从成千上万条信息中发现有用的,过滤掉重复的、抖动性的信息,或者从中找出问题根源,从来都不是一件容易的事情,所以业界流传着“监控容易做,告警很难报”的说法。

还有一个场景就是监控,当指标较少、只有数十张 Dashboard 时,尚且可以让服务台 24小时关注,但是当指标达到百万、千万,Dashboard 达到数万张时(你没看错,是数万张图,得益于 Grafana/Graphite 的灵活性,Dashboard 可以用程序自动产生,无须运维工程师手工配置),就已经无法用人力来解决 Dashboard 的巡检了。

历史的发展总是螺旋上升的,早期我们监控的指标少,对系统的了解不够全面,于是加大力度提高覆盖度,等实现了全面覆盖,又发现信息太多了,人工无法处理,又要想办法降噪、聚合、抽象,少→多→少这一过程看似简单,其实经过了多次迭代和长时间的演化。

这类问题在实践中的解决方法:

  • 数据的聚合。

  • 降低维度:聚类和分类。

  • 标准化和归一化。

有些方法属于工程方法,有些方法属于人工智能或机器学习的范畴。

4、复杂业务模型下的故障定位

业务模型(或系统部署结构)复杂带来的最直接影响就是定位故障很困难,发现根源问题成本较高,需要多部门合作,开发、运维人员相互配合分析(现在的大规模系统很难找到一个能掌控全局的人),即使这样有时得出的结论也不见得各方都认可。

在开发层面,应对复杂业务的一般思路是采用 SOA、微服务化等,但从运维的角度讲,完成微服务化并没有降低业务的复杂度(当然结构肯定变清晰了)。

在这里,又不得不强调工程能力的重要性。在复杂、异构和各种技术栈混杂的业务系统中,如果想定位故障和发现问题,在各个系统中就必须有一个可追踪、共性的东西。然而,在现实中若想用某个“体系”来一统天下,则基本不可能,因为各种非技术因素可能会让这种努力一直停留在规划阶段,尤其是大公司,部门之间的鸿沟是技术人员无法跨越的。

所以,下面给出的几种简单方法和技术,既能在异构系统中建立某种关联,为智能化提供一定的支持,又不要求开发人员改变技术栈或开发框架。

  • 日志标准化:日志包含所约定的内容、格式,能标识自己的业务线、服务层级等。

  • 全链路追踪:TraceID 或者 RequestID 应该能从发起方透传到后端,标识唯一请求。

  • SLA 规范化:采用统一的 SLA 约定,比如都用“响应时间”来约定性能指标,用“慢速比”来衡量系统健康度。

当这些工程(自动化、标准化)的水平达到一定高度后,我们才有望向智能化方向发展。

故障定位又称为告警关联(Alarm Correlation)、问题确定(Problem Determination)或根源故障分析(Root Cause Analysis),是指通过分析观测到的征兆(Symptom),找出产生这些征兆的真正原因。

在实践中通常用于故障定位的机器学习算法有关联规则和决策树。

还有很多方法,但笔者也在探索中,所以无法推荐一个“最佳”方法。究竟什么算法更适合,只能取决于实践中的效果了。

需要注意的是,并不是用了人工智能或机器学习,故障定位的效果就一定很好,这取决于很多因素,比如特征工程、算法模型、参数调整、数据清洗等,需要不断地调整和学习。还是这句话:智能化的效果不仅仅取决于算法,工程能力也很重要,而且好的数据胜过好的算法。

作者:博文视点

链接:https://www.jianshu.com/p/06c7dd803d4a


以上所述就是小编给大家介绍的《智能运维(AIOps)中几处问题的解决方案与思路》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

这就是搜索引擎

这就是搜索引擎

张俊林 / 电子工业出版社 / 2012-1-1 / 45.00元

搜索引擎作为互联网发展中至关重要的一种应用,已经成为互联网各个领域的制高点,其重要性不言而喻。搜索引擎领域也是互联网应用中不多见的以核心技术作为其命脉的领域,搜索引擎各个子系统是如何设计的?这成为广大技术人员和搜索引擎优化人员密切关注的内容。 本书的最大特点是内容新颖全面而又通俗易懂。对于实际搜索引擎所涉及的各种核心技术都有全面细致的介绍,除了作为搜索系统核心的网络爬虫、索引系统、排序系统、......一起来看看 《这就是搜索引擎》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

随机密码生成器
随机密码生成器

多种字符组合密码