• 社群比較
• 支援語言比較
• 協議比較
• 儲存比較(重要)
• UI比較
• 擴充套件性比較
• 告警比較
• JVM監控
• 服務監控
• 跟蹤粒度比較
• 過濾追蹤
• 效能損耗
• 釋出包比較
• 支援元件比較
• 總結
• 參考連結

---

說明：本次對比基於skywalking-6.0.0-GA和Pinpoint-1.8.2（截止2019-02-19最新版本）。另外，我們這次技術選型直接否定了Zipkin，其最大原因是它對程式碼有侵入性，CAT也是一樣。這是我們所完全無法接受的。

這應該是目前最優秀的兩款開源APM產品了，而且兩款產品都透過位元組碼註入的方式，實現了對程式碼完全無任何侵入，他們的對比資訊如下：

OAP說明: skywalking6.x才有OAP這個概念，skywalking5.x叫collector。

接下來，對每個PK項進行深入分析和對比。

先來偷偷的做一個問卷調查，方便我們互相瞭解大家對 APM & 鏈路追蹤這塊的選型。

社群比較

這一點上面skywalking肯定完勝。一方面，skywalking已經進入apache孵化，社群相當活躍。而且專案發起人是中國人，我們能夠進入官方群（Apache SkyWalking交流群：392443393）和專案發起人吳晟零距離溝通，很多問題能第一時間得到大家的幫助（玩過開源的都知道，這個價值有多大）。
而Pinpoint是韓國人開發的，免不了有溝通障礙。至於github上最近一年的commit頻率，skywalking和Pinpoint旗鼓相當，都是接近20的水平:

所以，社群方面，skywalking更勝一籌。

支援語言比較

Pinpoint只支援Java和PHP，而skywalking支援4種語言：Java, C#, PHP, Node.js。如果公司的服務涉及到多個開發語言，那麼skywalking會是你更好的選擇。並且，如果你要實現自己的探針（比如Go語言），skywalking的二次開發成本也比Pinpoint更低。

說明：Github上有開發者為Pinpoint貢獻了對Node.js的支援，請戳連結：https://github.com/peaksnail/pinpoint-node-agent。但是已經停止維護，幾年沒更新了！

所以，支援語言方面，skywalking更勝一籌。

協議比較

SkyWalking支援gRPC和http，不過建議使用gRPC，skywalking6.x版本已經不提供http方式（但是還會保留接收5.x的資料），以後會考慮刪除。
而Pinpoint使用的是thrift協議。
協議本身沒有誰好誰壞。

儲存比較(重要)

筆者認為，儲存是skywalking和Pinpoint最大的差異所在，因為底層儲存決定了上層功能。
Pinpoint只支援HBase，且擴充套件代價較大。這就意味著，如果選擇Pinpoint，還要有能力hold住一套HBase叢集（daocloud從Pinpoint切換到skywalking就是因為HBase的維護代價有點大）。在這方面，skywalking支援的儲存就多很多，這樣的話，技術選型時可以根據團隊技術特點選擇合適的儲存，而且還可以自行擴充套件（不過生產環境上應該大部分是以es儲存為主）。
Pinpoint只支援HBase的另一個缺陷就是，HBase本身查詢能力有限（HBase只能支援三種方式查詢：RowKey精確查詢，SCAN範圍查詢，全表掃描）限制了Pinpoint的查詢能力，所以其支援的查詢一定是在時間的基礎上（Pinpoint透過滑鼠圈定一個時間範圍後檢視這個範圍內的Trace資訊）。而skywalking可以多個維度任意組合查詢，例如：時間範圍，服務名，Trace狀態，請求路徑，TraceId等。

另外，Pinpoint和skywalking都支援TTL，即歷史資料保留策略。skywalking是在OAP模組的application.yml中配置從而指定保留時間。而Pinpoint是透過HBase的ttl功能實現，透過Pinpoint提供的hbase指令碼https://github.com/naver/pinpoint/blob/master/hbase/scripts/hbase-create.hbase可以看到：ApplicationTraceIndex配置了TTL => 5184000，SqlMetaData_Ver2配合了TTL => 15552000，單位是秒。

