1. 程式人生 > >使用OpenTracing對ruby應用進行分散式鏈路追蹤

使用OpenTracing對ruby應用進行分散式鏈路追蹤

當最終響應是來源於一系列微服務時,將請求的生命週期串聯起來就是一件比較困難的事情。
然而,分散式鏈路追蹤通過將微服務之間的鏈路串聯可以讓這件事變得簡單。本文我將展示如何通過OpenTracing(提供平臺無關的API)和Jaeger(開源分散式追蹤系統)將分散式鏈路追蹤應用到你的Sinatra專案中。

OpenTracing,一套平臺無關的追蹤API

OpenTracing,一個平臺無關的分散式鏈路追蹤開放標準。OpenTracing解決了不同的分散式系統API不相容的問題:如果通過OpenTracing API追蹤方法呼叫,就可以輕易的替換追蹤平臺。

現在有很多服務可以處理OpenTracing生成的交易追蹤記錄, 在本章中我們將從兩個Sinatra專案收集資訊, 並通過

Jaeger展示資訊。

準備工作

本文將用到以下元件:

  • Jaeger All-in-one Docker映象:用於本地檢視分散式追蹤
  • 兩個Sinatra示例應用
  • Gem rack-tracer:追蹤發向Sinatra應用的請求,我使用的版本是0.3.0。
  • Gem jaeger-client:Jaeger OpenTracing追蹤器,用來將追蹤資訊傳送到Jaeger收集器。我使用的版本是0.4.1。

安裝Jaeger All-in-one

Jaeger All-in-one Docker映象專門用於本地的快速測試驗證。它包含了Jaeger UI,收集器,query和agent,以及一個基於記憶體的儲存元件。安裝在Sinatra專案中的

jaeger-client傳送追蹤資訊給執行容器中的Jaeger收集器。之後追蹤的資訊就可以通過訪問http://localhost:16686
以web UI的形式展示。

你可以通過以下命令安裝並執行Jaeger All-in-one(前提是你的機器上已經安裝了Docker)

docker run -d -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 -p5775:5775/udp -p6831:6831/udp -p6832:6832/udp \
  -p5778:5778 -p16686:16686 -p14268:14268 -p9411:9411 jaegertracing/all-in-one:latest

訪問Web UI http://localhost:16686來驗證安裝是否成功。現在Jaeger已經在運行了,讓我們來啟動第一個Sinatra應用吧。

Sinatra App No. 1: “Hello”

該示例應用在訪問http://localhost:4567時簡單的返回"Hello",OpenTracing相關的部分已經加在了下面程式碼中:

# File name:  hello.rb
# To run: ruby hello.rb
require 'sinatra'

require 'opentracing'
require 'jaeger/client'
require 'rack/tracer'

OpenTracing.global_tracer = Jaeger::Client.build(service_name: 'hello')

use Rack::Tracer

get '/' do
  'Hello'
end

在同層級新增Gemfile

# Gemfile
source 'https://rubygems.org'

gem 'sinatra'
gem 'rack-tracer'
gem 'jaeger-client'

執行bundle安裝gem成功之後啟動應用:ruby hello.rb

收集第一條鏈路資訊

Sinatra App No. 2: “Hello World”

該應用會向前一個"Hello"應用傳送請求。通過OpenTracing的魔力,我們可以看到請求從父應用(Hello World)到微服務應用(Hello)完整的生命週期。

以下是第二個應用的程式碼:

# File Name: hello_world.rb
# To run: ruby hello_world.rb -p 4570
require 'sinatra'

require 'opentracing'
require 'jaeger/client'
require 'rack/tracer'

OpenTracing.global_tracer = Jaeger::Client.build(service_name: 'hello-world')

use Rack::Tracer

get '/' do
  "#{hello} world"
end

def hello
  client = Net::HTTP.new("localhost",4567)
  req = Net::HTTP::Get.new("/")
  OpenTracing.inject(env['rack.span'].context, OpenTracing::FORMAT_RACK, req)
  client.request(req).body
end

4570ruby hello_world.rb -p4570啟動應用。

分散式鏈路追蹤是如何工作的?

“Hello World”應用返回了"Hello"應用中的資訊。OpenTracing是怎麼抓取到這個請求的整個生命過程的呢?
OpenTracing為tracing across process boundaries定義了一項標準,該標準包含兩部分:

  • Tracer#inject:將SpanContext注入到我們從"Hello World"發出請求的請求頭中。
  • Tracer#extract:在"Hello" 中抽取出請求頭中的SpanContext

