如何快速建设手机app机房动力监控系统监控

随着信息网络技术的不断发展綜合机房动力监控系统的数量和规模与日俱增;机房动力监控系统规模大小不等,设备种类与数量不同的网络设备机房动力监控系统在分支机构所在地域也分布广泛为了保障机房动力监控系统安全可靠运行,机房动力监控系统环境设备(供配电、UPS、空调、温湿度、漏水等)是中小型机房动力监控系统是必不可少的重要设备它为计算机系统及各类生产设备的正常运行提供必要和可靠的保障。

但由于欠缺网絡的管理模式和无人值守机房动力监控系统的的不完善设施机房动力监控系统极有可能出现物理运行环境状况、动力配电状况、设备运荇状况、人员活动状况以及消防状况的变化包括可能出现的危急状况。也无法保障得到及时的发现和处理也很难被有效预见、防范和避免。

针对这些问题竣达技术科技结合现实生活的观点出发,运用手机微信来进行对机房动力监控系统动力及环境的监控以手机微信直接查看机房动力监控系统设备运行的状态数据、实时分析机房动力监控系统环境实时监控的数据。扫描网页上二维码即可实现监控无需額外设置。做到接线安装简便、操作便捷的特点大大提升了用户的体验。

利用了监控主机和可扩展开关量(如:烟感、漏水、温湿度等)来进行对机房动力监控系统动力及环境的整体监控,上传数据到云端无需手机卡,用户的手机微信就可直接查看机房动力监控系统運行与环境状态以及接受机房动力监控系统设备异常告警信息同时,针对机房动力监控系统类型的不同以及设备和用户的需求,竣达技术开发出了微信云动环的三种形态选择

手机微信操作极其简单,扫描设备二维码后点击查看“设备状态”或者“我的设备”即可查詢到设备的状态信息和历史告警信息。而且设备分享码在对应的设备里面“设备状态”最下方其他用户也可以直接用微信扫描对应设备嘚二维码关注该设备,做到多人同时在线监控

在检测到设备异常时,有着网络与区域都不限制、可多机房动力监控系统集中监控的特性会即时发送机房动力监控系统设备异常告警信息到用户所关注的手机微信上同时直观的展示机房动力监控系统动力及环境监控设备的實时状态及数据(如:UPS、烟感、温湿度等)及时排除故障隐患,从而极大的保障了机房动力监控系统及其设备的安全运作

从机房动力監控系统动力监控结合环境监控的模式进行云端数据管理,直达用户手机微信的微信云动环以及可多人同时在线监控和接收设备异常告警信息,为整个机房动力监控系统安全运行的提供保障更多的详细的功能,请关注竣达技术更期待您的留言!

}

当前动环建设的现状与存在的问題    由于各通信运营商的网络规模庞大维护人员工作量大造成维护工作质量下降,为了使动力维护和管理体制向集中监控、集中维护、集中管理的方向发展提高设备维护质量,确保通信设备的安全降低维护成本,大家都在进行

系统建设使用和情况看由于参与建设嘚厂家良莠不齐,部分地方的动力环境系统还存在一些问题:电信运营商计划规模大但实际建设的规模小,节省人力的效果不明著;个別地方建设的动环监控系统在维护生产中使用效果有限管理功能更是没有体现等等,这都是制约当前动环监控系统进一步建设的重要原洇

为什么一些地方建设的动环监控系统的使用效果不太理想呢

系统前景而进行开发的,由于没有长期的产品实际运行纪录和反馈加上經验少、技术不足等等,导致系统在开发出来后不能得到实际大系统运行的反馈信息并进行优化改良因此性能不佳,易出现错告、漏告而动环系统能否实现无人或少人职守是衡量该系统的主要标志,误告、错告导致使用者失去信心无法真正意义上获得用户的信任,实現不了无人职守而部分厂家解决问题也仅仅从硬件入手,改变的效果不明显加之一些厂家经验不足,没有告警信息的智能过滤系统系统显示的告警信息过多过滥,面对如此多的告警信息维守人员束手无策往往导致一些重要信息淹没在海量告警信息中,影响了系统的實际使用价值

:动力环境监控系统需要厂家和用户在系统建设完成后针对各地不同的运行维护管理体制进行相关的配制和设定,并将系統的管理功能模块针对用户的要求进行嵌套使监控中心各软件平台使用功能能配合用户逐步完善的运维管理体制而进行优化。但许多厂镓将设备安装调试接通作为动环系统建设的完工没有结合用户实际情况的优化工作,而且不主动维护出现问题才出面。系统的许多功能、方法用户不熟悉一些建设点由于搬迁、优化等原因而中断,没有及时帮助用户将其连入系统使动环监控系统使用效果低下,无法體现其本身真正具有的优势得不到运维人员的信任,无法成为维护管理的得力工具

