skywalking與pinpoint全鏈路追蹤方案對比
由於公司目前有200多微服務,微服務之間的呼叫關係錯綜複雜,呼叫關係人工維護基本不可能實現,需要調研一套全鏈路追蹤方案,初步調研之後選取了skywalking和pinpoint進行對比;
選取skywalking和pinpoint對比的原因是:兩者都使用探針(agent)技術進行資訊採集,整合到專案內時不用修改業務程式碼,避免造成後期難以推進的問題;
以下是進行的一些維度的對比,主要從功能性需求和非功能性需求方面做參考:
功能性需求對比
skywalking pinpoint 備註
支援協議
Java, C#, PHP, Node.js
java,php
ui
兩種ui相類似,sw服務資訊載入速度會快一些
擴充套件性
都可自定義plugin,使用探針,都可以進行擴充套件,據說sk擴充套件性更好
儲存
支援各種型別儲存,es,mysql,h2等
只支援hbase
警告
config/alarm-settings.xml設定警告規則
需要額外引入mysql傳送警告
jvm監控
都包含,pinpoint相對更全面一些,從頁面檢視比較類似
跟蹤粒度
需要使用對應的外掛,可以到方法級,展示sql,每個方法呼叫的時間
服務監控
skywalking支援的維度有:CPU使用率,SLA,RT,CPM(Call Per Minutes)
Pinpoint支援的維度有:CPU使用率,Open File Descriptor,資料來源,活動執行緒數,RT,TPS。
pinpoint更多
過濾追蹤
都是用ant風格,sw有對應的外掛,更靈活
效能損耗
效能損耗sw少於pinpoint
支援中介軟體
1.支援開源web容器
2.RPC框架支援更多
3.mq,多支援rocketMQ
4.不支援mssql和mariadb
5.redis支援Jedis,Redisson,Lettuce
1.支援幾乎所有web容器,
2.少於sw
4.RDBMS/nosql,好於sw
5.不支援redisson
6.不支援log4j2
公司當前使用的resin
和karaf容器兩個是否支援
對程式碼的侵入性
無侵入
非功能性需求對比
skywalking
pinpoint
是否需要修改程式碼
不需要
相關文件
官網文件比較全,支援中文,apache支援
英文文件
社群
社群活躍,發起人是華人
南韓人開發,活躍程度類似
釋出方式
使用jar包,start.sh指令碼啟動
使用war包,依賴web容器
github start 數 9.1k 8.8k
skywalking對中國產軟體的支援好於Pinpoint;
Pinpoint的優勢在於:追蹤資料粒度非常細、功能強大的使用者介面,以及使用HBase作為儲存帶來的海量儲存能力。
skywalking的優勢在於:非常活躍的中文社群,支援多種語言的探針,對中國產開源軟體非常全面的支援,以及使用es作為底層儲存帶來的強大的檢索能力,並且skywalking的擴充套件性以及定製化要更優於Pinpoint
其他一些方面提出的問題,待近期補充:
後邊需要繼續調研的點:
1.對公司現有技術棧,兩種方案的支援情況;
2.擴充套件性及如何進行擴充套件,擴充套件之後可以做哪些內容;
3.取樣率如何配置
4.儲存時間
5.取樣的策略
6.agent開發方法
7.資料是否有遵循標準
8.nginx是否支援
有同事提出是否可以用這個工具定位線上的具體都某一次請求的問題?
答案是否定的,因為全鏈路追蹤的定位是展示整體服務呼叫的拓撲圖,能夠從宏觀描述服務請求鏈路中哪個環節比較慢,給開發者提供最佳化程式的一個方向;
對於效能消耗,大家也有一些不同的看法,有的業務方,對於20%的效能損耗是不敏感的,但是對於當前線上已經負載比較高,且經常有線上問題的系統,還需要效能消耗方面的調研;
skywalking與pinpoint全鏈路追蹤方案對比
由於公司目前有200多微服務,微服務之間的呼叫關係錯綜複雜,呼叫關係人工維護基本不可能實現,需要調研一套全鏈路追蹤方案,初步調研之後選取了skywalking和pinpoint進行對比;
選取skywalking和pinpoint對比的原因是:兩者都使用探針(agent)技術進行資訊採集,整合到專案內時不用修改業務程式碼,避免造成後期難以推進的問題;
以下是進行的一些維度的對比,主要從功能性需求和非功能性需求方面做參考:
功能性需求對比
skywalking pinpoint 備註
支援協議
Java, C#, PHP, Node.js
java,php
ui
兩種ui相類似,sw服務資訊載入速度會快一些
擴充套件性
都可自定義plugin,使用探針,都可以進行擴充套件,據說sk擴充套件性更好
儲存
支援各種型別儲存,es,mysql,h2等
只支援hbase
警告
config/alarm-settings.xml設定警告規則
需要額外引入mysql傳送警告
jvm監控
都包含,pinpoint相對更全面一些,從頁面檢視比較類似
跟蹤粒度
需要使用對應的外掛,可以到方法級,展示sql,每個方法呼叫的時間
服務監控
skywalking支援的維度有:CPU使用率,SLA,RT,CPM(Call Per Minutes)
Pinpoint支援的維度有:CPU使用率,Open File Descriptor,資料來源,活動執行緒數,RT,TPS。
pinpoint更多
過濾追蹤
都是用ant風格,sw有對應的外掛,更靈活
效能損耗
效能損耗sw少於pinpoint
支援中介軟體
1.支援開源web容器
2.RPC框架支援更多
3.mq,多支援rocketMQ
4.不支援mssql和mariadb
5.redis支援Jedis,Redisson,Lettuce
1.支援幾乎所有web容器,
2.少於sw
4.RDBMS/nosql,好於sw
5.不支援redisson
6.不支援log4j2
公司當前使用的resin
和karaf容器兩個是否支援
對程式碼的侵入性
無侵入
無侵入
非功能性需求對比
skywalking
pinpoint
是否需要修改程式碼
不需要
不需要
相關文件
官網文件比較全,支援中文,apache支援
英文文件
社群
社群活躍,發起人是華人
南韓人開發,活躍程度類似
釋出方式
使用jar包,start.sh指令碼啟動
使用war包,依賴web容器
github start 數 9.1k 8.8k
skywalking對中國產軟體的支援好於Pinpoint;
Pinpoint的優勢在於:追蹤資料粒度非常細、功能強大的使用者介面,以及使用HBase作為儲存帶來的海量儲存能力。
skywalking的優勢在於:非常活躍的中文社群,支援多種語言的探針,對中國產開源軟體非常全面的支援,以及使用es作為底層儲存帶來的強大的檢索能力,並且skywalking的擴充套件性以及定製化要更優於Pinpoint
其他一些方面提出的問題,待近期補充:
後邊需要繼續調研的點:
1.對公司現有技術棧,兩種方案的支援情況;
2.擴充套件性及如何進行擴充套件,擴充套件之後可以做哪些內容;
3.取樣率如何配置
4.儲存時間
5.取樣的策略
6.agent開發方法
7.資料是否有遵循標準
8.nginx是否支援
有同事提出是否可以用這個工具定位線上的具體都某一次請求的問題?
答案是否定的,因為全鏈路追蹤的定位是展示整體服務呼叫的拓撲圖,能夠從宏觀描述服務請求鏈路中哪個環節比較慢,給開發者提供最佳化程式的一個方向;
對於效能消耗,大家也有一些不同的看法,有的業務方,對於20%的效能損耗是不敏感的,但是對於當前線上已經負載比較高,且經常有線上問題的系統,還需要效能消耗方面的調研;