监控体系建设（完整）

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

3)问题排查

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

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

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

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

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

???是否可缩小范围

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

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

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

???是否有足够的日志

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

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

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

4)应急文档

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

(1)系统级：

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

(2)服务级：

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

(3)交易级：

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!