3、一些产品的功能不够 :理想的动环系统应具备四個功能:告警功能,数据采集功能数据处理功能,管理辅助功能目前大多数动环监控系统只具备前两个功能,有的甚至只有一个告警功能(如干节点方式)如果出现漏告或错告,则该系统的功能就大打折扣同时采集的数据一般都需纯粹人工处理,而使用者由于不熟悉而没有或无法对庞大的数据进行处理相当于主动放弃了这部分功能。导致许多动环监控系统性价比不理想

建设有效的机房动力监控系统动环监控系统:

(1)作为管理部门,制定相应的管理制度与维护制度加强对动力监控系统维护方面的考核,责任到部门、责任到人对动力监控系统本身出现的故障或问题应该规定一个时限去进行修复,如前端硬件设备出现故障后应该在 24h内修复无法自行修复的应该12h內通知集成商,一周内修复硬件只有这样才能体现动力监控系统的作用,才能为机房动力监控系统实现无人值守提供必要条件

(2)动仂监控系统发挥作用离不开动力维护人员的积极参与,实践证明:动力维护人员对动力监控系统维护得好该系统就可以在本地网得到很恏的使用。若要正常、高效地使用动力监控系统离不开维护人员的精心维护。

(3)动力监控系统在故障方面可由网管中心负责使用与維护方面应该由动力维护部门负责,动力维护部门可以通过动力监控系统了解各个局动力设备的日常运行状况可以提前发现动力设备可能出现的问题或可能出现的故障,提高动力维护人员的维护水平与预检、预修的能力动力设备不同于交换、传输设备,动力设备在出现故障前往往会在运行参数上出现一些异常,但并不表现为故障当异常情况积累到一定程度时,就会发生质变导致故障发生。

专业厂镓在全国设有17个办事处,保障24小时本地化服务想了解更多机房动力监控系统动环监控产品,欢迎在线咨询或致电:400 088 6668

}

12 月 7 日在 2018 ArchSummit 全球架构师峰会·运维与监控专场,七牛云资深运维开发工程师贺强带来了主题为《如何快速构建高效的监控系统》的内容分享。

本文是对演讲内容的实录整理。

大家好今天给大家带来的分享是如何在创业公司去搭建一套高效快速的运维系统。我演讲的主要内容有:谈到高效我们如何来定义所谓的高效的监控系统;如何做好一个监控系统的选型和设计;七牛云内部的监控系统介绍;最后会和大家一起来探讨监控的发展趋势以忣未来展望。

如何定义「高效」的监控系统

在我认为,高效的系统应该包含以下几个特性:高可靠、易扩展、自适应、开放性

所有的能够体现高可靠的几点信息,第一是整个系统没有单点的模块无单点的风险,这是我们日常做系统或者做运维、做系统设计的时候需要艏先考虑的问题第二是本身会提供一个丰富的自采集系统层面的监控项,包括系统内核、设备、应用的一些资源消耗等信息第三是它所支持的监控种类比较丰富,因为我们现在的应用的类型也比较多像常见的对应用监控的需求,比如日志监控、端口监控、RPC 监控等等這些能够很方便的进行添加和管理。第三点是比较基础的高效、延时低,无论是数据采集、上报、计算处理、再到通知以及到用户收箌这个通知,整个效率是比较高的这也是和高效能够对应起来的。最后是易于 debug如果开发人员说监控没有报警或者误报警,如何 debug 这个信息快速修复问题。这是我对高可靠的一些认识

它其实是我们系统的开发过程中,对于运维侧以及部署和扩容方面的考虑这个系统很嫆易扩容和部署,它的依赖比较小其次,它能够达到快速部署的基础是它的数据存储是要集群化管理而不是数据和单机绑定,它的服務逻辑层需要去可水平扩展随着业务对监控的需求不断增加,监控的压力变大的时候能够快速地进行服务层面的水平扩展。

我认为这點比较重要我们很多传统的监控系统都是比较机械一点,为什么说机械就是说它监控的添加、修改之类的,都是需要我们人工手动的莋一些很多冗余的操作而不能随着服务器服务,我们监控对象的生命周期的运转比如说服务器上线、下线、运维、维修、新添加的服務或者服务下线,能够进行动态关联监控也随着这些对象的生命周期进行变化。还有是人员流转我们经常会遇到公司内部的员工入职、转岗、离职等方面,还会随着他的岗位状态运转能够自动匹配是否对它进行报警发送以及删除。

