微服務鏈路追蹤之Jaeger

時間 2019-12-18

標籤微服鏈路追蹤 jaeger 简体版

原文原文鏈接

一 Jaeger概述

在微服務爲咱們提供了模塊分，低耦合的高效開發和DevOPS中，具體業務中當一個請求中，請求了多個服務單元，若是請求出現了錯誤或異常，很難去定位是哪一個服務出了問題，這時就須要鏈路追蹤。可能你會想在業務系統中請求中埋點，或寫日誌，可是這種都須要在業務代碼中來寫，並且耦合在代碼中，不具有微服務的擴張性後後期的易維護行。python

1.1 Jaeger概念

受Dapper和OpenZipkin啓發的Jaeger是由Uber Technologies做爲開源發佈的分佈式跟蹤系統。它用於監視和診斷基於微服務的分佈式系統，包括：git

分佈式上下文傳播
分佈式交易監控
根本緣由分析
服務依賴性分析性能/延遲優化

1.2 特性

1.2.1 高擴展性

Jaeger後端的設計沒有單點故障，能夠根據業務需求進行擴展。例如，Uber上任何給定的Jaeger安裝一般天天要處理數十億個跨度。github

1.2.2 原生支持OpenTracing

Jaeger後端，Web UI和工具庫已徹底設計爲支持OpenTracing標準。docker

經過跨度引用將跡線表示爲有向無環圖（不只是樹）shell
支持強類型的跨度標籤和結構化日誌經過行李數據庫
支持通用的分佈式上下文傳播機制json

1.2.3 多存儲後端

Jaeger支持兩個流行的開源NoSQL數據庫做爲跟蹤存儲後端：Cassandra 3.4+和Elasticsearch 5.x / 6.x / 7.x。正在進行使用其餘數據庫的社區實驗，例如ScyllaDB，InfluxDB，Amazon DynamoDB。Jaeger還附帶了一個簡單的內存存儲區，用於測試設置。後端

1.2.4 現代化的UI

Jaeger Web UI是使用流行的開源框架（如React）以Javascript實現的。v1.0中發佈了幾項性能改進，以容許UI有效處理大量數據，並顯示具備成千上萬個跨度的跟蹤（例如，咱們嘗試了具備80,000個跨度的跟蹤）。api

1.2.5 雲原生部署

Jaeger後端做爲Docker映像的集合進行分發。這些二進制文件支持各類配置方法，包括命令行選項，環境變量和多種格式（yaml，toml等）的配置文件。Kubernetes模板和Helm圖表有助於將其部署到Kubernetes集羣。安全

1.2.6 可觀察性

默認狀況下，全部Jaeger後端組件都公開Prometheus指標（也支持其餘指標後端）。使用結構化日誌庫zap將日誌寫到標準輸出。

1.2.7 安全

Jaeger的第三方安全審覈可在https://github.com/jaegertracing/security-audits中得到。有關Jaeger中可用安全機制的摘要，請參見問題＃1718。

1.2.8 與Zipkin的向後兼容性

儘管咱們建議使用OpenTracing API來對應用程序進行檢測並綁定到Jaeger客戶端庫，以從其餘地方沒法得到的高級功能中受益，可是若是您的組織已經使用Zipkin庫對檢測進行了投資，則沒必要重寫全部代碼。Jaeger經過在HTTP上接受Zipkin格式（Thrift或JSON v1 / v2）的跨度來提供與Zipkin的向後兼容性。從Zipkin後端切換隻是將流量從Zipkin庫路由到Jaeger後端的問題。

二快速入門

您的應用程序必須通過檢測，而後才能將跟蹤數據發送到Jaeger後端。查看「客戶端庫」部分，以獲取有關如何使用OpenTracing API以及如何初始化和配置Jaeger跟蹤器的信息。

2.1 簡介

2.2 All in One

多合一是用於快速本地測試的可執行文件，具備內存存儲組件，可啓動Jaeger UI，收集器，查詢和代理。開始多合一的最簡單方法是使用發佈到DockerHub的預構建映像（單個命令行）。

docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.14
複製代碼

Or run the jaeger-all-in-one(.exe) executable from the binary distribution archives:

jaeger-all-in-one --collector.zipkin.http-port=9411
複製代碼

You can then navigate to http://localhost:16686 to access the Jaeger UI.

容器須要暴露的端口

Port	Protocol	Component	Function
5775	UDP	agent	accept `zipkin.thrift` over compact thrift protocol (deprecated, used by legacy clients only)
6831	UDP	agent	accept `jaeger.thrift` over compact thrift protocol
6832	UDP	agent	accept `jaeger.thrift` over binary thrift protocol
5778	HTTP	agent	serve configs
16686	HTTP	query	serve frontend
14268	HTTP	collector	accept `jaeger.thrift` directly from clients
14250	HTTP	collector	accept `model.proto`
9411	HTTP	collector	Zipkin compatible endpoint (optional)

