设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 手机 数据 公司
当前位置: 首页 > 服务器 > 安全 > 正文

监控体系建设(完整)(5)

发布时间:2021-01-13 16:33 所属栏目:53 来源:网络整理
导读:事件发生之后,监控系统需要能自动分析事件的关联信息,帮助运维人员尽可能的还原事件现场,提高分析问题的能力,关联信息主要有纵向和横向的关系,其中纵向的关联是把基础设施、网络、系统、应用域、应用、交易关联起来

事件发生之后,监控系统需要能自动分析事件的关联信息,帮助运维人员尽可能的还原事件现场,提高分析问题的能力,关联信息主要有纵向和横向的关系,其中纵向的关联是把基础设施、网络、系统、应用域、应用、交易关联起来,任何一个环节出问题,向上计算出波及范围和受影响系统;横向的关联是以交易为中心,计算上下游的交易节点.下面分别是两个关联:

纵向关系:

横向关系:

4)事件触发

系统在设置报警策略时,可针对指标进行触发条件设置,触发条件按照类型分为阈值触发、基线触发、智能预测.系统根据不同的触发类型设置,采用的判断方式也不一样.具体明细如下:

??? 阈值触发

系统支持指标的阈值触发设置,当指标值达到设置的阈值时即可进行报警.

-阈值的设置范围只能在该指标的数值范围内进行设置.

–?阈值在设置时需要指定数值单位,防止数值因单位不同出现判断错误.

–?在设置阈值时系统支持实时查看指标当日折现图和历史基线,帮助运维人员正确判断阈值的设置范围.

????基线触发

系统支持指标的基线触发设置,当指标值达到设置的基线时即可进行报警.

-基线设置可按照昨日基线、月基线、周基线进行设置.

-系统支持在选定的基线基础上进行上浮或下沉幅度的设置.

-在设置基线时系统支持实时查看指标当日折现图和历史基线,帮助运维人员正确判断基线的设置范围.

-系统支持按照平均基线进行设置.

-基线设置时需要有一定的历史数据作为依据.

????智能预测

智能预测主要是通过历史数据的分析,通过人工智能算法预测未来可能出现的问题,这一块是未来监控事件优化的一个方向.

3、事件应急

1)应急恢复

运维最基本的指标就是系统可用性,应急恢复的时效性是系统可用性的关键指标.通常来讲应急恢复的方法有不少,比如:

???服务整体性能下降或异常,可以考虑重启服务;

???应用做过变更,可以考虑是否需要回切变更;

???资源不足,可以考虑应急扩容;

???应用性能问题,可以考虑调整应用参数、日志参数;

???数据库繁忙,可以考虑通过数据库快照分析,优化SQL;

???应用功能设计有误,可以考虑紧急关闭功能菜单;

???还有很多……

监控系统的事件丰富过程中需要尽可能关联上述的一些应急手段,供运维人员快速应急,比如服务启停工具、切换工具、程序回切工作等,比如下面这个应用服务启停工具例子:

2)现场保护

故障处理中,理论上应该在应急前进行现场保护以备问题原因排查的跟进.现场信息主要包含进程内部状态信息、日志信息.实际应用过程中可以结合工具进行现场保护,仍以服务启停工具为例,支持获取进程线程镜像信息、进程内存镜像信息及GC日志信息.

3)问题排查

???是否为偶发性、是否可重现

故障现象是否可以重现,对于快速解决问题很重要,能重现说明总会有办法或工具帮助我们定位到问题原因,而且能重现的故障往往可能是服务异常、变更等工作导致的问题.

但,如果故障是偶发性的,是有极小概率出现的,则比较难排查,这依赖于系统是否有足够的故障期间的现场信息来决定是否可以定位到总是原因.

???是否进行过相关变更

大部份故障是由于变更导致,确定故障现象后,如果有应的变更,有助于从变更角度出现分析是否是变更引起,进而快速定位故障并准备好回切等应急方案.

???是否可缩小范围

一方面应用系统提倡解耦,一支交易会流经不同的应用系统及模块;另一方面,故障可能由于应用、系统软件、硬件、网络等环节的问题.在排查故障原因时应该避免全面性的排查,建议先把问题范围缩小到一定程序后再开始协调关联团队排查.

???关联方配合分析问题

与第(3)点避免同时各关联团队同时无头绪的排查的同时,对于牵头方在缩小范围后需要开放的态度去请求关联方配合定位,而对于关联方则需要有积极配合的工作态度.

???是否有足够的日志

定位故障原因,最常用的方法就是分析应用日志,对运维人员不仅需要知道业务功能对应哪个服务进程,还要知道这个服务进程对应的哪些应用日志,并具备一些简单的应用日志异常错误的判断能力.

???是否有core或dump等文件

故障期间的系统现场很重要,这个在故障应急前建议在有条件的情况下留下系统现场的文件,比如CORE\DUMP,或TRACE采集信息等,备份好一些可能被覆盖的日志等.

4)应急文档

故障的表现虽然形式很多,但实际的故障处理过程中,应急措施往往重复使用几个常用的步骤,所以应急文档首先要针对这些常用的场景,过于追求影响应用系统方方面面的内容,会导致这个方案可读性变差,最终变更一个应付检查的文档.以下是我觉得应用系统应急方案应该有的内容:

(1)系统级:

能知道当前应用系统在整个交易中的角色,当前系统出现问题或上下游出现问题时,可以知道如何配合上下游分析问题,比如:上下游系统如何通讯,通讯是否有唯一的关键字等.另外,系统级里还涉及一些基本应急操作,比如扩容、系统及网络参数调整等.

(2)服务级:

能知道这个服务影响什么业务,服务涉及的日志、程序、配置文件在哪里,如何检查服务是否正常,如何重启服务,如何调整应用级参数等.

(3)交易级:

(编辑:ASP站长网)

网友评论
推荐文章
    热点阅读