說明：es並不是完全碾壓HBase，es和HBase沒有絕對的好和壞。es強在檢索能力，儲存能力偏弱。HBase強在儲存能力，檢索能力偏弱。如果蒐集的日誌量非常龐大，那麼es儲存就比較吃力。同樣的，如果對檢索能力有一定的要求，那麼HBase肯定滿足不了你。所以，又到了根據你的業務和需求決定的時刻了，trade-off真是無所不在。

UI比較

Pinpoint的UI確實比skywalking稍微好些，尤其是服務的拓撲圖展示。不過daocloud根據Pinpoint的風格為skywalking定製了一款UI。請戳連結：https://github.com/TinyAllen/rocketbot，專案介紹是：rocketbot: A UI for Skywalking。截圖如下所示；

所以，只比較原生UI的話，Pinpoint更勝一籌。

擴充套件性比較

Pinpoint好像設計之初就沒有過多考慮擴充套件性，無論是底層的儲存，還是自定義探針實現等。而skywalking核心設計標的之一就是Pluggable，即可插拔。
以儲存為例，pinpoint完全沒有考慮擴充套件性，而skywalking如果要自定義實現一套儲存，只需要定義一個類實現介面org.apache.skywalking.oap.server.library.module.ModuleProvider，然後實現一些DAO即可。至於Pinpoint則完全沒有考慮過擴充套件底層儲存。
再以實現一個自己的探針為例（比如我要實現Go語言的探針），Pinpoint選擇thrift作為資料傳輸協議標準，而且為了節省資料傳輸大小，在傳遞常量的時候也儘量使用資料參考字典，傳遞一個數字而不是直接傳遞字串等等。這些最佳化也增加了系統的複雜度：包括使用 Thrift 介面的難度、UDP 資料傳輸的問題、以及資料常量字典的註冊問題等等。Pinpoint發展這麼年才支援Java和PHP，可見一斑。而skywalking的資料介面就標準很多，並且支援OpenTracing協議，除了官方支援Java以外，C#、PHP和Node.js的支援都是由社群開發並維護。
還有後面會提到的告警，skywalking的可擴充套件性也要遠好於Pinpoint。
最後，Pinpoint和skywalking都支援外掛開發，Pinpoint外掛開發參考：http://naver.github.io/pinpoint/1.8.2/plugindevguide.html。skywalking外掛開發參考：https://github.com/apache/incubator-skywalking/blob/master/docs/en/guides/Java-Plugin-Development-Guide.md。

所以，擴充套件性方面skywalking更勝一籌。

告警比較

Pinpoint和skywalking都支援自定義告警規則。

但是惱人的是，Pinpoint如果要配置告警規則，還需要安裝MySQL(配置告警時的使用者，使用者組資訊以及告警規則都持久化儲存在MySQL中)，這就導致Pinpoint的維護成本又高了一些，既要維護HBase又要維護MySQL。

Pinpoint支援的告警規則有：SLOW COUNT|RATE, ERROR COUNT|RATE, TOTAL COUNT, SLOW COUNT|RATE TO CALLEE, ERROR COUNT|RATE TO CALLEE, ERROR RATE TO CALLEE, HEAP USAGE RATE, JVM CPU USAGE RATE, DATASOURCE CONNECTION USAGE RATE。

Pinpoint每3分鐘週期性檢查過去5分鐘的資料，如果有符合規則的告警，就會傳送sms/email給使用者組下的所有使用者。需要說明的是，實現傳送sms/email的邏輯需要自己實現，Pinpoint只提供了介面com.navercorp.pinpoint.web.alarm.AlarmMessageSender。並且Pinpoint發現告警持續時，會遞增傳送sms/email的時間間隔 3min -> 6min -> 12min -> 24min，防止sms/email狂刷。