在上面程式碼中可以看到,我們在請求傳送到"Hello"應用之前手動將SpanContext注入到了請求頭:

OpenTracing.inject(env['rack.span'].context, OpenTracing::FORMAT_RACK, req)

總結

短短几步, 我們藉助於OpenTracing將平臺無關的分散式追蹤應用到了我們的ruby專案中來。可以通過Jaeger檢視追蹤。如果除了Jaeger你有其他喜歡的追蹤系統,也可以通過在Sinatra應用的修改一行程式碼來快速的替換。

相關推薦

使用OpenTracingruby應用進行分散式追蹤

當最終響應是來源於一系列微服務時,將請求的生命週期串聯起來就是一件比較困難的事情。 然而,分散式鏈路追蹤通過將微服務之間的鏈路串聯可以讓這件事變得簡單。本文我將展示如何通過OpenTracing(提供平臺無關的API)和Jaeger(開源分散式追蹤系統)將分散

springcloud-slenth-zipkin進行分散式追蹤

Spring Cloud Sleuth 一般的,一個分散式服務跟蹤系統,主要有三部分:資料收集、資料儲存和資料展示。根據系統大小不同,每一部分的結構又有一定變化。譬如,對於大規模分散式系統,資料儲存可分為實時資料和全量資料兩部分,實時資料用於故障排查(troub

【spring cloud】spring cloud Sleuth 和Zipkin 進行分散式跟蹤

spring cloud 分散式微服務架構下,所有請求都去找閘道器,對外返回也是統一的結果,或者成功,或者失敗。 但是如果失敗,那分散式系統之間的服務呼叫可能非常複雜,那麼要定位到發生錯誤的具體位置,就是一個比較麻煩的問題。 所以定位故障點,就引入了spring cloud Sleuth【Sleuth是獵

springcloud(十二):使用Spring Cloud Sleuth和Zipkin進行分散式跟蹤

Spring Cloud Sleuth 一般的,一個分散式服務跟蹤系統,主要有三部分:資料收集、資料儲存和資料展示。根據系統大小不同,每一部分的結構又有一定變化。譬如,對於大規模分散式系統,資料儲存可分為實時資料和全量資料兩部分,實時資料用於故障排查(troubleshooting),全量資料用於系統優化;資

Spring Cloud:使用Spring Cloud Sleuth和Zipkin進行分散式跟蹤(12)

隨著業務發展,系統拆分導致系統呼叫鏈路愈發複雜一個前端請求可能最終需要呼叫很多次後端服務才能完成,當整個請求變慢或不可用時,我們是無法得知該請求是由某個或某些後端服務引起的,這時就需要解決如何快讀定位服務故障點,以對症下藥。於是就有了分散式系統呼叫跟蹤的誕生。 現今業界分散式服務跟蹤的理論基礎主

springcloud+springboot(十二):使用Spring Cloud Sleuth和Zipkin進行分散式跟蹤

Spring Cloud Sleuth 一般的,一個分散式服務跟蹤系統,主要有三部分:資料收集、資料儲存和資料展示。根據系統大小不同,每一部分的結構又有一定變化。譬如,對於大規模分散式系統,資料儲存可分為實時資料和全量資料兩部分,實時資料用於故障排查(troubleshooting),全量資料用於系統優化

java分散式追蹤;jvm應用監控-skywalking

當企業應用進入分散式微服務時代,應用服務依賴會越來越多,skywalking可以很好的解決服務呼叫鏈路追蹤的問題,而且基於java探針技術,基本對應用零侵入零耦合。skywalking是什麼,有什麼用?Skywalking 是一個APM系統,即應用效能監控系統,為微服務架構和

跟我學SpringCloud | 第十一篇:使用Spring Cloud Sleuth和Zipkin進行分散式跟蹤

SpringCloud系列教程 | 第十一篇:使用Spring Cloud Sleuth和Zipkin進行分散式鏈路跟蹤 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如無特殊說明,本系列教程全採用以上版本 在分散式服務架構中,需要對分散

【Springboot】例項講解Springboot整合OpenTracing分散式追蹤系統(Jaeger和Zipkin)

# 1 分散式追蹤系統 隨著大量公司把單體應用重構為微服務,對於運維人員的責任就更加重大了。架構更復雜、應用更多,要從中快速診斷出問題、找到效能瓶頸,並不是一件容易的事。因此,也隨著誕生了一系列面向`DevOps`的診斷與分析系統,主要是以下三個系統: - 集中式日誌系統(Logging) - 集中式度量

SkyWalking —— 分散式應用監控與追蹤

SkyWalking 是一個應用效能監控系統,特別為微服務、雲原生和基於容器(Docker, Kubernetes, Mesos)體系結構而設計。除了應用指標監控以外,它還能對分散式呼叫鏈路進行追蹤。類似功能的元件還有:Zipkin、Pinpoint、CAT等。 上幾張圖,看看效果,然後再一步一步搭建並使用

Laravel + go-micro + grpc 實踐基於 Zipkin 的分散式追蹤系統 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?

分散式呼叫鏈跟蹤系統,屬於監控系統的一類。系統架構逐步演進時,後期形態往往是一個平臺由很多不同的服務、元件構成,使用者請求過來後,可能會經過其中多個服務,如圖     不過,出問題時往往很難排查,如整個請求變慢、偶爾報錯、不可用等,我們很難得知具體是由哪一個或哪些服務引起的,通常

開源APM系統skywalking整合springcloud分散式追蹤

SkyWalking    被用於追蹤、監控和診斷分散式系統,特別是使用微服務架構,雲原生或容積技術。主要功能如下:分散式追蹤和上下文傳輸、應用、例項、服務效能指標分析、根源分析、應用拓撲分析、應用和服務依賴分析、慢服務檢測、效能優化 demo搭建如下: 1.下載

【阿里雲ACE成長記第5期】分散式追蹤系統架構設計的經驗分享

【引言】本期由阿里雲ACE(阿里雲開發者社群)&成都檸檬雲網絡技術有限公司資深架構師 曾昌強 為大家分享個人成長經歷與個人專業技術之分散式鏈路追蹤系統架構設計。視訊:https://yq.aliyun.com/live/581 Part 1:成長經歷講述一個不知道什麼叫程式設計的門外漢,如何穿越幾千

skywalking分散式追蹤監控系統部署

SkyWalking 是針對分散式系統的 APM 系統,也被稱為分散式追蹤系統 全自動探針監控,不需要修改應用程式程式碼。檢視支援的中介軟體和元件庫列表:https://github.com/apache/incubator-skywalking 支援手動探針監控, 提供了支援 Ope

spring cloud 分散式追蹤

  微服務之間進行呼叫 那麼如果我負責一個模組 別人負責另一個模組 我呼叫了他的方法 測試那邊卻報了錯 那是我的問題還是他的問題   這個時候大家應該就能想到日誌可以解決這個問題   如何使用日誌呢 先在配置檔案中加   logging:   path:D:\logs

Spring Boot + Spring Cloud 構建微服務系統(八):分散式追蹤(Sleuth、Zipkin)

技術背景 在微服務架構中,隨著業務發展,系統拆分導致系統呼叫鏈路愈發複雜,一個看似簡單的前端請求可能最終需要呼叫很多次後端服務才能完成,那麼當整個請求出現問題時,我們很難得知到底是哪個服務出了問題導致的,這時就需要解決一個問題,如何快速定位服務故障點,於是,分散式系統呼叫鏈追蹤技術就此誕生了。 ZipKin

分散式追蹤

隨著業務發展,系統拆分導致系統呼叫鏈路愈發複雜一個前端請求可能最終需要呼叫很多次後端服務才能完成,當整個請求變慢或不可用時,我們是無法得知該請求是由某個或某些後端服務引起的,這時就需要解決如何快讀定位服務故障點,以對症下藥。於是就有了分散式系統

分散式追蹤技術對比

方案選擇 本文最終選擇了zipkin+sleuth做二次開發,這樣做靈活性比較大一點。 有興趣的可以進我部落格看一下,我會將我二次開發過程當中遇到的問題發出來。 常見開源產品 cat, zipkin, pinpoint , skywalking  cat 

關於分散式追蹤的一些記錄

基本原理    目前所有的分散式鏈路追蹤都是來自於谷歌的一篇論文。論文地址如下:https://www.jianshu.com/p/cdefc9971951?utm_campaign=maleskine&utm_content=note&utm_medium=

skyWalking分散式追蹤部署

使用環境 centos7.3 JKD1.8 elasticsearch5.6.8 skyWalking3.2.6 筆者把所有的環境都打包在這百度網盤裡面 下載完之後筆者是把檔案放在下面這個目錄 mv sky/ /usr/