2.3 Kubernetes and OpenShift

Kubernetes templates: github.com/jaegertraci…
Kubernetes Operator: github.com/jaegertraci…
OpenShift templates: github.com/jaegertraci…

2.4 示例APP：HotROD

HotROD（按需乘車）是一個演示應用程序，由幾個微服務組成，並說明了OpenTracing API的用法。博客文章中提供了一個教程/演練：以OpenTracing API.的方式進行HotROD。它能夠獨立運行，但須要Jaeger後端才能查看跟蹤。Take OpenTracing for a HotROD ride

2.4.1 特性

經過數據驅動的依賴關係圖發現整個系統的體系結構
查看請求時間表和錯誤；瞭解應用程序的工做方式。
查找延遲和缺少併發的來源。
高度上下文化的日誌記錄。
使用行李傳播來：
- 診斷請求間爭用（排隊）。
- 服務花費的屬性時間
將開源庫與OpenTracing集成一塊兒使用可免費得到與供應商無關的工具。

2.4.2 先決條件

您須要在計算機上安裝Go 1.11或更高版本才能從源代碼運行
須要運行的Jaeger後端才能查看跟蹤

2.4.3 運行

2.4.3.1 源碼

mkdir -p $GOPATH/src/github.com/jaegertracing
cd $GOPATH/src/github.com/jaegertracing
git clone git@github.com:jaegertracing/jaeger.git jaeger
cd jaeger
make install
go run ./examples/hotrod/main.go all
複製代碼

2.4.3.2 docker

docker run --rm -it \
  --link jaeger \
  -p8080-8083:8080-8083 \
  -e JAEGER_AGENT_HOST="jaeger" \
  jaegertracing/example-hotrod:1.14 \
  all
複製代碼

2.4.3.3 二進制

Run example-hotrod(.exe) executable from the binary distribution archives:

$ example-hotrod all
複製代碼

Then navigate to http://localhost:8080.

2.5 從Zipkin遷移

收集器服務公開了Zipkin兼容的REST API / api / v1 / spans，該API接受Thrift和JSON。此外，還有/ api / v2 / spans用於JSON和Proto。默認狀況下，它是禁用的。可使用--collector.zipkin.http-port = 9411啓用它

Zipkin Thrift IDL and Zipkin Proto IDL files can be found in jaegertracing/jaeger-idl repository. They’re compatible with openzipkin/zipkin-api Thrift and Proto.

三架構

3.1 術語

3.1.1 Span

Span表示Jaeger中的邏輯工做單元，具備操做名稱，操做的開始時間和持續時間。跨度能夠嵌套並排序以創建因果關係模型。

每一個 Span 包含如下對象：

Operation name：操做名稱（也能夠稱做 Span name）。
Start timestamp：起始時間。
Finish timestamp：結束時間。
Span tag：一組鍵值對構成的 Span 標籤集合。鍵值對中，鍵必須爲 String，值能夠是字符串、布爾或者數字類型。
Span log：一組 Span 的日誌集合。每次 Log 操做包含一個鍵值對和一個時間戳。鍵值對中，鍵必須爲 String，值能夠是任意類型。
SpanContext: pan 上下文對象。每一個 SpanContext 包含如下狀態：
- 要實現任何一個 OpenTracing，都須要依賴一個獨特的 Span 去跨進程邊界傳輸當前調用鏈的狀態（例如：Trace 和 Span 的 ID）。
- Baggage Items 是 Trace 的隨行數據，是一個鍵值對集合，存在於 Trace 中，也須要跨進程邊界傳輸。
References（Span 間關係）：相關的零個或者多個 Span（Span 間經過 SpanContext 創建這種關係）。

3.1.2 Trace

跟蹤是經過系統的數據/執行路徑，能夠看做跨度的有向無環圖。

3.2 組件

Jaeger能夠做爲多合一二進制（其中全部Jaeger後端組件都在單個進程中運行）進行部署，也能夠做爲可擴展的分佈式系統進行部署，以下所述。有兩個主要的部署選項：

收集器正在直接寫入存儲。

收集器正在寫信給Kafka做爲初步緩衝。

本節詳細介紹Jaeger的組成部分以及它們之間的關係。它由您的應用程序與之交互的順序安排。

3.2.1 Jaeger client libraries

Jaeger客戶端是OpenTracing API的特定於語言的實現。它們可用於手動或經過與OpenTracing集成的各類現有開源框架（例如Flask，Dropwizard，gRPC等）來檢測應用程序以進行分佈式跟蹤。