首先是要对外提供 SDK 或者 API 除了我们自巳运维侧采集一些监控,提供一些既有的监控还允许第三方开发和其他的人员对监控人员 push 一些数据,以及对这些数据的读取、处理

这樣几个特征,我认为是构成高效监控系统的必要因素

如何做好监控系统的选型和设计?

谈这点需要基于公司的现状去谈这个选型和设计因为在创业初期,最开始可能对运维和监控的关注度并不高我们在这块用于很粗粒度的方式去解决。拿七牛云来说从现在往前推一姩的时间,用的监控有 32 套单机版的 Prometheus

具体说说它的问题。首先单机 Prometheus它是一个开源很强大的单机版监控,它的问题也是它的特点有一套佷牛逼的查询语法,支持强大的数据查询功能能够满足各种方位、各种姿势对数据的需求,通过它的语句组合这样也导致了一个问题,运维人员如果没有深入研究这套语法的话就很难掌握灵活的语句去配置你的报警,存在的问题是少数人能够掌握这个问题学习成本仳较高,而精通的人更少

目前这个 Prometheus 没有比较好的分布式解决方案,所以出现了 32 套 Prometheus分业务去构建它的监控而且可能一个业务里面还存在哆套 Prometheus,因为受到单机性能的影响随着监控指标数据量不断增加,出现了这个瓶颈出现之后我们还要再进行扩容。这样长时间下来会絀现多套集群套用,数据和配置分布杂乱无统一入口。

我们做的更多是添加监控、修改阈值和条件原生的 Prometheus 是通过配置文件的方式,Prometheus 启動的时候加载然后会出现的配置文件大概有好几千行,一行代表一个监控一行是一个非常复杂的查询语句,每天有好多监控的需求需要重复的修改这些配置文件,无界面化管理操作效率非常低。

最后一个问题我认为比较重要的是监控和我们的业务服务器,还有业務服务之间没有一个动态关联关系因为都是静态的,有任何一方的改动都可能出现误报的情况我们调整了机器扩容或者下线机器,需偠完全手动修改配置和 Prometheus

基于这样的情况,我们期望改善这个现状因为这样的规模只会让情况变的越来越糟,不符合高效运维的定义

艏先设立几个目标,第一个是如何把这 32 套 Prometheus 进行统一化、统一入口作为一个运维的统一监控平台,来满足我们所有业务对于日常监控和数據处理、查询、报警的需求第一个目标是化简为繁。第二是可视化包括监控配置可视化和数据展示可视化。第三是动态关联保持监控对象的动态感知能力。

第四个也比较重要我们做一套新的监控,必须要考虑老的监控的东西需要往新的东西迁移在迁移的时候,必須要考虑成本如果做一套完全和新的结构迁移出东西,成本会非常高还有历史数据的迁移,我们用了监控数据做一些东西它的数据肯定还会迁移到新的数据上来,让它继续发挥作用它如何迁移、如何进行兼容,我们首先定义了一个目标

基于这个目标,我们做一个方案选型首先还是考虑 Prometheus,因为我们以前用的是 Prometheus它也很强大,我们不愿意放弃

优点是组件少、部署很方便;PromQL 强大的数据查询语法。它囿非常强大的查询数据的方法比如说通常会对数据进行打标签,对这个数据的标签进行一些组合然后查询到你需要的这些数据,在这些组合基础上它还可以提供一些很方便的函数,比如说求和、求平均值、求方差、求最大最小、求分位数我们通常需要写一些代码或鍺写一些脚本来满足这些函数能够简单达到的效果。

第三它是一个非常高可靠的时序数库,类似于一些优秀的数据库非常符合我们监控时序数据的存储和展示。第四它具有非常丰富的开源社区 exporter。Prometheus 社区里面会有一些针对各种开源软件的数据收集的一些组件都能找到对應的 exporter 组件,只要把它跑起来不用作为一个 DBA 或者专业的运营人员,你也可以很方便的拿到数据库应该关注的指标然后这些指标的数据表現形式是什么样的,而且配套的在平台上已经有很多开源的东西甚至可以一键导入,可以很方便的生成数据库的大盘数据

说完优点,峩们直面它的缺点主要是数据集群多、配置管理低下、配置报警起来没有界面,非常痛苦

我们会调研下一个监控方案,就是 Falcon这也是┅套国内比较优秀的监控系统。它有以下几个优点:首先组件都是分布式的没有单点模块,这符合我们高可靠的要求每个稳定性都很高,因为它在设计的时候完全考虑到了用户的使用策略所以所有的操作都是基于页面完成,这点比较人性化而且支持了很丰富的监控方式和方法。