Pinpoint告警參考：http://naver.github.io/pinpoint/1.8.2/alarm.html

skywalking配置告警不需要引入任何其他儲存。skywalking在config/alarm-settings.xml中可以配置告警規則，告警規則支援自定義。

skywalking支援的告警規則（配置項中的名稱是indicator-name）有：service_resp_time, service_sla, service_cpm, service_p99, service_p95, service_p90, service_p75, service_p50, service_instance_sla, service_instance_resp_time, service_instance_cpm, endpoint_cpm, endpoint_avg, endpoint_sla, endpoint_p99, endpoint_p95, endpoint_p90, endpoint_p75, endpoint_p50。

Skywalking透過HttpClient的方式遠端呼叫在配置項webhooks中定義的告警通知服務地址。skywalking也支援silence-period配置，假設在TN這個時間點觸發了告警，那麼TN -> TN+period 這段時間內不會再重覆傳送該告警。

skywalking告警參考：https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/backend/backend-alarm.md。目前只支援official_analysis.oal指令碼中Service, Service Instance, Endpoint scope的metric，其他scope的metric需要等待後續擴充套件。

Pinpoint和skywalking都支援常用的告警規則配置，但是skywalking採用webhooks的方式就靈活很多：簡訊通知，郵件通知，微信通知都是可以支援的。而Pinpoint只能sms/email通知，並且還需要引入MySQL儲存，增加了整個系統複雜度。所以，告警方面，skywalking更勝一籌。

JVM監控

skywalking支援監控：Heap, Non-Heap, GC(YGC和FGC)。
Pinpoint能夠監控的指標主要有：Heap, Non-Heap, FGC, DirectBufferMemory, MappedBufferMemory，但是沒有YGC。另外，Pinpoint還支援多個指標同一時間點檢視的功能。如下圖所示：

所以，對JVM的監控方面，Pinpoint更勝一籌。

服務監控

包括作業系統，和部署的服務實體的監控。
Pinpoint支援的維度有：CPU使用率，Open File Descriptor，資料源，活動執行緒數，RT，TPS。
skywalking支援的維度有：CPU使用率，SLA，RT，CPM（Call Per Minutes）。
所以，這方面兩者旗鼓相當，沒有明顯的差距。

跟蹤粒度比較

Pinpoint在這方面做的非常好，跟蹤粒度非常細。如下圖所示，是Pinpoint對某個介面的trace資訊：

而同一個介面skywalking的trace資訊如下圖所示：

備註: 此截圖是skywalking載入了外掛apm-spring-annotation-plugin-6.0.0-GA.jar（這個外掛允許跟蹤加了@Bean, @Service, @Component and @Repository註解的spring context中的bean的方法）。

透過對比發現，在跟蹤粒度方面，Pinpoint更勝一籌。

過濾追蹤

Pinpoint和skywalking都可以實現，而且配置的運算式都是基於ant風格。
Pinpoint在Web UI上配置 filter wizard 即可自定義過濾追蹤。
skywalking透過載入apm-trace-ignore-plugin外掛就能自定義過濾跟蹤，skywalking這種方式更靈活，比如一臺高配伺服器上有若干個服務，在共用的agent配置檔案apm-trace-ignore-plugin.config中可以配置通用的過濾規則，然後透過-D的方式為每個服務配置個性化過濾。

所以，在過濾追蹤方面，skywalking更勝一籌。

效能損耗

由於Pinpoint採集資訊太過詳細，所以，它對效能的損耗最大。而skywalking預設策略比較保守，對效能損耗很小。
有網友做過壓力測試，對比如下：

圖片來源於：https://juejin.im/post/5a7a9e0af265da4e914b46f1

所以，在效能損耗方面，skywalking更勝一籌。

釋出包比較

