使用Splunk监控SAP Dump

最近在尝试使用Splunk对SAP系统进行监控，以Dump监控为例，总结了一点相关信息，记录在这里。

本文链接：https://www.cnblogs.com/hhelibeb/p/13260385.html

转载请注明

Dump

定义

运行期错误（Runtime error）：SAP ABAP程序在运行过程中会因为一些不同的原因而终止。(比如内部内核错误、ABAP编程错误、资源瓶颈等）。

如果在执行ABAP程序时发生运行时错误，则会创建一个错误日志（Short Dump）。错误日志包含很多结构化和非结构化的信息，可以帮助开发者分析原因、寻找解决方案。

存储在系统中的错误日志在一段时间后（最长28天）被删除。

也就是说，我们通常所说的Dump，准确地说是一种日志，它是由运行期错误产生的。

表现

在不同的环境，Dump可能有不同的表现，我们最熟悉的大概是SAP GUI的红色消息：

此外还有WEB UI的HTTP 500等，

问题案例

Dump的直接影响是让程序中断，这无疑会给用户带来麻烦。下面用一个故事来介绍它可能带来的危害。

有一个主数据批处理更新程序，它可以基于用户上传的数据在后台执行更新。该程序会通过电子邮件将更新状态发送给用户。
某一天，用户上传了一些数据，该程序在后台运行时Dump。因此该程序被终止，没有电子邮件发送给用户。用户没有注意到他没有收到电子邮件，并认为数据已正确更新。
一周后，在后续业务流程中，用户发现数据不是最新的，导致自己的业务流程被迫中断。他提了工单，并表示不满：“我可以接受该程序偶尔会失败，但是我需要及时获得反馈，以便让我知道结果是什么。”
然后，客服人员将问题转发给开发人员，开发人员开始进行调查程序问题。而中断的业务流程也必须等待数据更新后才能重启。

这个故事体现了一个常见的道理：在事故中，问题被发现的越晚，产生的后果就越严重。

它也体现了信息价值会随时间而衰减的现象：当dump出现时，用户和IT支持人员都没有及时得知事件的发生。随着时间的推进，dump对业务的影响已经产生，此时，开发人员才得知这个事件，实际上已经太晚了。

解决方案

1，手工查看ST22报表

开发者可以定期查看SAP提供的标准报表，事务ST22来识别问题，界面如下图。

ST22的优点是，

信息十分全面

缺点，

需要手工查看。
需要定期查看。生产系统一般有登录时间限制，长时间不操作的话会自动退出，这意味着可能要经常登陆系统，很麻烦。
日志会定期删除。很多系统只保留1~2天的记录，这会导致开发者无法追踪一些过去的问题。

2，通过Splunk监控

将数据定期发送至Splunk系统，配置相应告警，这样一旦指定的dump发生，开发者就可以第一时间收到邮件/工单，了解到事件的发生并进行跟踪分析。

优点是，

可以自定义各种触发条件
可以自定义触发后行为（发邮件，创建工单，运行脚本，记录日志等）
数据是持久化的
支持全文搜索
支持使用SPL（Search Processing Language）进行分析

缺点，

需要流量付费，因此可能不会把太多详细信息发送到Splunk

解决方案对比

下图是3中dump发现方式的对比，

被动发现：这是上面案例中提到的情况，开发者在整个处理链条的末端，得知消息最晚，在工作上十分被动。

主动检查报表：即手工查看ST22报表，需要一定的手工处理量，且如上所述，存在一些缺点。

使用Splunk：全自动的告警，且能提供一些SAP较难提供的高级功能。

()

结论

意义

使用Splunk对Dump信息进行监控，相对于旧有的工作模式，可以减少开发者的劳动量，帮助开发者更快地发现生产系统中的问题，从而减小问题带来的负面影响。此外，它也提供了持久化数据和强大的分析能力，为ABAP开发者持续地分析和改善系统中的不健康程序提供了基础。

存在的问题

尽管我们对Splunk的应用取得了一定的成果，但同时也遇到了一些问题，正在分析和解决，包括，

数据不一致问题：从Splunk中搜索到的结果有时会缺少某些条目，这可能是因为搜索在某个节点失败引起的，也可能是数据同步过程存在问题。如果存在统计类型的告警，那这种问题可能会带来误报、漏报现象。
并发搜索数量问题：为了保证性能，Splunk会限制并发搜索的数量。如果某段时间的搜索数量达到了限制的最大值，那么告警的搜索可能会被取消，导致告警无法正常运行。

参考：ABAP Runtime Errors and Short Dumps