但是基于基于我们公司的原有监控也有一些缺点。我们考虑迁移的时候原有的监控都需要废弃,需要做两种格式的兼容成本很高,历史数据也不能很方便的一键导入这也是需要直面的两个问题。

我们怎么做呢我们的选择方案是 Prometheus 分布式化,再加上 Falcon 高可鼡希望能够打造一款既满足高可靠、兼容性好、配置比较简单的一套系统来解决我们监控的痛点,做到取长补短

七牛云内部监控系统介绍

首先说一下我们监控系统在解决上面几个问题的时候,最终做出的一些比较有特色的地方第一是联动服务树,很多公司里面都会拥囿自己的监控平台其中服务树是一个很核心的组件,联动服务树是刚才提到的一个动态关联的基石第二个是分布式 Prometheus,可以进行数据存儲和告警功能还有一点是我们的监控是具有自动故障处理的特征功能。还有一个是监控自动添加除了我们提供人工添加的途径外,还鈳以自动添加

接下来具体介绍一下架构。

左侧绿色是我们内部的运维平台里面的两个小块 Portal 和服务树是两个和监控有密切交互的组件。祐侧是整个监控系统监控系统里面核心是分布式 Prometheus,底下是我们的服务器集群这是我们机房动力监控系统的业务机器,上面有一个 agent具體它们之间工作的流程:我们的分布式 Prometheus 主要提供 API 层的一些策略管理、一些监控添加,还有一些数据的存储、告警触发这边是把我们的操莋进行界面化,以及 API 层面存储的工作服务树是管理我们整个运维体系中这些对象的一个工具,它和分布式 Prometheus 之间会有一个同步的机制Alarm 会負责告警处理、告警消息的处理,包括合并、分级、优先级调整等工作还有我们的告警自动处理模块、数据聚合模块,用来计算出我们整个告警处理的效率和长尾统计分析的模块还有 agent,它是系统数据收集模块

接下来详细介绍以下几个主要的内容。

首先是服务树左侧這一列可以看出它是树状结构的东西,它是一组基于唯一 id 和 pid 生成的树状结构组织可以将运维的对象和树节点关联起来,包括日常的服务器、服务、初始化策略、监控策略、部署任务等等可以称之为它的运维对象。它和某一个节点关联起来就变成了某一个服务上面有哪些机器,以及它有哪些初始化策略、有哪些监控策略、有哪些部署任务这些都可以和服务树关联起来。只要我们维护好这个服务树就鈳以管理好日常的监控、发布、初始化等一切需求,包括服务署下面的服务器扩容、缩容也可以在这个服务树上来管理,它是这样一个組织关系

Portal 这块有很多功能,首先说一下监控性的功能它是一套带 UI 的配置功能,对于监控配置的监控项是配置监控策略、配置自定义腳本、配置值班信息、查看告警信息和历史数据。

我们配置的一些条件可能是我们上报上来的东西,里面有一些 Tags我们设置它的一些值,匹配好之后可以对这个数据进行求和、求平均、求最大、求最小,基于此会生成一条查询语句这样构成了一个监控策略,实际上是┅条模板化的查询语句然后在这边修改。还有告警级别、告警间隔、最大告警次数等信息

还有自定义插件,因为现在监控的需求比较哆很多需求很难通过监控系统本身来实现,所以我们提供了插件的功能只需要任意用脚本去写,然后按照我们的格式输出就能把你嘚格式收集上来,配置对应的监控项就可以它是绑定在某一个服务上面的脚本,针对这些服务做某些监控

上图有一些告警数据的告警截图。我们分不同的颜色展示不同的告警级别可能是一些微信的发送、以及对应的短信的分级通知机制。

最重要的一点是分布式 Prometheus因为 Prometheus 目前没有开源的集群化解决方案,我们是和第三方的公司进行合作开发的用它们对原生分布式 Prometheus 进行改造,同时纳入我们服务树的一些核惢的点进行考虑合作开发一套适合公司使用的分布式 Prometheus。对于原生 Prometheus 的原生改动主要就是把它对存储进行分离,然后把它的查询层和告警計算进行拆分进行了多级的高可用素质,存储方面进行了存储分片、查询调动其次是设计一些API,能够把 Prometheus的查询语句进行模板化监控筞略配置的时候,把它升级为一条条的存储语句存储起来就是把原生 Prometheus 一万多条的配置文件进行系统化、界面化的过程。

因为模板语句比較复杂所以我们提供了一个自动生成模板语句的功能,凡是用户自己配置的自定义脚本比如要生成监控的某一个东西,只要这个监控腳本提交了这个系统系统会自动调用它,然后给它生成模板语句不需要关心就可以看到模板语句,有他要求的 Tags有一些对应的约束值。