skywalking與時俱進，全系標配jar包，部署只需要執行start.sh指令碼即可。而Pinpoint的collector和web還是war包，部署時依賴web容器（比如Tomcat）。拜託，都9012年了。

所以，在釋出包方面，skywalking更勝一籌。

支援元件比較

skywalking和Pinpoint支援的中介軟體對比說明：

1. WEB容器說明：Pinpoint支援幾乎所有的WEB容器，包括開源和商業的。而wkywalking只支援開源的WEB容器，對2款大名鼎鼎的商業WEB容器Weblogic和Wevsphere都不支援。
2. RPC框架說明：對RPC框架的支援，skywalking簡直秒殺Pinpoint。連小眾的motan和sofarpc都支援。
3. MQ說明：skywalking比Pinpoint多支援一個國產的MQ中介軟體RocketMQ，畢竟RocketMQ在國內名氣大，而在國外就一般了。加之skywalking也是國產的。
4. RDBMS/NoSQL說明：Pinpoint對RDBMS和NoSQL的支援都要略好於skywalking，RDBMS方面，skywalking不支援MSSQL和MariaDB。而NoSQL方面，skywalking不支援Cassandra和HBase。至於Pinpoint不支援的H2，完全不是問題，畢竟生產環境是肯定不會使用H2作為底層儲存的。
5. Redis客戶端說明：雖然skywalking和Pinpoint都支援Redis，但是skywalking支援三種流行的Redis客戶端：Jedis，Redisson，Lettuce。而Pinpoint只支援Jedis和Lettuce，再一次，韓國人開發的Pinpoint無視了目前中國人開發的GitHub上star最多的Redis Client — Redisson。
6. 日誌框架說明：Pinpoint居然不支援log4j2？但是已經有人開發了相關功能，詳情請戳連結：log4j plugin support log4j2 or not? https://github.com/naver/pinpoint/issues/3055

---

透過對skywalking和Pinpoint支援中介軟體的對比我們發現，skywalking對國產軟體的支援真的是全方位秒殺Pinpoint，比如小眾化的RPC框架：motan（微博出品），sofarpc，阿裡的RocketMQ，Redis客戶端Redisson，以及分散式任務排程框架elastic-job等。當然也從另一方面反應國產開源軟體在世界上的影響力還很小。

這方面沒有誰好誰壞，畢竟每個公司使用的技術棧不一樣。如果你對RocketMQ有強需求，那麼skywalking是你的最佳選擇。如果你對es有強需求，那麼skywalking也是你的最佳選擇。如果HBase是你的強需求，那麼Pinpoint就是你的最佳選擇。如果MSSQL是你的強需求，那麼Pinpoint也是你的最佳選擇。總之，這裡完全取決你的專案了。

---

總結

經過前面對skywalking和Pinpoint全方位對比後我們發現，對於兩款非常優秀的APM軟體，有一種既生瑜何生亮的感覺。Pinpoint的優勢在於：追蹤資料粒度非常細、功能強大的使用者介面，以及使用HBase作為儲存帶來的海量儲存能力。而skywalking的優勢在於：非常活躍的中文社群，支援多種語言的探針，對國產開源軟體非常全面的支援，以及使用es作為底層儲存帶來的強大的檢索能力，並且skywalking的擴充套件性以及定製化要更優於Pinpoint：

• 如果你有海量的日誌儲存需求，推薦Pinpoint。
• 如果你更看重二次開發的便捷性，推薦skywalking。

最後，參考上面的對比，結合你的需求，哪些不能妥協，哪些可以捨棄，從而更好的選擇一款最適合你的APM軟體。

參考連結

• 參考[1]. https://github.com/apache/incubator-skywalking/blob/master/docs/en/setup/service-agent/java-agent/Supported-list.md
• 參考[2]. http://naver.github.io/pinpoint/1.8.2/main.html#supported-modules
• 參考[3]. https://juejin.im/post/5a7a9e0af265da4e914b46f1