服务监控之分布式追踪一篇读懂

时间 2019-11-12

原文原文链接

如今愈来愈多的应用迁移到基于微服务的云原生的架构之上，微服务架构很强大，可是同时也带来了不少的挑战，尤为是如何对应用进行调试，如何监控多个服务间的调用关系和状态。如何有效的对微服务架构进行有效的监控成为微服务架构运维成功的关键。

如今愈来愈多的应用迁移到基于微服务的云原生的架构之上，微服务架构很强大，可是同时也带来了不少的挑战，尤为是如何对应用进行调试，如何监控多个服务间的调用关系和状态。如何有效的对微服务架构进行有效的监控成为微服务架构运维成功的关键。用软件架构的语言来讲就是要加强微服务架构的可观测性(Observability)。html

微服务的监控主要包含一下三个方面：mysql

经过收集日志，对系统和各个服务的运行状态进行监控
经过收集量度(Metrics)，对系统和各个服务的性能进行监控
经过分布式追踪，追踪服务请求是如何在各个分布的组件中进行处理的细节

对因而日志和量度的收集和监控，你们会比较熟悉。常见的日志收集架构包含利用Fluentd对系统日志进行收集，而后利用ELK或者Splunk进行日志分析。而对于性能监控，Prometheus是常见的流行的选择。linux

分布式追踪正在被愈来愈多的应用所采用。分布式追踪能够经过对微服务调用链的跟踪，构建一个从服务请求开始到各个微服务交互的所有调用过程的视图。用户能够从中了解到诸如应用调用的时延，网络调用(HTTP，RPC)的生命周期，系统的性能瓶颈等等信息。那么分布式追踪是如何实现的呢?sql

1.分布式追踪的概念数据库

