今天準備談下ESB總線平台建設項目中的服務運作統計分析，服務心跳監測，服務監控預警方面的設計和實作。可以看到，在一個ESB服務總線平台上線後，SOA治理管控就變得相當重要，而這些運作監控分析本身也是提升ESB總線平台高可用性的關鍵。
對于ESB總線本身的高可用性建設，我在前面寫過一篇文章可以參考。
大型集團ESB服務總線平台建設項目高可用性實踐總結
今天主要分享下對于這類大型ESB總線平台建設項目在服務運作統計分析，服務心跳監測，服務監控，服務預警等配合高可用性能力方面的一些實踐總結。
對接口服務運作統計分析的思考
對于ESB服務運作監控，從SOA服務管控和治理層面來看，經常會涉及到的KPI性能名額并不多，主要還是展現在運作次數，運作時間等關鍵的次元，如果考慮到名額本身之間的關聯關系友善分析，那麼還需要增加服務運作的并發數(分鐘級)，服務調用的資料量等關鍵名額。
舉例來說，當我們發現服務調用變慢了，即服務運作時間明顯增加了，那麼我們需要分析是否是該服務本身的并發量是否增加了，還是說服務本身調用的資料量增加了，還是說其它服務調用的并發量和資料量增加了導緻該服務的資源被占用等。這些都是可能需要涉及到關聯分析的地方。
首先我們來看下單次服務運作能夠采集和記錄的關鍵資料
- 服務運作時間(服務請求開始 to 服務請求結束)
- 服務運作是否成功(True or False)
- 服務傳輸的消息封包大小
- 服務名稱
- 服務提供的系統，包括服務提供系統歸屬的組織類别等
- 服務消費方系統
- 正常調用還是非法調用
接着再來看某個時間周期的情況，比如1個小時，1天，1周或1個月的統計時間周期
- 運作次數，對運作次數進行求和
- 最大分鐘級并發數，取并發數的Max值
- 異常數，對異常數按時間點進行求和
- 告警數，對告警數按時間點進行求和
- 服務最大運作時間，最小運作時間，平均運作時間
- 服務消息封包最大封包，最小封包，平均封包容量
對于時間周期隻我們我們統計的一個次元，而對服務進行分析的時候還需要考慮如下次元
- 按服務目錄-》按服務
- 按企業-》子公司-》子組織
- 按應用域-》按應用系統-》按子產品
- 按服務類型-》服務子類型
- 按服務提供系統，服務消費系統
經過以上分析，我們看到一個最底層的服務運作日志資訊，就有了按時間次元，按組織，服務類型，系統等多個次元進行次元分析和統計的可能。而這些恰好又是我們進行自定義報表和次元分析的基礎。所有的統計分析基本都會基于以上基礎運作資訊展開進行。
基于以上思考，我們整合了一個面向組織和業務系統的服務運作統計分析報表，可以按系統的次元詳細的檢視到自己提供和消費的接口服務的運作情況，異常情況，并發量和資料量，異常和告警等各種關鍵資訊。如下參考：
為了做完整的服務運作和性能分析，我們最好還需要對中間件資源池(應用伺服器和資料庫伺服器)的CPU，記憶體使用率，存儲使用量等關鍵名額進行實時的性能分析和監控。在實際的性能分析和監控中往往也是首先會從CPU和記憶體告警上第一時間反應出服務目前運作出現異常(如大并發，超大資料傳輸等)，然後我們在通過實際的日志監控分析功能快速的檢視目前服務運作的并發情況，傳遞的資料量情況等。
當我們發現如果一個服務經常運作大并發，大資料量的異常調用的時候，則需要對服務單獨啟用流量控制政策等。比如：
- 對服務傳輸的資料量及封包大小進行流控。
- 對服務本身的并發量進行流控。
- 對某個服務最大能夠使用的資源量進行流控，防止單服務占滿所有資源。
服務運作名額勾稽關系分析
服務運作名額相關之間的關聯分析是我們進行服務運作問題排查，異常告警問題根源分析的基礎。在前面談SOA治理管控平台中，我們曾經畫過一個圖來說明，服務運作過程中的基礎實體資源，資料庫和應用伺服器中間件資源，服務運作KPI和SLA設定之間的關聯關系，如下：
基于上圖，我們進一步做下擴充分析，先做下基本的關聯關系判别：
JVM記憶體持續增加不釋放，一個是服務并發量增加同時服務調用時間增長，其次是出現大資料量，長執行時間的服務調用，導緻服務連接配接和記憶體無法快速回收。CPU使用率高升，但是記憶體使用率一般，一般為出現大并發量的服務調用，其次對于服務調用過程中有過多的資料映射，轉換等處理導緻CPU使用率增加。
服務調用運作時間長，首先要分析是否是原始服務本身調用時間就變長，如果不是，則一般是在ESB服務調用上出現大量長周期服務調用，但是連接配接不能快速是否，線程池滿一直排隊的情況。
如果JVM記憶體溢出，首先要通過Jstat工具監控下記憶體GC回收的情況，究竟是新時代，老生代，還是PermSize出現溢出。如果是PermSize需要進一步分析是否是程式本身有問題。
如果沒有做流量控制，單個服務本身的大并發，大資料量調用往往會侵占所有資源，對整個ESB上其它運作的服務都造成性能影響。
對于ESB總線本身的等待線程數增加一定會涉及到記憶體持續增加，涉及到服務調用響應周期增加。如果是服務調用逾時，則需要分析具體是在哪段引起的逾時，是原始服務本身逾時，還是在ESB中間件上進行服務處理的時候逾時。
對于服務告警和預警，前面也講到過，再強調下具體場景包括
- 服務機關時間運作次數明顯增加，我們可以設定一個門檻值，隻要超過了就進行報警。
- 服務運作時間明顯增加，我們可以設定一個門檻值，隻要超過了就進行報警。
- 服務機關時間資料量明顯增加，我們可以設定一個門檻值，隻要超過了就進行報警。
注意對于服務告警政策可以是針對所有服務，也可以是針對某個具體的服務，對于門檻值可以是一個百分比數，也可以是一個絕對值。接下來我們再看下服務運作各個名額本身之間的一些關聯關系：
- 服務傳遞資料量大，一定帶來記憶體增加
- 服務運作時長增加，同時更加容易引起服務調用逾時。
- 服務調用并發量增加，服務調用時長一般也會增加，如果時長增加明顯，則一定導緻記憶體持續增加。單個服務本身的并發量增加，會引起ESB上線程排隊增加，導緻直接影響到其它服務調用性能。
- 單個服務調用本身的資料量增加，容易引起JVM記憶體持續增加，導緻JVM記憶體溢出。
- 如果是後端服務本身性能下降，最明顯的就是占有連接配接，資源不釋放，導緻ESB本身性能下降。
而對于整個ESB中間件的性能監控和分析，從最底層的IT基礎設施，存儲和伺服器，到ESB中間件資源池，再到具體運作的服務運作包，互相之間存在密切的關聯，需要達到的效果往往是第一時間回報出預警。并且通過預警去采取後續的行動措施和SLA政策設定等。
1. 從資源池監控發現的CPU和記憶體異常第一時間找到非法調用服務？
如果有CPU和記憶體使用率出現異常，同時某個服務或某幾個服務出現運作性能告警，那麼我們就有了分析的依據究竟是哪個服務導緻的。并快速定位到具體的服務。在定位到具體的服務後，可以再詳細檢視服務調用的并發數，資料量等資訊，然後有針對性的對服務展開流量控制政策。
2. 如果JVM記憶體持續上升而沒有釋放，如何快速定位到服務？
這個也是經常遇到的問題，當JVM記憶體持續增加，或者連接配接數不斷的增加而不釋放的時候，如果我們不進行及時的處理往往就導緻整個JVM記憶體溢出而影響到所有ESB服務的運作。是以在這種場景下我們需要盡快的發現導緻問題的服務，并對服務采取相應的措施。
3. 從服務運作告警到自動熔斷
為了不因為一個具體服務的異常非法調用而影響到所有服務的運作，對于單個服務在出現持續性的告警後，應該有政策直接對該服務進行熔斷處理。比如直接對服務進行禁用處理。
增加實時的心跳檢查
在前面部分已經詳細分析了服務本身的運作并發，次數和資料量與JVM記憶體，與CPU和記憶體使用率等各個關鍵名額之間的勾稽關系。
這些名額之間本身互相影響和作用，我們對名額的監控本身應該是風險驅動的，即在系統出現當機或記憶體溢出等故障問題前快速的發現問題并進行處理。
是以，我們就需要對各種關鍵名額進行心跳監控和實時預警。
對JVM記憶體使用率進行監控
在前面我們已經談到了，實際上出現JVM溢出的時候，往往會由于請求漂移影響到整個叢集大量節點記憶體溢出而導緻叢集不可用。
是以需要時刻監控JVM記憶體使用率的情況，如果發現JVM記憶體持續在某個高位，無法通過Gc操作将記憶體回收下來的時候就應該實時進行預警。
在預警後我們既可以進行人工處理，也可以設定政策直接對問題節點進行重新開機操作。
如上，我們對所有叢集節點的JVM記憶體使用率進行實時監控，當發現使用率持續大于70%的時候就進行相應的預警操作，如果超過80%就推送嚴重警告資訊。
對後端業務系統和服務本身可用性監控
其次，ESB服務總線如果出現服務調用異常，除了ESB總線本身的異常故障外，更大的可能性是後端業務系統不可用，或者說後端業務系統提供的業務服務不可用導緻。
對于ESB總線本身，我們可以實時心跳檢查ESB總線暴露的服務可用性，如下：
如果是後端系統本身不可用，那麼往往會快速的傳回connection timeout異常資訊，這樣不會影響到整個ESB總線平台穩定性。但是如果是後端業務系統服務假死或處于長時間無響應的狀态，那麼就會導緻大量的連接配接無法釋放，最終導緻資源被消耗完。
是以對後端系統和後端服務進行實時心跳監控也是有必要的。
不論是對于ESB叢集還是後端業務系統的監控，實際上都包括兩個方面的監控，一個我們叫技術聯通性監控，一個叫業務聯通性監控。
技術連通性即是否出現conneciton timeout通路逾時，是就傳回異常。而對于業務聯通性，則是調用真實的某個業務服務接口，如果出現read time out則傳回業務連通失敗錯誤。
對服務運作進行實時心跳監控
其次，我們還需要對服務運作進行實時心跳監控，即時刻監控服務運作的并發量，資料量，運作時長等幾個關鍵資料名額。
在前面已經談到過以上幾個名額本身存在勾稽關系，比如發現服務運作平均時長增加，那麼很可能是服務并發量增加或調用資料量增加導緻。其次，如果發現服務調用的消息封包資料量猛增，那麼很可能導緻服務運作時長增加。
是以需要對以上幾個關鍵名額進行實時監控，時刻監控是否發生了峰值突變情況。
當發現了峰值或突變的時候，我們就需要進行預警，并分析發生大并發或大資料量調用的原因并及時采取相應的流量管控措施，以確定整個ESB平台的穩定性。
通過監控大屏可視化實時監控
監控大屏更多的是展示基于服務內建層面的總覽資料，同時對關鍵的異常告警資訊，關鍵名額心跳，關鍵名額排名資訊進行展示。這些都應該在Level1級層面的視圖或報表。
我們舉一個簡單場景，一個企業實施了ESB總線後，內建了20個業務系統，上100個服務接口，每天大概産生100萬條服務調用示例記錄，高峰時期的分鐘級并發在1萬次左右。
總線實際上和硬體類網關很類似，當所有的服務調用全部都有經過總線的時候，我們就更加關心總線上實際的實時并發量，資料流量大小資料。而且這兩個資料最好是要實作準實時的監控。以分鐘級為例，我們需要監控分鐘級的服務調用次數，分鐘級的服務調用傳輸資料量。
監控着兩個名額是否出現突然的峰值調用，如果沒有一般來說總線運作本身也不好出現問題。如果出現了各種異常大并發，大資料量調用，則一定會展現到我們的監控時序圖上面。這兩個資料實際上是适合在大屏上面實時心跳檢測并顯示的。
對于大屏可視化展示，我們可以了解為總覽，即更多的是目前ESB總線服務，內建的業務系統的總體健康情況。是以在大屏上我們可以考慮對當天的一些統計資料進行統計展示。
這些統計資料包括了服務調用總次數，平均時長，總資料量，平均資料量，分鐘級最大并發，接入總系統數，接入總服務數，總異常數，總告警次數等。對于異常告警往往是一個比較重要的展示内容，特别是異常資訊本身還分為了系統級的異常和業務級的異常，對于告警本身又分為嚴重，一般，輕微等各種級别的告警。這些都需要在大屏進行一個統計的展示。
如果是做集團到省兩級ESB總線實施，在大屏上我們就可以考慮來實作結合地圖的可視化效果展示。這個前面有文章說過，可以通過連線，端點節點大小，顔色等來展現服務調用流量，狀态等資訊。
即使是單級ESB總線，在大屏展示的時候我們也需要考慮是否能夠展示一個內建架構視圖，能夠展示出目前總線內建的多個業務系統，類似Bus總線的展示方式，可以通過該圖将內建的關鍵系統全部标注出來。同時對于內建的系統上本身可以顯示更多的關鍵資訊。
如果內建的業務系統用一個方框進行展示，那麼在方框裡面可以考慮展示。
- 方框的顔色用于展示目前提供服務的本身的異常和告警情況
- 方框内可以顯示提供服務數和消費服務數
- 方框内可以顯示服務當天的服務提供總次數，峰值并發量
最後，大屏本身也可以展示一些清單資料，但是從大屏可視化效果來說，清單資料不适合展示太多。可以考慮的清單資料展示主要包括了服務運作次數，服務調用異常，服務調用耗時或資料量的Top10排名資訊顯示等。