Zipkin Docker Compose 部署实战从内存存储到多后端集成的完整示例指南【免费下载链接】zipkinZipkin is a distributed tracing system项目地址: https://gitcode.com/gh_mirrors/zip/zipkin导读本文基于 Zipkin 官方仓库 docker/examples/README.md 及 docker/examples 目录下的全部 compose 文件系统讲解如何用 Docker Compose 一键拉起 Zipkin 分布式追踪系统从默认的内存存储快速体验到接入 Cassandra / Elasticsearch / MySQL 持久化存储再到集成 ActiveMQ / Kafka / RabbitMQ / Pulsar 消息传输、Eureka 服务发现、Prometheus 监控以及 NGINX 反代 UI 等完整链路。读完本文你将掌握所有示例 compose 文件的用途、启动命令、关键环境变量与常见问题能够根据自己的场景拼装出可运行的 Zipkin 演示或测试环境。前置说明示例是学习用途不是生产模板仓库中的 docker/examples/docker-compose.yml 在文件头部就明确声明了定位该文件用于学习 Zipkin而非生产部署this file is meant for learning Zipkin, not production deployments。它默认使用openzipkin/zipkin-slim精简镜像仅支持内存存储和 HTTP/gRPC 收集器。当你需要接入 Cassandra、MySQL、Kafka 等能力时各扩展 compose 文件会通过extends机制把zipkin服务切换为功能完整的openzipkin/zipkin大镜像详见下文各小节。生产部署的环境变量全集以 zipkin-server 文档 为准。快速开始默认 compose 配置启动命令进入 docker/examples 目录后执行默认配置即可启动 Zipkin# 使用 Zipkin 最新正式发布版本 $ docker compose up # 使用仓库最新构建版本master 分支镜像 $ TAGmaster docker compose up这里值得留意TAG变量它在所有示例 compose 文件中都以${TAG:-latest}的形式参与镜像标签解析如 docker-compose.yml 中的ghcr.io/openzipkin/zipkin-slim:${TAG:-latest}。因此默认拉取的是latest标签需要追踪每日构建或某次 CI 构建时通过TAGmaster等显式覆盖即可。默认 compose 内容解读默认的 docker-compose.yml 只有一个zipkin服务其关键配置services: zipkin: image: ghcr.io/openzipkin/zipkin-slim:${TAG:-latest} container_name: zipkin environment: - STORAGE_TYPEmem # 内存存储 # - SELF_TRACING_ENABLEDtrue # 取消注释可开启自追踪 # - JAVA_OPTS-Xms128m -Xmx128m -XX:ExitOnOutOfMemoryError # 取消注释可加大堆内存 ports: - 9411:9411 # Zipkin UI 与 HTTP API 端口 # command: --logging.level.zipkin2DEBUG # 取消注释可开启调试日志几个实用配置点STORAGE_TYPEmem明确使用内存存储即 docker/README.md 中所说的Zipkin 无依赖可直接以内存模式运行。默认容器zipkin镜像会设置JAVA_OPTS最大堆为 64mzipkin-slim为 32m如需调大可按上面的示例覆盖。SELF_TRACING_ENABLEDtrue开启 Zipkin 对自身的追踪self-tracing可用于观察 Zipkin 自身的处理性能。--logging.level.zipkin2DEBUG通过command覆盖日志级别排查问题时非常有用docker/README.md 中也给出了同样写法。JAVA_OPTS可携带-Xms/-Xmx堆参数、-XX:ExitOnOutOfMemoryError兜底退出策略或 trust store 位置等 JVM 参数。查看 UI 与制造追踪数据启动后用浏览器打开$(docker ip):9411在 Linux 本机即http://localhost:9411。追踪数据默认存在内存中。要在 UI 中看到具体 trace需要先在服务下拉框中选择zipkin-server再点击 Find Traces 按钮——这是因为内存模式下没有任何应用向 Zipkin 上报 span唯一的数据来源就是 Zipkin 自身它会把自己作为服务zipkin-server记录这一操作在 docker/README.md 中也有同样的提示。用-f指定扩展 compose 文件两种拼装方式仓库的所有扩展文件都使用 Docker Compose 的override多文件覆盖机制因此实际运行时常会看到两类命令直接指定某个独立 compose 文件该文件内部已通过extends引用docker-compose.yml与docker-compose-dependencies.yml例如 Cassandra、Elasticsearch、MySQL、Kafka、ActiveMQ 等场景$ docker compose -f docker-compose-cassandra.yml up多个 compose 文件叠加按顺序后面的覆盖前面例如 Eureka、Example、UI、UI Proxy、Prometheus 场景文档中均以docker compose -f docker-compose.yml -f docker-compose-xxx.yml up的形式给出。使用-f时compose 会读取当前目录下的对应文件示例文件互相引用依赖的都是仓库内相对路径请保持 docker/examples 目录结构完整。存储后端Cassandra / Elasticsearch / MySQL这三个配置文件都属于持久化存储场景且都额外启动了zipkin-dependenciescron 任务容器用于每小时定期计算服务依赖图。它们引用的公共依赖任务定义在 docker-compose-dependencies.yml。Cassandradocker-compose-cassandra.yml$ docker compose -f docker-compose-cassandra.yml up该配置docker-compose-cassandra.yml启动三个容器storageghcr.io/openzipkin/zipkin-cassandra预先初始化好 Zipkin schema 的 Cassandra。注释中还保留了切换到 DataStax DSE 的写法datastax/dse-server:5.1.20需设置DS_LICENSEacceptDSE 最低支持 5.1 版本。zipkin通过extends继承默认配置后切换到完整镜像openzipkin/zipkin并设置STORAGE_TYPEcassandra3。其注释明确指出slim 镜像不含 Cassandra 支持必须换用大镜像。其余关键变量CASSANDRA_ENSURE_SCHEMAfalse使用测试镜像时 schema 已预装无需 Zipkin 自行确保 schema。CASSANDRA_CONTACT_POINTScassandra指向 compose 网络中的 storage 容器。可选的CASSANDRA_USERNAME/CASSANDRA_PASSWORD取消注释可配置认证。注释中的--logging.level.com.datastax.oss.driver.internal.core.tracker.RequestLoggerTRACE可开启请求日志TRACE 级别会输出查询参数值。dependenciesSTORAGE_TYPE${STORAGE_TYPE:-cassandra3}CASSANDRA_CONTACT_POINTScassandra从 Cassandra 读取 span 计算依赖。手动触发依赖计算zipkin-dependencies是每小时运行一次的定时任务若想提前看到依赖图可在另一个终端手动执行$ docker compose -f docker-compose-cassandra.yml run --rm --no-deps --entrypoint start-zipkin-dependencies dependencies--rm表示运行完即删除容器--no-deps跳过依赖服务启动--entrypoint start-zipkin-dependencies指定入口脚本。Elasticsearchdocker-compose-elasticsearch.yml$ docker compose -f docker-compose-elasticsearch.yml up该配置docker-compose-elasticsearch.yml使用ghcr.io/openzipkin/zipkin-elasticsearch9测试镜像Elasticsearch 9.x仓库同时提供了 8.x 与 9.x 两版测试镜像见 docker/README.md并将 zipkin 指向它STORAGE_TYPEelasticsearch、ES_HOSTSelasticsearch:9200以 compose 服务名作为主机名。注释中的ES_HTTP_LOGGINGBODY可开启对 Elasticsearch 请求/响应体的日志便于调试。dependencies同样使用STORAGE_TYPEelasticsearch与ES_HOSTSelasticsearch。手动触发依赖计算与 Cassandra 场景写法一致只是换用对应文件$ docker compose -f docker-compose-elasticsearch.yml run --rm --no-deps --entrypoint start-zipkin-dependencies dependenciesMySQLdocker-compose-mysql.yml$ docker compose -f docker-compose-mysql.yml up该配置docker-compose-mysql.yml使用ghcr.io/openzipkin/zipkin-mysql测试镜像已初始化 Zipkin 的 MySQL schemaschema 结构以 zipkin-storage/mysql-v1 文档 为准zipkin 与 dependencies 的关键配置environment: - STORAGE_TYPEmysql - MYSQL_HOSTstorage # 使用 zipkin-mysql 镜像内置的账号密码 - MYSQL_USERzipkin - MYSQL_PASSzipkin提示如果使用外部MySQL 服务器或镜像需自行确保 schema 及其他参数与 zipkin-storage/mysql-v1/README.md 中 Applying the schema 一节一致这一点在 docker/README.md 中有明确说明。消息传输ActiveMQ / Kafka / RabbitMQ / Pulsar这四类配置的共同点是在 HTTP 上报之外额外提供一个消息中间件作为 span 传输通道。它们都新增一个独立的中间件容器并把 zipkin 切换为完整镜像slim 不含这些 collector 支持通过环境变量把 Zipkin 的 collector 指向中间件。场景配置文件中间件容器Zipkin 侧环境变量应用侧上报配置ActiveMQdocker-compose-activemq.ymlzipkin-activemq暴露61616:61616ACTIVEMQ_URLfailover:tcp://activemq:61616senderbrokerUrl设为failover:tcp://localhost:61616docker 内则用非 localhost 主机名Kafkadocker-compose-kafka.ymlzipkin-kafkaKafkaZooKeeper暴露19092:19092KAFKA_BOOTSTRAP_SERVERSkafka:9092senderbootstrapServers设为host.docker.internal:9092应用与 Zipkin 同 docker 网络或localhost:19092应用在本机RabbitMQdocker-compose-rabbitmq.ymlzipkin-rabbitmq暴露5672:5672RABBIT_ADDRESSESrabbitmq:5672senderhost设为localhostdocker 内则用非 localhost 主机名Pulsardocker-compose-pulsar.ymlzipkin-pulsar暴露6650:66508080HTTP 端口默认注释PULSAR_SERVICE_URLpulsar://pulsar:6650按 Pulsar 客户端配置对应服务地址启动命令统一为以 Kafka 为例$ docker compose -f docker-compose-kafka.yml up应用侧 sender 的地址选择重点这是文档着墨最多的实操细节以 Kafka 为例如果你的示例应用与 Zipkin 在同一个 docker 网络内bootstrapServers应设为host.docker.internal:9092如果你的应用跑在笔记本宿主机上则用localhost:19092向运行在 Docker 里的 Kafka broker 发送 spancompose 已把 19092 端口映射到宿主机。Docker Machine 与 Kafka 的适配若使用 Docker Machine远程 Docker 主机需要同步修改两处让两者指向同一个可达地址在 docker-compose-kafka.yml 中取消注释并设置KAFKA_ADVERTISED_HOST_NAME192.168.99.100改为你的 Docker 主机 IP将 Kafka sender 的bootstrapServers改为192.168.99.100:19092。这是因为 Kafka 会向客户端公布KAFKA_ADVERTISED_HOST_NAME只有公布地址与客户端实际连接地址一致时才能建立连接。服务发现Eurekadocker-compose-eureka.yml工作流程该配置docker-compose-eureka.yml演示了Zipkin 注册到 Eureka 示例服务从 Eureka 发现 Zipkin的完整闭环zipkin启动时通过EUREKA_SERVICE_URLhttp://eureka:8761/eureka/v2和EUREKA_HOSTNAMEzipkin把自己的 endpoint 注册进 Eurekafrontend、backend两个示例服务同样配置EUREKA_SERVICE_URL从 Eureka 发现 Zipkin 的 endpoint并据此上报 spanEureka 容器ghcr.io/openzipkin/zipkin-eureka默认不暴露端口注释中保留了8761:8761的调试选项以及EUREKA_USERNAME/EUREKA_PASSWORD的认证配置。启动命令需要与默认配置叠加$ docker compose -f docker-compose.yml -f docker-compose-eureka.yml up注意Eureka 场景的 compose 文件内部已经定义了frontend和backend服务因此它同时覆盖了下一节的 example 场景两者不必重复叠加。端到端示例应用brave-exampledocker-compose-example.ymlbrave-example 通过 compose override 机制新增frontend与backend两个服务镜像为ghcr.io/openzipkin/brave-example:${PROJECT:-armeria}默认使用 armeria 变体也可用PROJECT环境变量切换其他框架变体frontend暴露8081:8081。启动$ docker compose -f docker-compose.yml -f docker-compose-example.yml up验证步骤文档原文给出可完整照做打开http://localhost:8081/该页面会调用后端http://localhost:9000/api并展示其结果一个格式化后的日期这就在系统里制造了一条真实 trace之后访问http://localhost:9411/zipkin?serviceNamebackend即可查看经过 backend 服务的追踪数据。UI 托管docker-compose-ui.ymlzipkin-ui 是独立于 zipkin-server 的 UI 容器用 NGINX 托管 Lens UI。docker-compose-ui.yml 通过 override 机制新增一个 NGINX 容器监听 80 端口及相应配置$ docker compose -f docker-compose.yml -f docker-compose-ui.yml up该容器同时是为 Zipkin 搭建反向代理的骨架模板你可以在此基础上增加认证、处理 zipkin-js 应用的 CORS、或终止 SSL。将 zipkin-ui 独立运行并指向远程 Zipkin 服务设置ZIPKIN_BASE_URL即可$ docker run -d -p 80:80 \ -e ZIPKIN_BASE_URLhttp://myfavoritezipkin:9411 \ openzipkin/zipkin-uiUI Proxydocker-compose-uiproxy.ymldocker-compose-uiproxy.yml 与 UI 场景类似但它是专门用来验证ZIPKIN_UI_BASEPATH变量的代理配置它将该变量设为/admin/zipkin启动后可通过http://localhost/admin/zipkin/访问 Zipkin UI$ docker compose -f docker-compose.yml -f docker-compose-uiproxy.yml up这演示了把 Zipkin UI 挂载在某个子路径如统一网关/admin/zipkin背后的真实用法对部署在已有反向代理之后的场景很有参考价值。监控Prometheus Grafanadocker-compose-prometheus.ymlZipkin 内置 Prometheus 指标导出器。docker-compose-prometheus.yml启动三个附加容器prometheusquay.io/prometheus/prometheus:v3.10.0暴露9090挂载 prometheus/prometheus.yml 作为抓取配置定时抓取 Zipkin 的/prometheus指标端点grafanaquay.io/giantswarm/grafana:11.6.7暴露3000通过GF_AUTH_ANONYMOUS_ENABLEDtrue与GF_AUTH_ANONYMOUS_ORG_ROLEAdmin关闭认证方便本地体验setup_grafana_datasourcequay.io/curl/curl-base:8.18.0启动时执行 prometheus/create-datasource-and-dashboard.sh自动把 Prometheus 注册为 Grafana 数据源并导入 Zipkin 的 Prometheus 仪表盘。启动命令需叠加默认配置$ docker compose -f docker-compose.yml -f docker-compose-prometheus.yml up启动后打开$DOCKER_HOST_IP:9090直接探索 Prometheus 指标来自 Zipkin 的/prometheus端点打开$DOCKER_HOST_IP:3000/dashboard/db/zipkin-prometheus体验 Grafana 仪表盘。关于镜像来源配置文件中的注释特别说明Prometheus/Grafana/curl 镜像均使用quay.io镜像源以避免 Docker Hub 拉取配额导致的构建中断——如果你的网络环境访问 quay.io 更稳定这本身也是一条可复用的部署经验。常见问题与排查要点slim 镜像不支持扩展能力只要涉及 Cassandra / MySQL / Kafka / ActiveMQ / RabbitMQ / Pulsar 任一能力compose 文件都会显式切回openzipkin/zipkin大镜像。若自行修改镜像为 slim 后功能消失属预期行为。容器健康检查依赖各扩展文件普遍使用depends_on: { condition: service_healthy }确保存储/中间件就绪后 Zipkin 才启动测试镜像如zipkin-cassandra都会先初始化好 schema 并报告健康状态。Kafka 连不上优先核对KAFKA_ADVERTISED_HOST_NAME与 senderbootstrapServers是否指向同一个可达地址特别是 Docker Machine 场景。日志排查将command设为--logging.level.zipkin2DEBUG可看到收集器与存储调用细节Elasticsearch 场景还可开ES_HTTP_LOGGINGBODY查看 ES 请求内容。镜像标签所有镜像均使用${TAG:-latest}模板需要追踪最新构建时可TAGmaster docker compose ... up。参考与示例配套的镜像体系docker/examples 中引用的测试镜像全部构建自 docker/test-images 目录包括zipkin-activemq、zipkin-cassandra、zipkin-elasticsearch8/9、zipkin-opensearch2、zipkin-eureka、zipkin-kafka、zipkin-mysql、zipkin-pulsar、zipkin-rabbitmq、zipkin-ui等完整列表见 docker/README.md。这些镜像小而快复用openzipkin/zipkin基础层专为演示与集成测试设计生产环境请使用 docker/Dockerfile 构建的openzipkin/zipkin/openzipkin/zipkin-slim正式镜像并按 zipkin-server/README.md 的环境变量全集进行配置。【免费下载链接】zipkinZipkin is a distributed tracing system项目地址: https://gitcode.com/gh_mirrors/zip/zipkin创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考