opentelemetry全链路初探–jaeger架构拆分

技术分享 4个月前 (11-19) 0 999+

前言

jaeger的架构演变

在之前的描述中，一直使用jaeger:all-in-one来做数据存储与展示，jaeger:all-in-one就是将collector、query、ui、storage等等功能的大杂烩，在调试与测试环境中，非常方便，但是在生产环境肯定是不能这样用，本节就来将其拆分成对应的子模块

jaeger架构改造

数据上报：可以是sdk、api、定时脚本等一切上报trace、metrics数据的工具
collector：用于接收trace数据上报
storage：将数据发送到对应的地方存储起来，以便UI查询使用。trace常见的storage：es、kafka等
UI：trace常见的展示工具：jaeger

下面我们来详细描述一下整个过程

采集程序

import tornado.httpserver as httpserver import tornado.web from tornado.ioloop import IOLoop from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.resources import SERVICE_NAME, Resource from opentelemetry.sdk.trace.export import BatchSpanProcessor from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter from opentelemetry.trace import get_tracer   trace.set_tracer_provider(     TracerProvider(resource=Resource.create({SERVICE_NAME: "hello-otlp"})) ) span_processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://127.0.0.1:14318/v1/traces")) trace.get_tracer_provider().add_span_processor(span_processor)  def traced(name):     def decorator(func):         def wrapper(*args, **kwargs):             tracer = get_tracer(__name__)             with tracer.start_as_current_span(name):                 return func(*args, **kwargs)         return wrapper     return decorator  class TestFlow(tornado.web.RequestHandler):     def get(self):         views()         self.finish('hello world')  @traced("phase-1") def views():     views_sub_2()     views_sub_3()  @traced("phase-2") def views_sub_2():     pass  @traced("phase-3") def views_sub_3():     pass  def applications():     urls = []     urls.append([r'/', TestFlow])     return tornado.web.Application(urls)  def main():     app = applications()     server = httpserver.HTTPServer(app)     server.bind(10000, '0.0.0.0')     server.start(1)     IOLoop.current().start()   if __name__ == "__main__":     try:         main()     except KeyboardInterrupt as e:         IOLoop.current().stop()     finally:         IOLoop.current().close()

jaeger-collector

docker run -d --name jaeger-collector    -p 14250:14250    -p 14268:14268    -p 14317:4317    -p 14318:4318    -e SPAN_STORAGE_TYPE=elasticsearch    -e ES_SERVER_URLS=http://10.22.12.178:9200    -e ES_USERNAME=elastic    -e LOG_LEVEL=debug    jaegertracing/jaeger-collector:1.72.0

storage

这里使用es来充当storage

docker run -d --name jaeger-es      -e bootstrap.memory_lock=true      -e discovery.type=single-node      -p 9200:9200      -p 9300:9300      -e xpack.security.enabled=false      -e xpack.security.http.ssl.enabled=false      elastic/elasticsearch:9.1.2

jaeger-ui

docker run -d --name jaeger-query    -p 16686:16686    -p 16687:16687    -e SPAN_STORAGE_TYPE=elasticsearch    -e ES_SERVER_URLS=http://10.22.12.178:9200    -e ES_USERNAME=elastic    -e LOG_LEVEL=debug    jaegertracing/jaeger-query:1.72.0

来看下效果：

首先让上报程序上报trace数据： curl 127.0.0.1:10000
登录http://127.0.0.1:16686/查看

很好，数据已经正常上报了

小结

jaeger从1.35版本开始支持原生otlp协议，所以可以直接在sdk中使用otlp协议上报。如果是低版本的jaeger，需要使用jaeger grpc、jaeger thrift等协议
这里要非常小心版本对应的问题，文中jaeger的版本是1.72，而es的版本是9.1.2，如果版本不匹配，很容易报错。在低版本中，Jaeger Collector 在创建 ES 索引模板时，模板的格式不符合 Elasticsearch 8.x 新的要求造成的。ES 7.x 还接受某些字段是字符串，但 8.x 对 index_template 结构要求更严格，会直接拒绝了导致无法启动

新增数据处理层otel-collector

在jaeger-collector上做一层otel-collector做数据采集

对应的修改：

数据采集

... span_processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="http://127.0.0.1:4318/v1/traces")) ...

otel-collector

docker run -d --name=otel-collector      -v ./otel-collector-config.yaml:/etc/otelcol/config.yaml      -p 4317:4317      -p 4318:4318      otel/opentelemetry-collector:latest

配置完成，有位老哥说了，为啥要这么配置，本来我直接发到jaeger-collector就行了，现在多加一层otel-collector，多做了一层无用功，完全没必要啊

