最近在嘗試使用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會限制並發搜索的數量。如果某段時間的搜索數量達到了限制的最大值，那么告警的搜索可能會被取消，導致告警無法正常運行。