最近在嘗試使用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

解決方案對比

下圖是3中dump發現方式的對比，

被動發現：這是上面案例中提到的情況，開發者在整個處理鏈條的末端，得知訊息最晚，在工作上十分被動。

主動檢查報表：即手工檢視ST22報表，需要一定的手工處理量，且如上所述，存在一些缺點。

使用Splunk：全自動的告警，且能提供一些SAP較難提供的高階功能。

()

結論

意義

使用Splunk對Dump資訊進行監控，相對於舊有的工作模式，可以減少開發者的勞動量，幫助開發者更快地發現生產系統中的問題，從而減小問題帶來的負面影響。此外，它也提供了持久化資料和強大的分析能力，為ABAP開發者持續地分析和改善系統中的不健康程式提供了基礎。

存在的問題

• 資料不一致問題：從Splunk中搜索到的結果有時會缺少某些條目，這可能是因為搜尋在某個節點失敗引起的，也可能是資料同步過程存在問題。如果存在統計型別的告警，那這種問題可能會帶來誤報、漏報現象。
• 併發搜尋數量問題：為了保證效能，Splunk會限制併發搜尋的數量。如果某段時間的搜尋數量達到了限制的最大值，那麼告警的搜尋可能會被取消，導致告警無法正常執行。