欢迎您光临优德w888!

优德w888 > 军事资讯 > IT运维监控解决方案介绍

IT运维监控解决方案介绍

时间:2019-12-19 12:27

•测试ZabbixNode

告警规则3

当value连续1分钟 >= 0.5,< 0.8时产生Warning级别的告警,当value连续1分钟 >= 0.8时产生Critical级别的告警。

当产生Warning级别的告警后,当连续出现1分钟< 0.5的事件数据时,产生Close事件把Warning告警关闭。

当产生Critical级别的告警后,当连续出现1分钟 < 0.8区间的事件数据时,产生Close事件把Critical告警关闭。

Warn create epl:

insert into Warn select (select value from GenericMetric.std:lastevent()) as value, (select name from GenericMetric.std:lastevent()) as name, (select tags from GenericMetric.std:lastevent()) as tags,current_timestamp as timestamp from pattern[ every (GenericMetric(value >= 0.5 and value < 0.8) -> ( timer:interval(60 sec) and not GenericMetric(value < 0.5 or value >= 0.8)))]

Critical create epl:

insert into Critical select (select value from GenericMetric.std:lastevent()) as value, (select name from GenericMetric.std:lastevent()) as name, (select tags from GenericMetric.std:lastevent()) as tags,current_timestamp as timestamp from pattern[ every (GenericMetric(value >= 0.8) -> ( timer:interval(60 sec) and not GenericMetric(value < 0.8)))]

Warn close epl:

insert into Close select (select name from GenericMetric.std:lastevent()) as name,current_timestamp as timestamp from pattern [every (Warn -> ( timer:interval(60 sec) and GenericMetric(value < 0.5) and not GenericMetric(value >= 0.5)))]

Critical close epl:

insert into Close select (select name from GenericMetric.std:lastevent()) as name,current_timestamp as timestamp from pattern [every (Critical -> ( timer:interval(60 sec) and GenericMetric(value < 0.8) and not GenericMetric(value >= 0.8)))]

如果 没有CEP,要实现上述告警规则需要构建状态机,以及对状态跳转过程中的历史数据的记录,实现起来比较复杂,但是基于esper,对应每个规则只是一句简单的EPL,而且多个规则可以同时起作用,代码可读性以及扩展性都比构建状态机要好很多。

通过OneCenter的故障告警功能,可以直接获得IT资源的故障告警通知; 

•Zabbix代码优化

告警规则2

当value连续10次 >= 0.5,< 0.8时产生Warning级别的告警,当value连续10次 >= 0.8时产生Critical级别的告警。

当产生Warning级别的告警后,当连续出现10次< 0.5的事件数据时,产生Close事件把Warning告警关闭。

当产生Critical级别的告警后,当连续出现10次 < 0.8区间的事件数据时,产生Close事件把Critical告警关闭。

告警的生成规则和规则1是相同的,这里就不再重复给出,需要关注的是关闭的规则与之前不同:

Warn close epl:

insert into Close select (select name from GenericMetric.std:lastevent()) as name,current_timestamp as timestamp from pattern [every [1] (Warn -> every [10](GenericMetric(value < 0.5)))]

Critical close epl:

insert into Close select (select name from GenericMetric.std:lastevent()) as name,current_timestamp as timestamp from pattern [every [1] (Critical -> every [10](GenericMetric(value < 0.8)))]

远程无代理模式的监控,不需要现场到设备跟前,也可以及时了解设备的运转状态;

•微信公众号:OpenFalcon

监控告警需求

监控原始事件定义如下:

//name代表监控指标的名称,例如CPU.CPUUtil

//timestamp指某一个具体的时间点

//value代表在timestamp时间点的指标值

//tags里面存储了一些其他描述信息,例如服务器名,ip地址,所属业务系统等等

case class GenericMetric(timestamp:Long, name:String, value:Any, tags:Map[String, Any])

//timestamp代表Warning产生的时间点

//name代表指标名称

//value代表产生Warning前最后一个事件的值

case class Warning(timestamp:Long, name:String, value:Any, tags:Map[String, Any])
//timestamp代表关闭事件产生的时间点

//name代表指标名称

case class Close(timestamp:Long, name:String)
//timestamp代表Critical产生的时间点

//name代表指标名称

