trace使用jaeger还是zipkin？

trace

接上一遍文章，上次说到通过otel观测微服务，在收集和可视化trace数据时候，我是用的是zipkin，但是zipkin有个问题，就是在高并发下，zipkin经常假死，根本访问不了，写入数据失败，而且还有大量的 wget - health。之前我通过加大内存到2G也没有解决该问题，于是我还是另辟蹊径，使用jaeger来做trace的处理和可视化。

jaeger

由于我是先试验性看下jaeger会不会在高并发下也会存在此等问题，于是我使用官网推荐的 jaegertracing/all-in-one 镜像来部署。部署脚本如下

  docker run -d --name jaeger-once \
  -p 16686:16686 \
  -e MEMORY_MAX_TRACES=100000 \
  -m 2GB \
  jaegertracing/all-in-one:1.21

其实部署这些容器并不难，难就难在找到适合你想要的配置。就像这里，我找半天才找到 环境变量 MEMORY_MAX_TRACES 是限制内存最大保存trace数量，这个可以查看官网说明，memory.max_traces 的驼峰就是他的环境变量。因为all-in-one镜像是内存存储数据的，所以这里必须要限制下他的大小，否则当你的数据过大时候内存就会长满，那时候再去修改你就只能重启服务器了，切记要慎重。。。
还有为了保险，我通过-m 设置该容器最大可使用内存的大小。
由于jaeger支持otel grpc，所以我们再collector 配置上，更改trace的exporter就行。修改如下

exporters:
  otlp/jaeger:
    endpoint: <your jaeger ip:4317>
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/jaeger]
 

这样子 trace数据就会通过grpc方式发送到jaeger了，尝试了下，再高并发下，依然稳定通过jaeger查询trace数据，可靠。于是就使用jaeger了，后面如果要把数据持久化起来，就需要部署jaeger的 collector ，query这两个镜像，通过配置collector 的存储为es就可以把数据存储到es中，然后通过query查询trace数据。这里就不需要部署agent了，因为我们有了otel collector ，已经把数据收集起来了，所以只需要转发给不同的组件处理就行 了。好了今天就这样，lets do it yourself