资讯专栏INFORMATION COLUMN

内存库长事务告警的自愈之路

IT那活儿 / 1515人阅读
内存库长事务告警的自愈之路

一条告警,在不同阶段回顾,常会有新想法:内存库(TimesTen)长事务告警就是这样,从最开始的简单告警,到逐渐完善成可以自愈的告警。

首先我们要知道什么是内存库长事务,顾名思义就是运行时间较长、长时间未提交的事务,这类事务往往会造成主备同步延时影响主备及时性,一般临时处理方法是内存库维护人员将应用信息反馈给应用维护人员,经授权后应用侧重启对应进程。

这个流程涉及的操作步骤如下:




回顾各个阶段如下:




下面回顾下是如何在不同阶段一步步对该告警进行完善的:


1

初学内存库

刚学内存库时,长事务告警是这样的:

TT: 长事务告警:地市-主机IP-系统用户-内存库实例-库角色 , 共 3 个, 2017/09/13 03:00,请核查.

告警发出后,TT维护人员、应用维护人员分别根据操作手册《【工作手册】TT内存库出现长事务处理方法-20161115.docx》进行处理;


2

深入内存库

经过深入学习后,对长事务告警可能出现的各种情形有了积累,告警场景及处理方法逐渐明确完整,告警调整成这样的:

TT: 长事务告警:地市-主机IP-系统用户-内存库实例-库角色-10个,应用详情:应用主机1.IP 应用进程号1;应用主机2.IP 应用进号2;应用主机3.IP 应用进程号3, 2018/3/16 01:11,请核查.

这时告警发出来后,应用维护人员直接根据告警短信中的应用详情部分(进程主机IP地址、进程号),在BOSS后台进程管理界面(Taskmon平台)上查找进程的菜单路径、名称,审核影响,经授权后执行进程停止、启动操作。

注:BOSS后台进程管理界面


3

初学应用

工作内容调整投入到应用维护中,再次收到了长事务告警,看着短信里面的主机IP和进程ID,想着如果直接把进程路径及名称写出来不是更好吗?经过一段时间的学习,梳理清楚了在数据库sql查询方法,这时长事务告警调整成这样的:

TT: 长事务告警:地市-主机IP-系统用户-内存库实例-库角色-2个,应用详情:应用主机1.IP ping正常,200集群_CBE系统->200_离线二批->批价合账合并进程_CBE_RATE728_689_1->intcb_proc->20053203146->应用主机1.IP:应用进程号1;应用主机2.IP ping正常,200集群_临时抢占进程->200_TMP_二批->TMP_批价合账合并进程_CBE_RATE715_683_1->intcb_proc->20053202443->应用主机2.IP:应用进程号2, 2019/8/24 18:50,请核查.

告警发出来后,一眼就知道是什么业务进程、在平台的哪个界面操作,这时不用再登主机查信息了,应用维护人员(或移动值班室人员)直接登录进程管理界面就可以处理了。


4

深入应用

随着应用的深入学习,知道了进程的启停不仅只能人工在界面处理,还可以通过调用接口实现;于是想到了正好可以做长事务告警的自愈处理,于是告警调整成下面这样的:

内存库: TT: 长事务告警:地市-主机IP-系统用户-内存库实例-库角色-2个,应用详情:应用主机1.IP ping正常,201集群_CBE系统->201_不计费流量话单匹配用户资料_event_trans->CBE_RATE710_GPRS_FREE_731->event_trans->20180130020->应用主机1.IP:应用进程号1,已重启;10.25.19.195 ping正常,201集群_CBE系统->201_离线二批->批价合账合并进程_CBE_RATE710_735_1->intcb_proc->20153203690->应用主机2.IP:应用进程号2,已重启; 2020/8/10 19:00,请核查.





梳理各个阶段如下:







总结思考如下:




内存库长事务告警的自处理,最开始告警的处理、登记占用了大部分维护时间,且都是重复性的工作,现在告警短信包含了所有信息并且自动处理,维护人员可以将注意点转变到告警原因的统计分析工作上,挖掘更有价值的信息;

本文列举的样例只是很小的一个点,提升的效果也是有限的;自以为其他事情也一样,随着技术的提升、角色的调整、思维的转变,在不同阶段对同一件事情往往会有不同的看法,所以需要经常回头看下以前做的事情,不断完善;一个点带来的效率的提升可以不断正向激励自己,陆续积累的点逐渐汇聚起来,提升工作效率。

目前现场引入了自动化运维平台,再回头看内存库长事务的告警处理,又能碰撞出什么样的火花呢?且听下回分解。


END


更多精彩干货分享

点击下方名片关注

IT那活儿

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129903.html

相关文章

  • “大促”背后技术 | 当我们说促销时候,我们在谈什么?

    摘要:郭理靖表示,在京东商城的实践中,针对线上系统选择构建两个机房,分别是生产环境以及在灾备环境。在监控引擎方面,京东云的尝试也是比较细致的,其中包括监控服务报警服务等。进一步,根据不同的报警,我们可以定位到 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/...

    20171112 评论0 收藏0
  • “大促”背后技术 | 当我们说促销时候,我们在谈什么?

    摘要:郭理靖表示,在京东商城的实践中,针对线上系统选择构建两个机房,分别是生产环境以及在灾备环境。在监控引擎方面,京东云的尝试也是比较细致的,其中包括监控服务报警服务等。进一步,根据不同的报警,我们可以定位到 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/...

    张巨伟 评论0 收藏0
  • “大促”背后技术 | 当我们说促销时候,我们在谈什么?

    摘要:郭理靖表示,在京东商城的实践中,针对线上系统选择构建两个机房,分别是生产环境以及在灾备环境。在监控引擎方面,京东云的尝试也是比较细致的,其中包括监控服务报警服务等。进一步,根据不同的报警,我们可以定位到 showImg(https://segmentfault.com/img/bVbtNqp?w=688&h=113); showImg(https://segmentfault.com/...

    王岩威 评论0 收藏0
  • New Relic性能监控(二)应用监控APM

    摘要:左边侧边栏分为三个组,分别为监控数据,事件和报告。从接到请求到响应处理完成的过程为称为一次事务。针对应用,还提供性能监控数据,包括内存使用,线程数等等。 New Relic性能监控(二)应用监控APM 2018-04-12 琅琊书生本系列文章基于公司使用New Relic的经验,鉴于国内较少有这方面的文章,因此把我工作中了解到的知识分享给大家,希望可以给需要的朋友带来帮助。 上期文章...

    wangxinarhat 评论0 收藏0
  • “懂运维、精运营、重服务” UCloud发布混合云多云管理平台UCMP

    摘要:企业微信截图企业微信截图多云异构环境下的资源统一管理在混合云的架构下,不同云服务商提供的基础资源数据结构不同,对企业资产管理运营管理运维管理都带来了巨大的不便。现如今数字经济高速发展,兼具基础设施投资成本低、资源扩展速度快、数据安全高可控的混合云架构,成为了政府单位及中大型传统行业的首选。但多云架构混合云方案在带来成本、效率、安全等优势的同时,由于IT资源分散在不同的架构中,也带来了混合架构...

    Tecode 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<