//value代表产生Critical前最后一个事件的值

case class Critical(timestamp:Long, name:String, value:Any, tags:Map[String, Any])

通过OneCenter一体化监控功能实现全网上千种IT资源的统一管理;

•为什么选择Zabbix

CEP对IT运维的价值

传统的ITOM主要对底层的软硬件基础架构对单一指标基于静态的阈值进行监控告警,这里有两个关键词:基础架构 以及 单一, 这其实正好对应了传统IT监控的两大痛点。单一导致的结果就是误报,服务器的CPU利用率上升有时是因为交易量的上升带来的正常现象,只要在合理区间内就无需告警,但是CPU利用率的孤立上升就可能是因为代码缺陷造成的,有经验的工程师一眼就能看出是否是故障,是因为工程师在一瞬间就综合分析了各个相关指标。针对基础架构则让运维人员的生活非常苦逼,有功劳都是其他部门的,出了故障都是运维的兄弟在顶包,所以近些年来基本上所有的公司都在做APM,通过网络抓包或者日志埋点等方式可以提取交易成功率/交易量/成功率等反映业务性能的指标,做了不少漂亮工程,不过不管是交易量还是成功率都还是从系统的角度去看问题,真正能带来多少业务价值其实也很难说,大屏上那些五颜六色的图表可能更多时候也是在领导检查或者参观时才体现其价值。从数据来看,其实IT运维过程中的数据是最完整的,既有包含了服务器,网络设备等基础设施的底层运行信息,也有包含中间件和数据库的中间层系统信息,还有包含了全部业务过程的上层应用日志信息,在这个数据时代,IT运维正在向IT运营转变,理应能够发挥更大的业务价值,举例对于一个金融公司,如果能从应用日志中提取到同一个账户在1分钟内在距离50公里的两地柜员机取款的类欺诈信息来支撑风控,IT运维所承担的就不只是保障作用,而是直接参与到了业务决策过程当中。虽然CEP不是为IT运维管理而生,但是在一定程度上CEP确实可以解决上述两个问题,CEP最强大的就是其模式匹配引擎,其不仅可以作用于不同类型的事件,更可以按照时间窗口,发生顺序和次数以及其他状态聚合结果进行模式匹配,可以和各种业务规则进行对应。另外CEP是直接作用于流式数据,而非通过定期查询数据库的方式,因此最实时,且对数据库没有任何压力。目前的Flink流引擎已经自带了CEP模块,Flink官方给出的CEP例子正好就是针对数据中心监控的场景,案例中需要对Rack的温度进行监控,对于同一个Rack,当10秒内连续两次温度超过温度阈值时预警,当20秒内产生连续两个预警,且第二次预警温度高于第一次时进行告警,该模式中有不同状态的切换,有时间窗口的滑动等,如果没有CEP,需要自行构建对应的状态机进行处理,但是基于CEP强大的模式挖掘能力之上的实现非常简单,由此可见CEP的威力。不过Flink中的CEP模块是与其流失API紧密结合的,如果我们的前置流引擎不是Flink,则无法直接使用。我们在构建智能化监控系统时,从性能方面去考虑,在流引擎与CEP之间添加了基于AKKA的多层路由模块,可以按照业务系统,服务器,实例以及指标级别进行消息的路由,CEP引擎内嵌在每个Actor内部,可以在不同的路由级别对不同范围的消息进行模式匹配。下图是对应的架构图。 监控系统的架构以及对应实现不在我们这篇文章范围之内,本文接下来介绍下如何使用CEP来完成一个复杂监控告警从生成到关闭的过程。

图片 1

arch.png

卡管系统对于网络质量要求较高,卡管机房中心到全市各网点线路应保障通畅,故障应及时上报和处理;

云监控
•服务端Host在公有云上
•无需客户安装、运维服务端
•支持namespace隔离、quota限额
•从根本上对不同用户的数据进行隔离
•优化监控的添加、管理、查看流程
•提升用户体验、提高用户使用效率

CEP作为监控告警的规则引擎