谷歌在2010年4月发表了一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》(http://1t.click/6EB)，介绍了分布式追踪的概念。flask

对于分布式追踪，主要有如下的几个概念：服务器

追踪 Trace：就是由分布的微服务协做所支撑的一个事务。一个追踪，包含为该事务提供服务的各个服务请求。
跨度 Span：Span是事务中的一个工做流，一个Span包含了时间戳，日志和标签信息。Span之间包含父子关系，或者主从(Followup)关系。
跨度上下文 Span Context：跨度上下文是支撑分布式追踪的关键，它能够在调用的服务之间传递，上下文的内容包括诸如：从一个服务传递到另外一个服务的时间，追踪的ID，Span的ID还有其它须要从上游服务传递到下游服务的信息。

2.OpenTracing 标准概念网络

基于谷歌提出的概念OpenTracing(http://1t.click/6tC)定义了一个开放的分布式追踪的标准。架构

Span是分布式追踪的基本组成单元，表示一个分布式系统中的单独的工做单元。每个Span能够包含其它Span的引用。多个Span在一块儿构成了Trace。并发

OpenTracing的规范定义每个Span都包含了如下内容：

操做名(Operation Name)，标志该操做是什么
标签 (Tag)，标签是一个名值对，用户能够加入任何对追踪有意义的信息
日志(Logs)，日志也定义为名值对。用于捕获调试信息，或者相关Span的相关信息
跨度上下文呢 (SpanContext)，SpanContext负责子微服务系统边界传递数据。它主要包含两部分：

和实现无关的状态信息，例如Trace ID，Span ID
行李项 (Baggage Item)。若是把微服务调用比作从一个城市到另外一个城市的飞行, 那么SpanContext就能够当作是飞机运载的内容。Trace ID和Span ID就像是航班号，而行李项就像是运送的行李。每次服务调用，用户均可以决定发送不一样的行李。

这里是一个Span的例子：

t=0 operation name: db_query t=x 
 +-----------------------------------------------------+ 
 | · · · · · · · · · · Span · · · · · · · · · · | 
 +-----------------------------------------------------+ 
Tags: 
- db.instance:"jdbc:mysql://127.0.0.1:3306/customers 
- db.statement: "SELECT * FROM mytable WHERE foo='bar';"  
Logs: 
- message:"Can't connect to mysql server on '127.0.0.1'(10061)"  
SpanContext: 
- trace_id:"abc123" 
- span_id:"xyz789" 
- Baggage Items: 
- special_id:"vsid1738"

要实现分布式追踪，如何传递SpanContext是关键。OpenTracing定义了两个方法Inject和Extract用于SpanContext的注入和提取。

Inject 伪代码

span_context = ... 
outbound_request = ...  
# We'll use the (builtin) HTTP_HEADERS carrier format. We 
# start by using an empty map as the carrier prior to the 
# call to `tracer.inject`. 
carrier = {} 
tracer.inject(span_context, opentracing.Format.HTTP_HEADERS, carrier)  
# `carrier` now contains (opaque) key:value pairs which we pass 
# along over whatever wire protocol we already use. 
for key, value in carrier: 
outbound_request.headers[key] = escape(value)

这里的注入的过程就是把context的全部信息写入到一个叫Carrier的字典中，而后把字典中的全部名值对写入 HTTP Header。

Extract 伪代码

inbound_request = ...  
# We'll again use the (builtin) HTTP_HEADERS carrier format. Per the 
# HTTP_HEADERS documentation, we can use a map that has extraneous data 
# in it and let the OpenTracing implementation look for the subset 
# of key:value pairs it needs. 
# 
# As such, we directly use the key:value `inbound_request.headers` 
# map as the carrier. 
carrier = inbound_request.headers 
span_context = tracer.extract(opentracing.Format.HTTP_HEADERS, carrier) 
# Continue the trace given span_context. E.g., 
span = tracer.start_span("...", child_of=span_context)  
# (If `carrier` held trace data, `span` will now be ready to use.)

抽取过程是注入的逆过程，从carrier，也就是HTTP Headers，构建SpanContext。

整个过程相似客户端和服务器传递数据的序列化和反序列化的过程。这里的Carrier字典支持Key为string类型，value为string或者Binary格式(Bytes)。

3.怎么用能?

好了讲了一大堆的概念，做为程序猿的你早已经不耐烦了，不要讲那些有的没的，快上代码。不急咱们这就看看具体如何使用Tracing。

咱们用一个程序猿喜闻乐见的打印‘hello world’的Python应用来讲明OpenTracing是如何工做的。

客户端代码

import requests 
import sys 
import time 
from lib.tracing import init_tracer 
from opentracing.ext import tags 
from opentracing.propagation import Format  
def say_hello(hello_to): 
with tracer.start_active_span('say-hello') as scope: 
scope.span.set_tag('hello-to', hello_to) 
hello_str = format_string(hello_to) 
print_hello(hello_str) 
def format_string(hello_to): 
with tracer.start_active_span('format') as scope: 
hello_str = http_get(8081, 'format', 'helloTo', hello_to) 
scope.span.log_kv({'event': 'string-format', 'value': hello_str}) 
return hello_str  
def print_hello(hello_str): 
with tracer.start_active_span('println') as scope: 
http_get(8082, 'publish', 'helloStr', hello_str) 
scope.span.log_kv({'event': 'println'})  
def http_get(port, path, param, value): 
url = 'http://localhost:%s/%s' % (port, path)  
span = tracer.active_span 
span.set_tag(tags.HTTP_METHOD, 'GET') 
span.set_tag(tags.HTTP_URL, url) 
span.set_tag(tags.SPAN_KIND, tags.SPAN_KIND_RPC_CLIENT) 
headers = {} 
tracer.inject(span, Format.HTTP_HEADERS, headers)  
r = requests.get(url, params={param: value}, headers=headers) 
assert r.status_code == 200 
return r.text 
# main 
assert len(sys.argv) == 2  
tracer = init_tracer('hello-world')  
hello_to = sys.argv[1] 
say_hello(hello_to) 
# yield to IOLoop to flush the spans 
time.sleep(2) 
tracer.close()

客户端完成了如下的工做：

初始化Tracer，trace的名字是‘hello-world’
建立以个客户端操做say_hello，该操做关联一个Span，取名‘say-hello’，并调用span.set_tag加入标签
在操做say_hello中调用第一个HTTP 服务A，format_string，该操做关联另外一个Span取名‘format’，并调用span.log_kv加入日志
以后调用另外一个HTTP 服务B，print_hello，该操做关联另外一个Span取名‘println’，并调用span.log_kv加入日志
对于每个HTTP请求，在Span中都加入标签，标志http method，http url和span kind。并调用tracer.inject把SpanContext注入到http header 中。

服务A代码

from flask import Flask 
from flask import request 
from lib.tracing import init_tracer 
from opentracing.ext import tags 
from opentracing.propagation import Format  
app = Flask(__name__) 
tracer = init_tracer('formatter')    
@app.route("/format") 
def format(): 
span_ctx = tracer.extract(Format.HTTP_HEADERS, request.headers) 
span_tags = {tags.SPAN_KIND: tags.SPAN_KIND_RPC_SERVER} 
with tracer.start_active_span('format', child_of=span_ctx, tags=span_tags): 
hello_to = request.args.get('helloTo') 
return 'Hello, %s!' % hello_to 
if __name__ == "__main__": 
app.run(port=8081)

服务A响应format请求，调用tracer.extract从http headers中提取信息，构建spanContext。

服务B代码

from flask import Flask 
from flask import request 
from lib.tracing import init_tracer 
from opentracing.ext import tags 
from opentracing.propagation import Format  
app = Flask(__name__) 
tracer = init_tracer('publisher') 
@app.route("/publish") 
def publish(): 
span_ctx = tracer.extract(Format.HTTP_HEADERS, request.headers) 
span_tags = {tags.SPAN_KIND: tags.SPAN_KIND_RPC_SERVER} 
with tracer.start_active_span('publish', child_of=span_ctx, tags=span_tags): 
hello_str = request.args.get('helloStr') 
print(hello_str) 
return 'published'  
if __name__ == "__main__": 
app.run(port=8082)

服务B和A相似。

以后在支持分布式追踪的软件UI上(下图是Jaeger UI)，就能够看到相似下图的追踪信息。咱们能够看到服务hello-word和三个操做say-hello/format/println的详细追踪信息。

当前有不少分布式追踪软件都提供了OpenTracing的支持，包括：Jaeger，LightStep，Instanna，Apache SkyWalking，inspectIT，stagemonitor，Datadog，Wavefront，Elastic APM等等。其中做为开源软件的Zipkin(http://1t.click/6Ec)和Jaeger(http://1t.click/6DY)最为流行。

Zipkin

Zipkin(http://1t.click/6Ec)是Twitter基于Dapper开发的分布式追踪系统。它的设计架构以下图：

蓝色实体是Zipkin要追踪的目标组件，Non-Intrumented Server表示不直接调用Tracing API的微服务。经过Intrumented Client从Non-Intrumented Server中收集信息并发送给Zipkin的收集器Collector。Intrumented Server 直接调用Tracing API，发送数据到Zipkin的收集器。
Transport是传输通道，能够经过HTTP直接发送到Zipkin或者经过消息/事件队列的方式。
Zipkin自己是一个Java应用，包含了：收集器Collector负责数据采集，对外提供数据接口;存储;API和UI。

Zipkin的用户界面像这个样子：

Zipkin官方支持如下几种语言的客户端：C#，Go，Java，JavaScript，Ruby，Scala，PHP。开源社区也有其它语言的支持。

Zipkin发展到如今有快4年的时间，是一个相对成熟的项目。

Jaeger

Jaeger(http://1t.click/6DY)最先是由Uber开发的分布式追踪系统，一样基于Dapper的设计理念。如今Jaeger是CNCF(Cloud Native Computing Foundation)的一个项目。若是你对CNCF这个组织有所了解，那么你能够推测出这个项目应该和Kubernetes有很是紧密的集成。

Jaeger基于分布式的架构设计，主要包含如下几个组件：

Jaeger Client，负责在客户端收集跟踪信息。
Jaeger Agent，负责和客户端通讯，把收集到的追踪信息上报个收集器 Jaeger Collector
Jaeger Colletor把收集到的数据存入数据库或者其它存储器
Jaeger Query 负责对追踪数据进行查询
Jaeger UI负责用户交互

这个架构很像ELK，Collector以前相似Logstash负责采集数据，Query相似Elastic负责搜索，而UI相似Kibana负责用户界面和交互。这样的分布式架构使得Jaeger的扩展性更好，能够根据须要，构建不一样的部署。

Jaeger做为分布式追踪的后起之秀，随着云原生和K8s的普遍采用，正变得愈来愈流行。利用官方给出的K8s部署模版(http://1t.click/6DU)，用户能够快速的在本身的k8s集群上部署Jaeger。

4.分布式跟踪系统——产品对比

固然除了支持OpenTracing标准的产品以外，还有其它的一些分布式追踪产品。这里引用一些其它博主的分析，给你们一些参考：

调用链选型之Zipkin，Pinpoint，SkyWalking，CAT(http://1t.click/6tY)
分布式调用链调研(pinpoint,skywalking,jaeger,zipkin等对比)(http://1t.click/6DK)
分布式跟踪系统——产品对比(http://1t.click/6ug)

5.总结

在微服务大行其道，云原生成为架构设计的主流的状况下，微服务系统监控，包含日志，指标和追踪成为了系统工程的重中之重。OpenTracing基于Dapper的分布式追踪设计理念，定义了分布式追踪的实现标准。在开源项目中，Zipkin和Jaeger是相对优秀的选择。尤为是Jaeger，因为对云原生框架的良好集成，是构建微服务追踪系统的必备良器。

本文地址：https://www.linuxprobe.com/tracking-service-monitoring.html