Google釋出Zipkin與Stackdriver Trace的內建功能

google雲平台（google cloud platform）釋出了一個開源的zipkin伺服器，允許相容zipkin的用戶端發送跟蹤資訊到google自己的stackdriver trace分布式跟蹤服務中，進而實作分析的功能。zipkin/stackdriver trace內建的目标使用者是某些開發人員，他們的應用和服務是使用stackdriver trace官方所不支援的語言或架構編寫的，或者是某些應用的持有者，這些應用已經通過zipkin實作了instrument功能，他們還希望通路stackdriver trace的進階分析工具。

google的stackdriver能夠對雲平台上的應用提供監控、日志以及診斷服務。盡管任何雲平台捕獲到的資料都可以發送到stackdriver api上，但是stackdriver的功能是與google雲平台（google cloud platform，gcp）（gcp的客戶可以免費使用它）中的很多服務高度內建的。google stackdriver中包含了多個工具，其中就包括stackdriver trace，這是一個分布式的跟蹤服務，它是由最初的google dapper分布式跟蹤系統演化而來。

将分布式（微服務）系統進行instrument操作之後，stackdriver trace就允許開發人員跟蹤系統的請求流，分析應用的延遲并隔離性能瓶頸。stackdriver trace最初關注的是google app engine項目，但是現在支援運作在虛拟機或容器上的應用，這是通過為node.js、java和go（很快就會支援ruby和.net）提供instrumentation庫實作的，它還可以通過api來實作該功能。

另外一個流行的分布式跟蹤系統是zipkin，它最初是由twitter建立的，靈感起源于dapper的論文。這項成果在2012年開源，随後發展成為社群驅動的open zipkin項目。它反過來又推動了open tracing api的形成，這是一個由cncf支援的項目。zipkin提供了一系列的instrumentation庫，這些庫能夠捕獲應用的trace，另外還有一個後端系統用來存儲trace并支援通過web界面展現trace資訊。目前，已經有針對java、.net、node.js、python、ruby和go的zipkin用戶端，還有與各種流行web架構的内置內建。根據gcp部落格的說法，zipkin得到了廣泛的應用，twitter、yelp和salesforce是該項目的主要貢獻者。

google雲平台的部落格文章指出，這個新的stackdriver trace zipkin連接配接器是已有zipkin後端的替代方案，它會繼續使用相同的相容zipkin的跟蹤器，這樣的話，就沒有必要再去配置、管理或維護zipkin後端了。另外，新的收集器能夠與使用zipkin跟蹤器實作instrument功能的服務協同運作。

　　目前的stackdriver-zipkin v0.2.0釋出版本有幾個已知的限制：

zipkin跟蹤器必須要支援正确的zipkin時間和持續時長語義； zipkin跟蹤器和stackdriver trace instrumentation庫不能向同一條trace記錄上附加span，因為它們會對服務間傳播的跟蹤上下文采用不同的格式。這意味着某個庫捕獲的trace中不能包含其他類型的庫instrument服務後所形成的span，也就是說，如何服務代碼混合使用了stackdriver trace和zipkin的instrument功能，那麼跨越這些服務所形成的跟蹤資訊必須要在标準的stackdriver報告系統之外進行內建； 最初的釋放版本隻支援對zipkin伺服器進行寫操作，google雲平台的部落格上指出，如果缺乏讀取功能成為了一種阻礙的話，那麼開發人員可以在github上送出issue或pullrequest。

google stackdriver trace zipkin收集器的代碼可以通過googlecloudplatform github倉庫進行下載下傳。配置以及從分布式跟蹤器收集trace資料的指令可以在“組合使用stackdriver trace與zipkin”指南中找到。

本文轉自d1net（轉載）