最近在尝试使用Splunk对SAP系统进行监控,以Dump监控为例,总结了一点相关信息,记录在这里。html
本文连接:http://www.javashuo.com/article/p-dervtwpt-mk.html编程
转载请注明并发
运行期错误(Runtime error):SAP ABAP程序在运行过程当中会由于一些不一样的缘由而终止。(好比内部内核错误、ABAP编程错误、资源瓶颈等)。性能
若是在执行ABAP程序时发生运行时错误,则会建立一个错误日志(Short Dump)。错误日志包含不少结构化和非结构化的信息,能够帮助开发者分析缘由、寻找解决方案。spa
存储在系统中的错误日志在一段时间后(最长28天)被删除。3d
也就是说,咱们一般所说的Dump,准确地说是一种日志,它是由运行期错误产生的。日志
在不一样的环境,Dump可能有不一样的表现,咱们最熟悉的大概是SAP GUI的红色消息:htm
此外还有WEB UI的HTTP 500等,blog
Dump的直接影响是让程序中断,这无疑会给用户带来麻烦。下面用一个故事来介绍它可能带来的危害。事件
有一个主数据批处理更新程序,它能够基于用户上传的数据在后台执行更新。 该程序会经过电子邮件将更新状态发送给用户。
某一天,用户上传了一些数据,该程序在后台运行时Dump。 所以该程序被终止,没有电子邮件发送给用户。 用户没有注意到他没有收到电子邮件,并认为数据已正确更新。
一周后,在后续业务流程中,用户发现数据不是最新的,致使本身的业务流程被迫中断。 他提了工单,并表示不满:“我能够接受该程序偶尔会失败,可是我须要及时得到反馈,以便让我知道结果是什么。”
而后,客服人员将问题转发给开发人员,开发人员开始进行调查程序问题。而中断的业务流程也必须等待数据更新后才能重启。
开发者能够按期查看SAP提供的标准报表,事务ST22来识别问题,界面以下图。
ST22的优势是,
缺点,
将数据按期发送至Splunk系统,配置相应告警,这样一旦指定的dump发生,开发者就能够第一时间收到邮件/工单,了解到事件的发生并进行跟踪分析。
优势是,
缺点,
(此外,其实也可使用SAP的JOB功能设定DUMP信息定时发送邮件,可是相比Splunk来讲缺乏不少功能)
下图是3中dump发现方式的对比,
被动发现:这是上面案例中提到的状况,开发者在整个处理链条的末端,得知消息最晚,在工做上十分被动。
主动检查报表:即手工查看ST22报表,须要必定的手工处理量,且如上所述,存在一些缺点。
使用Splunk:全自动的告警,且能提供一些SAP较难实现的高级功能。
使用Splunk对Dump信息进行监控,相对于旧有的工做模式,能够减小开发者的劳动量,帮助开发者更快地发现生产系统中的问题,从而减少问题带来的负面影响。此外,它也提供了持久化数据和强大的分析能力,为ABAP开发者持续地分析和改善系统中的不健康程序提供了基础。