使用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。 因此该程序被终止，没有电子邮件发送给用户。 用户没有注意到他没有收到电子邮件，并认为数据已正确更新。
一周后，在后续业务流程中，用户发现数据不是最新的，导致自己的业务流程被迫中断。 他提了工单，并表示不满：“我可以接受该程序偶尔会失败，但是我需要及时获得反馈，以便让我知道结果是什么。”
然后，客服人员将问题转发给开发人员，开发人员开始进行调查程序问题。而中断的业务流程也必须等待数据更新后才能重启。
解决方案
1，手工查看ST22报表
开发者可以定期查看SAP提供的标准报表，事务ST22来识别问题，界面如下图。
ST22的优点是，
- 信息十分全面
缺点，
- 需要手工查看。
- 需要定期查看。生产系统一般有登录时间限制，长时间不操作的话会自动退出，这意味着可能要经常登陆系统，很麻烦。
- 日志会定期删除。很多系统只保留1~2天的记录，这会导致开发者无法追踪一些过去的问题。
2，通过Splunk监控
将数据定期发送至Splunk系统，配置相应告警，这样一旦指定的dump发生，开发者就可以第一时间收到邮件/工单，了解到事件的发生并进行跟踪分析。
优点是，
- 可以自定义各种触发条件
- 可以自定义触发后行为（发邮件，创建工单，运行脚本，记录日志等）
- 数据是持久化的
- 支持全文搜索
- 支持使用SPL（Search Processing Language）进行分析
缺点，
- 需要流量付费，因此可能不会把太多详细信息发送到Splunk
（此外，其实也可以使用SAP的JOB功能设定DUMP信息定时发送邮件，但是相比Splunk来说缺少很多功能）
解决方案对比
下图是3中dump发现方式的对比，
被动发现：这是上面案例中提到的情况，开发者在整个处理链条的末端，得知消息最晚，在工作上十分被动。
主动检查报表：即手工查看ST22报表，需要一定的手工处理量，且如上所述，存在一些缺点。
使用Splunk：全自动的告警，且能提供一些SAP较难实现的高级功能。
结论
意义
使用Splunk对Dump信息进行监控，相对于旧有的工作模式，可以减少开发者的劳动量，帮助开发者更快地发现生产系统中的问题，从而减小问题带来的负面影响。此外，它也提供了持久化数据和强大的分析能力，为ABAP开发者持续地分析和改善系统中的不健康程序提供了基础。
存在的问题
- 数据不一致问题：从Splunk中搜索到的结果有时会缺少某些条目，这可能是因为搜索在某个节点失败引起的，也可能是数据同步过程存在问题。如果存在统计类型的告警，那这种问题可能会带来误报、漏报现象。
- 并发搜索数量问题：为了保证性能，Splunk会限制并发搜索的数量。如果某段时间的搜索数量达到了限制的最大值，那么告警的搜索可能会被取消，导致告警无法正常运行。