这位老哥的思路非常清晰，现在来仔细观察下otel-collector与jaeger-collector的区别

otel-collector与jaeger-collector

	otel-collector	jaeger-collector
作用范围	traces、metrics	只支持traces
协议	OTLP、prometheus、zipkin等多种协议	jaeger thrift、jaeger grpc，新版本也支持OTLP
后端支持	可以发到支持otel的后端，比如tempo、prometheus、logging，甚至是jaeger-collector	只能发到 Jaeger Collector

jaeger的出现早于opentelemetry，所以有部分系统是通过jaeger这一套逻辑构建的，但是后面慢慢发展，不但traces数据需要分析，还有metrics、logs等重要的数据也需要分析了，那opentelemetry的出现解决了这个问题，能采集需要的数据，并且otel-collector作为一个数据逐渐成为了数据中转中心。比如jaeger擅长分析traces，那就发到jaeger这一套生态中，包括jaeger-collector、jaeger-UI等；prometheus擅长分析metrics数据，那就将metrics发到prometheus里面去
所以在jaeger-collector之前新增otel-collector，并没有增加系统冗余，而是解耦了jaeger与数据采集，并且丰富了系统功能性

otel-collector采集metrics

otel-collector

修改otel-collector-config.yaml

receivers: ...   hostmetrics:     collection_interval: 10s     scrapers:       cpu: {}       memory: {}       disk: {}       filesystem: {}       network: {}  exporters: ...   prometheus:     endpoint: "0.0.0.0:9464"     namespace: otelcol  service: ...     metrics:       receivers: [hostmetrics]       exporters: [prometheus]

暴露9464端口，等prometheus来拉取

docker run -d --name=otel-collector    -v ./otel-collector-config.yaml:/etc/otelcol/config.yaml    -p 4317:4317    -p 4318:4318    -p 9464:9464    otel/otel-collector:latest

prometheus

prometheus.yml

global:   scrape_interval: 5s  scrape_configs:   - job_name: "otel-collector"     static_configs:       - targets: ["10.22.12.178:9464"]

docker run -d --name prometheus    -p 9090:9090    -v ./prometheus.yml:/etc/prometheus/prometheus.yml    prom/prometheus:v3.5.0

检查prometheus，metrics数据已经获取

traces转换为metrics

提取traces耗时

将traces数据转换为metrics，比如文中有3段span phase-1 phase-2 phase-3，分别将它们的耗时时间转换成metrics存入prometheus，便于分析

1）修改otel-collector-config.yaml

receivers:   otlp:     protocols:       grpc:         endpoint: 0.0.0.0:4317       http:         endpoint: 0.0.0.0:4318    hostmetrics:     collection_interval: 10s     scrapers:       cpu: {}       memory: {}       disk: {}       filesystem: {}       network: {}  connectors:   spanmetrics:     dimensions:       - name: operation  exporters:   otlp:     endpoint: 10.22.12.178:14317     tls:       insecure: true   prometheus:     endpoint: "0.0.0.0:9464"     namespace: otelcol  service:   pipelines:     traces:       receivers: [otlp]       exporters: [otlp, spanmetrics]     metrics:       receivers: [hostmetrics, spanmetrics]       exporters: [prometheus]

2）重新运行镜像

docker run -d --name=otel-collector    -v ./otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml    -p 4317:4317    -p 4318:4318    -p 9464:9464    otel/opentelemetry-collector-contrib:0.132.3

这里需要非常小心了，由于需要对数据处理，使用了spanmetrics插件，而该插件只能在opentelemetry-collector-contrib才有，如果用opentelemetry-collector是没有的

3）上报trace数据： curl 127.0.0.1:10000，查看prometheus

耗时也是能够对应起来的

提取traces的attribute

1）先修改下采集程序，注入attribute

... def traced(name):     def decorator(func):         def wrapper(*args, **kwargs):             tracer = get_tracer(__name__)             with tracer.start_as_current_span(name) as span:                 span.set_attribute("addr", "cd") # 注入属性                 return func(*args, **kwargs)         return wrapper     return decorator ...

2）修改otel-collector配置

otel-collector-config.yaml

... connectors:   spanmetrics:     dimensions:       - name: operation       - name: addr # 提取属性 ...

3）上报trace数据： curl 127.0.0.1:10000，查看prometheus

小结

先从jaeger出发，从all-in-one的测试架构改造成可在生产环境使用的架构jaeger-collector --> es storage --> jaeger-UI
新增数据处理层otel-collector，使得整个数据采集更灵活，不但可以采集traces、也可以采集metrics
otel-collector不但做数据转发，也可以做数据修改