由於公司目前有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
從整體上來講,在進行演示和討論的時候,大家普遍認為,skywalking的界面比較現代化一些,pinpoint的功能更為強大;
其他一些方面提出的問題,待近期補充:
后邊需要繼續調研的點:
1.對公司現有技術棧,兩種方案的支持情況;
2.擴展性及如何進行擴展,擴展之后可以做哪些內容;
3.采樣率如何配置
4.保存時間
5.采樣的策略
6.agent開發方法
7.數據是否有遵循標准
8.nginx是否支持
另外,再討論的過程中,提到了一些問題,
有同事提出是否可以用這個工具定位線上的具體都某一次請求的問題?
答案是否定的,因為全鏈路追蹤的定位是展示整體服務調用的拓撲圖,能夠從宏觀描述服務請求鏈路中哪個環節比較慢,給開發者提供優化程序的一個方向;
對於性能消耗,大家也有一些不同的看法,有的業務方,對於20%的性能損耗是不敏感的,但是對於當前線上已經負載比較高,且經常有線上問題的系統,還需要性能消耗方面的調研;
————————————————
版權聲明：本文為CSDN博主「匆匆z2」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lo085213/article/details/94287469