本文中使用了一个开源的CEP组件esper(https://github.com/espertechinc/esper),目前该组件已经被weblogic等中间件厂商集成到自己的日志异常检测功能中,其本身是一个JAR库,无需其他运行时框架,所以使用起来非常方便。其支撑一种DSL语言EPL,与SQL类似,用户通过输入不同的EPL来定义不同的匹配模式。本文不包含基本的EPL语法介绍,有兴趣的同学可以移步这里(http://blog.csdn.net/luonanqin/article/details/21300263) 以及esper的官网(http://www.espertech.com/esper/)。本文主要从一个实际的监控需求案例出发,来介绍esper的相关功能。

现状描述及需求分析

•独立部署多套Zabbix,通过API整合

小结

本篇是从基础架构监控的层面来介绍了CEP,当然CEP更强大的功能是对结构化后的日志数据进行模式匹配,与复杂的业务规则进行对应,发挥更大的业务价值,后续的CEP系列文章里面会更多从日志数据挖掘的方面去做相关先容。此外,基于AKKA构建分布式的监控告警系统也是一个很有意思的主题,充分利用了actor的轻量级优势,通过创建百万甚至千万级别的actor与各指标进行对应,充分利用了服务器的计算资源,在相对普通的服务器集群上可以支持海量的指标实时有状态监控,后续也会单独进行介绍。

通过报表管理,收集设备每周每月的状态。

云服务提供商:监控宝、oneAlert等

CEP简介

CEP全称为 Complex Event Processing 复杂事件处理,其可以通过在流式数据中发现符合某种特征的模式进而触发对应的后续动作,其既支撑基于单条事件的简单无状态的模式匹配(例如基于事件中的某个字段进行筛选过滤),也可以支撑基于关联/聚合/时间窗口等跨事件的复杂有状态模式匹配(例如计算滑动时间窗口移动均值)。受益于其直接作用于流式数据,无需查询持久化数据库,对底层数据库不会产生任何压力,以及其强大的模式发现能力,在监控系统中,如果把CEP与流处理引擎结合,在IT运维管理中,可以大大增强告警的实时性以及适用范围。

逾期收益

•深度定制,用于大数据部门平台服务监控与自动运维,生产环境已上线

告警规则1

当value连续10次 >= 0.5,< 0.8时产生Warning级别的告警,当value连续10次 >= 0.8时产生Critical级别的告警。

当产生Warning级别的告警后,当出现不在 >= 0.5 < 0.8区间的事件数据时,产生Close事件把Warning告警关闭。

当产生Critical级别的告警后,当出现不在 < 0.8区间的事件数据时,产生Close事件把Critical告警关闭。

Warning create epl:

insert into Warn select (select value from GenericMetric.std:lastevent()) as value, (select name from GenericMetric.std:lastevent()) as name, (select tags from GenericMetric.std:lastevent()) as tags,current_timestamp as timestamp from pattern[ every [10] (GenericMetric(value >= 0.5 and value < 0.8) and not GenericMetric(value < 0.5 or value >= 0.8))]

Critical create epl:

insert into Critical select (select value from GenericMetric.std:lastevent()) as value, (select name from GenericMetric.std:lastevent()) as name, (select tags from GenericMetric.std:lastevent()) as tags, current_timestamp as timestamp from pattern[ every [10] (GenericMetric(value >= 0.8) and not GenericMetric(value < 0.8))]

Warn close epl:

insert into Close select (select name from GenericMetric.std:lastevent()) as name,current_timestamp as timestamp from pattern [every [1] (Warn -> (GenericMetric(value < 0.5 or value >= 0.8)))]

Critical close epl:

insert into Close select (select name from GenericMetric.std:lastevent()) as name,current_timestamp as timestamp from pattern [every [1] (Critical -> (GenericMetric(value < 0.8)))]

方案亮点

赶集

行业特性

Zabbix实践思路

以IC卡电子应用和公司管理信息化为主攻方向,同时完善信息网络,统一标准体系,强化技术保障,确保系统安全,实现各部门、系统间的信息数据资源共享、互连互通; 建成卡管工程部调度控制和安全生产的现代化保障体系。勤智IT运维成为市民卡运营管理部门信息化建设道路上的有效助力。

以上内容部分来自网络, 希望对您系统架构设计,软件研发有帮助。 其它您可能感兴趣的文章:

根据市民卡运营管理部门的运维需求,勤智建议采用OneCenter运维监控平台。

Aggregator 目标:集群监控
•针对某个hostgroup的多个counter进行计算
•分子:$(c1) + $(c2) -$(c3)
•分母:可以是$# 或者数字或者$(d1) + $(d2) -$(d3)
计算结果
•封装成一个metricItem,再次push回open-falcon
为什么这么实现
•归一化的问题解决方案
•复用整个open-falcon的绘图展现、告警逻辑

通过资源监控管理功能,统一管理卡管系统中的各种资源,监控网络设备、主机的运行情况;利用报表分析功能,根据用户自定义的方式周期性提供设备负载分析相关报表;针对卡管系统运维管理人员关注的数据,提供个性化支持和多种效果展示;通过告警管理功能,在卡管系统出现故障后,及时通过短信等方式通知运维管理人员,并生成告警分析统计报告。

Open-Falcon是小米运维团队设计开发的一款互联网企业级监控系统

v 当设备或应用系统出现故障后,能通过预置的报警方式及时通过邮件、短信等方式通知指定管理人员,并能生成告警分析统计报告,提供主动式的故障解决方式。

开源方案:Zabbix、Nagios、Cacti…

v 需要对卡管系统IT软硬件统一监控管理,及时了解IT软硬件设备的运行趋势,快速定位故障;

graph
•操作rrd文件,对数据进行存储和查询
•将多次操作合并后再flush磁盘
•将要flush到磁盘的数据,打散到每个时间片,降低IO消耗
•为什么用rrd而不是opentsdb之类的?

随着信息应用的专业化程度不断深入,其网点规模愈发庞大,应用的复杂性越来越高,业务开展高度依赖信息化平台的支撑,整个卡管系统的管理维护能力将直接影响到信息化应用的正常开展,因此对IT管理部门的支持与服务保障提出了较高的要求。

agent
•负责机器数据采集
•自发现各项监控指标
•发送数据给transfer
•发送心跳信息给hbs
•执行自定义插件
•业务数据不要用插件采集!
•数据收集采用推还是拉的方式?

公共交通卡(即交通IC卡)主要应用于公共交通领域,包括公交车、轨道交通等应用。另,市民卡运营管理部门一般会有几百个公共交通卡自营网点及代理网点。

•QQ讨论组:373249123

为促进公共交通持续发展的需要,市民卡运营管理信息部门在政务管理信息化、信息服务社会化方面做了大量工作,在业务应用系统开发、基础数据库建设和信息化基础设施建设等方面取得了明显成效。

 

解决方案

judge •对接收到的数据按照阈值进行判定
•达到阈值的数据产生相应的event
•触发式判定or 轮询?
•为什么要使用内存?

市民卡运维部希望通过先进的技术手段和管理理念,实现对整个设备网的实时监控和全面管理。

图片 2

为了满足业务需求,市民卡公司不断扩充卡管系统设备资源。比如,某卡管系统全网网络设备的数量多达100多台,设备厂商多达5种,还有近100台主机和应用系统,终端用户数量已经上万。然而,市民卡运营管理信息部门管理人员较少,面对多个厂家、不同类型的网络设备、主机及应用系统,一旦出现故障,难以定位故障原因并及时有效解决。

•使用模式优化

卡管系统对于IC卡电子设备维护能力要求较高,一旦出现故障应有专门的服务流程平台报障、维修和跟踪;


为促进公共交通持续发展的需要,市民卡运营管理信息部门积极推动卡管系统信息化建设,在业务应用系统开发、基础数据库建设和信息化基础设施建设等方面取得了明显成效。市民卡运营部门对整个卡管系统(包括业务应用系统、基础数据库和IT基础设施)的管理维护能力直接影响到公司业务的正常开展。

构建高效的研发与自动化运维
互联网数据库架构设计思路
移动开发一站式解决方案
某大型电商云平台实践
公司级应用架构模式N-Tier多层架构
某公司社交应用网络拓扑架构图
IT基础架构规划方案一(网络系统规划)
餐饮连锁公司IT信息化解决方案一

市民卡运营管理部门主要经营交通IC卡及IC卡应用电子系统的建设、维护、管理,IC卡的充值、清算、发放,以及IC卡收费系统机具设备的销售和维修。

•正在开发测试drrs(一种分布式的time series data 存储组件)并适配falcon

卡管系统的应用服务器数量较多,应用服务器均需要有保密和备份机制。

 

•Zabbix是一款开源的公司级监控系统

Zabbix遇到的问题

•深度调研open-falcon

图片 3

现状

•不利于自动化,不利于与运维平台等基础设施整合

•提供最好用、最人性化的互联网企业级监控解决方案

 

•集成服务树、支持ping监控、多机房架构支撑、报警第二接收人支撑

Gateway——跨数据中心

•小公司/ 创业团队< 500台服务器规模

历史数据高可用
rrd-on-hbase
•绘图数据存储在hbase中,解决高可用的问题
•历史数据提供更详细粒度的查看
drrs(@京东金融)
•Distributed Round Robin Server
•面向中心公司,轻量级的历史数据存储方案,解决数据扩容的问题

投入大量的人力,内部自研,与业务严重耦合没法作为产品推出

希望对您运维管理有帮助。

无从可选

•中间阶层

如有想了解更多App研发 , 系统 IT集成 , 公司信息化,项目管理 等新闻,请关注我的微信订阅号:


Open-Falcon部署实践
•初始阶段
•所有的组件部署在一台物理机上即可
机器量级~ 500
•graph、judge、transfer三个组件拆分出来部署在1台服务器上
机器量级~ 1000
•graph、judge、transfer 增加到2~3个实例
•query拆分出来,部署2个实例
•dashboard 拆分出来部署
机器量级~ 10K
•graph、judge、transfer 增加到20个实例,graph尽量使用ssd磁盘
•query增加到5个实例
•dashboard 拆分出来,增加到3个实例

接驳服务树(CMDB)
•开源服务器管理组件(服务树)
•监控对象通过服务树来管理
•服务器进出节点、监控自动变更

•告警策略的维护、变更代价太大,导致运维人员深陷其中,无法自拔

•用户“使用效率”低下,学习成本很高

 

•openTSDB

 

•Collectd

•MySQL 监控方案

•Github:

 

智能告警
同比、环比
•Dashboard数据展示支撑同比、环比
•告警判定引入同比、环比作为参考
动态阈值
•通过对历史数据的学习,生成动态的告警阈值
关联分析
•精准告警
•故障定位

早期,选用Zabbix

内部 

query

•不具备水平扩展能力,无法支持业务需求

SDK
七层
•Nginx
•统计cps、200、5xx、4xx、latency、availability、throughput
语言支撑Java/C++/PHP/Python
•内置统计每个接口的cps、latency
•内置统计业务关注的指标的能力
框架支撑
•resin、spring、flask…
统计类型
•Gauge/ Meter / Timer / Counter / Histogram

•随着公司业务规模的快速发展

其他
•Callback功能增强,推进故障自动处理
•插件的管理支撑多种方式(不仅限于git)
•Dashboard 增加用户登录认证
•告警排班/ 告警升级(@金山云)

图片 4

•Cacti

•BAT级别> 10万台服务器

 

•利用一致性hash算法,查询多个graph的数据并汇聚
•需要使用与transfer相同的hash算法及配置


•Nagios

•Agent宕机监控

•交换机监控

作者:Petter Liu
出处:
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。

典型案例

•Redis/memcached/rabbitmq监控

•对其进行二次开发、封装、调优...

 

transfer •对接收到的数据做合法性校验
•转发数据给graph和judge
•为什么要做这个统一的接入端?
•为什么要对数据做分片?
•数据分片方案,用一致性hash还是路由表?

•正在开发openTSDB接口、query增加正则功能

Open-Falcon

•项目主页:

hbs
•提供接口给agent查询机器所需监控的端口、进程、要执行的插件列表等信息
•接收agent汇报的状态信息并写入数据库
•缓存用户配置的告警策略
•为什么要用hbs缓存策略列表?

京东金融

美团

社区贡献

•生产环境广泛应用,1万+agent

•Windows监控

各web端
•Dashboard负责绘图、展示、仪表盘等
•Uic负责管理组合人的对应关系
•Alarm-dashboard负责展示当前未恢复的告警
•用户在portal中配置告警策略
•Portal中的hostgroup一般是从CMDB中同步过来的!

•RRDtool

上一篇:无声戏(2) 下一篇:没有了