檢測服務在接收新請求時建立跨度，並將上下文信息（跟蹤ID，跨度ID和行李）附加到傳出請求。只有ID和行李隨請求一塊兒傳播；不會傳播構成跨度的全部其餘信息，例如操做名稱，日誌等。取而代之的是，採樣的跨度在後臺異步傳輸到Jaeger Agents的過程外。

該儀器的開銷很小，而且設計爲始終在生產中啓用。請注意，雖然生成了全部跟蹤，但僅採樣了一些。對跟蹤進行採樣將跟蹤標記爲進一步處理和存儲。默認狀況下，Jaeger客戶端對0.1％的跡線進行採樣（每1000箇中的1個），而且可以從代理中檢索採樣策略。

3.2.2 Agent

Jaeger代理是一個網絡守護程序，它偵聽經過UDP發送的跨度，而後將其分批發送給收集器。它旨在做爲基礎結構組件部署到全部主機。該代理將收集器的路由和發現抽象到遠離客戶端的位置。

3.2.3 Collector

Jaeger收集器從Jaeger代理接收跟蹤，並經過處理管道運行它們。當前，咱們的管道會驗證跟蹤，爲其創建索引，執行任何轉換並最終存儲它們。Jaeger的存儲設備是可插拔組件，目前支持Cassandra，Elasticsearch和Kafka。

3.2.4 Query

查詢是一項從存儲中檢索跟蹤並託管UI來顯示跟蹤的服務。

3.2.5 Ingester

Ingester is a service that reads from Kafka topic and writes to another storage backend (Cassandra, Elasticsearch).

3.3 Sampling

Jaeger庫實現了一致的前期（或基於頭）的採樣。例如，假設咱們有一個簡單的調用圖，其中服務A調用服務B，服務B調用服務C：A-> B->C。當服務A收到不包含跟蹤信息的請求時，Jaeger跟蹤器將開始新的跟蹤，爲其分配一個隨機跟蹤ID，而後根據當前安裝的採樣策略作出採樣決定。採樣決策將與請求一塊兒傳播到B和C，所以這些服務將不會再次作出採樣決策，而是會尊重頂級服務A作出的決策。這種方法保證了，若是對跟蹤進行了採樣，則全部其跨度將記錄在後端。若是每一個服務都作出本身的抽樣決定，那麼咱們不多會在後端得到完整的跟蹤。

3.3.1 客戶端採樣配置

使用配置對象實例化跟蹤器時，能夠經過sampler.type和sampler.param屬性選擇採樣類型。Jaeger庫支持如下采樣器：

Constant (sampler.type=const) sampler always makes the same decision for all traces. It either samples all traces (sampler.param=1) or none of them (sampler.param=0).
Probabilistic (sampler.type=probabilistic) sampler makes a random sampling decision with the probability of sampling equal to the value of sampler.param property. For example, with sampler.param=0.1 approximately 1 in 10 traces will be sampled.
Rate Limiting (sampler.type=ratelimiting) sampler uses a leaky bucket rate limiter to ensure that traces are sampled with a certain constant rate. For example, when sampler.param=2.0 it will sample requests with the rate of 2 traces per second.
Remote (sampler.type=remote, which is also the default) sampler consults Jaeger agent for the appropriate sampling strategy to use in the current service. This allows controlling the sampling strategies in the services from a central configuration in Jaeger backend, or even dynamically (see Adaptive Sampling).

3.3.2 適配示例

自適應採樣器是一個組合了兩個功能的複合採樣器：

它基於每一個操做（即基於跨度操做名稱）作出抽樣決策。這在API服務中尤爲有用，這些API服務的端點的流量可能很是不一樣，而且對整個服務使用單個機率採樣器可能會使某些低QPS端點餓死（從不採樣）。
它支持最低的保證採樣率，例如始終容許每秒最多N條跡線，而後以必定的機率對全部採樣率進行採樣（一切都是針對每一個操做，而非針對每一個服務）。

能夠靜態配置每一個操做參數，也能夠在遠程採樣器的幫助下從Jaeger後端按期提取每一個操做參數。自適應採樣器旨在與Jaeger後端即將推出的自適應採樣功能一塊兒使用。

3.3.3 集合示例配置

能夠經過--sampling.strategies-file選項使用靜態採樣策略實例化收集器（若是使用Remote sampler配置，則將其傳播到相應的服務）。此選項須要一個已定義採樣策略的json文件路徑。

{
  "service_strategies": [
    {
      "service": "foo",
      "type": "probabilistic",
      "param": 0.8,
      "operation_strategies": [
        {
          "operation": "op1",
          "type": "probabilistic",
          "param": 0.2
        },
        {
          "operation": "op2",
          "type": "probabilistic",
          "param": 0.4
        }
      ]
    },
    {
      "service": "bar",
      "type": "ratelimiting",
      "param": 5
    }
  ],
  "default_strategy": {
    "type": "probabilistic",
    "param": 0.5
  }
}

複製代碼