最近在嘗試使用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開發者持續地分析和改善系統中的不健康程序提供了基礎。