下面介绍我们的 alarm基于 Open-Falcon 的 alarm,首先改造成分布式的进行告警合并、告警优先级的策略,我们通常会遇到某些机器异构的情况我们对一批机器加一个优先级告警,可能有一些机器满一两块都没有关系我们对它进行一些特殊的策略设置。比如说告警的监控加在这块和子节點上我们希望看到 95% 的告警进行告警,告警发生过来的时候会有一些优先级策略的判断,会对它进行默认的屏蔽不会通知到用户。

这個告警接入公司统一的信息通告平台它支持我们几种用户的通知方式,重要的告警直接打电话不重要的分别有短信、微信这些方式去通知。

还有一个是 task它是一个同步的模块。主要涉及到服务树上面关联的信息通过异步的方式通知给服务器那边。就是我们服务上有哪些机器、端口是什么、进程名是什么、机器是否发生了变动、它的值班人员是什么都会异步去通知给 Prometheus 那边,Prometheus 那边知道我这个服务上面加叻哪些监控然后从用户配置的监控策略去查询到这些数据之后去匹配这些阈值,接到告警之后推送给值班人员,是这样一个过程这昰 task 模块起到数据同步的过程。

Auto-recovery 是我们做的监控自愈的模块我们要针对某一个监控设定一定的处理机制,如果它满足某些条件我们就对咜进行自动处理。自动处理的东西是人工处理好主要的工作流程是:在告警那边收到消息,但这个告警消息是分告警策略的这个信息屬于哪条策略,然后这个策略会对应一些规则匹配到这些规则再去看,规定了这些告警在什么情况下满足我定义的条件多长时间执行叻多少次,然后进行 action因为在每台机器上都会有服务器,我们有执行器然后执行到对应的服务器,执行完之后会把对应的结果推到微信群,历史记录和日志之类的可以去查看这是监控自愈的情况。

这是监控自动聚合统计的内容告警发生了认领的过程,体现了故障处悝的效率;还有一个是从认领到故障恢复故障处理用了多长时间,它来体现我们的值班效率;还有一些告警可能它发生的频次会比较哆,我们去通过一些大数据计算的方法然后提炼出在零散的告警里面体现不出来的一些问题,最后通过这个中心去把它发掘出来并进荇一个个的处理和追踪。

然后再说一下我们的 agent我们这个 agent 的特点是除了收集常见的几百项监控指标之外,凡是绑定了端口的服务这个服務进程所占用的系统资源、进程级别的,都会收集到还有一些协议级别的,比如说我这个机器上有通过一些网络请求调动另外一个协议这个开关比较耗资源,在某些部门才会用打开之后它就会生成一些 Tags,然后在绘图的过程中可以看到两个服务之间消耗情况的一些指标

还有插件执行器,我要在这个机器上执行某脚本只要是可执行文件就行,符合我们监控系统的格式要求

然后是 push-gateway,本地有一个 API业务方希望把服务运行过程中的一些指标实时上报监控进行报警绘图,只要我有了 agent就可以往 API 上面 push 数据,程序上面直接调用就可以把数据推送到监控系统中来,进行对应的告警

最后是探活,我们 agent 的存活保证了所有数据的可用性可能我们 agent 已经挂掉了,如果没有收到告警就觉嘚一切都正常可以探活每个 agent 的数据上报,如果有一段时间内没有收到 agent 的探活上报说明所有的告警已经失效了,这是作为内部监控的数據

以上就是我们内部监控的整体介绍。总结一下目前这套系统首先已经代替了 32 套单机的 Prometheus 监控,所有的操作都在界面上进行完成所有嘚监控都是具有一定的自动处理机制。在我们发布的时候也会去自动添加这个服务相关的服务器基础建构和服务的进程端口、重要接口嘚一些监控。

第一个是说我们也比较想做好因为现在的系统微服务比较多,相互调用的链比较复杂且比较长现在在单机的告警情况下,客户报一个故障上来之后我们很难快速的定位到底是哪个环节、甚至哪个函数出现了问题,而是需要人肉筛选在整个链路中到底哪个環节出了问题这是我们下一步跟踪的方向。

第二个是基于大数据的智能化监控现在大家都提 AIOps,我觉得 AI 要落地的话首先要把基础的数據收集基本功做好,在这个基础上积累一些现有的历史数据,分析一些趋势做一些自动化的调度和自动化的处理,实现无人值守的目標

以上是我的全部演讲内容,谢谢大家!

}

我要回帖

更多关于 机房动力监控系统 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信