Apache Pulsar 生产部署Docker 单机集群与 Prometheus 监控的最小可行路径【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址: https://gitcode.com/gh_mirrors/pulsar28/pulsarApache Pulsar 是一套支持多租户的分布式发布订阅消息系统。这篇 Apache Pulsar 生产部署实战带你用 docker-compose 拉起 ZooKeeper、Bookie、Broker、Proxy 完整集群再接上 Prometheus 和 Grafana让 Pulsar Docker 服务从黑盒变成可观测的白盒。先想清楚你的场景在动手拉容器之前先确认你的负载形态它决定了集群规模高吞吐数据管道日志、埋点类 topic 每天写入几十亿条要求 bookie 层 HA 和磁盘隔离开发机上跑不出这种压力画像。低延迟在线消费风控、计费场景对投递 P99 有硬性预算broker 抖动直接打进你的 SLA需要独立部署和监控告警。多团队共享集群不同业务线共享 namespace靠资源配额和背压策略隔离配置项和权限模型必须按生产标准来。部署前先把下表过一遍缺一项都会在后面卡住项目本文基线说明Docker / Compose20.10 以上 / v2官方镜像 docker/pulsar/Dockerfile 基于 Ubuntu 20.04 OpenJDK 11 构建GPU / 显存不需要Pulsar 是 JVM 服务无 GPU 依赖资源以内存和磁盘为核心运行时语言环境Java 11镜像内置客户端语言不限Python 客户端由install-pulsar-client.sh预装主机规格16 vCPU / 64 GB / 400 GB SSDbookie 是磁盘密集型务必用 SSD单节点跑满 9 容器建议内存 ≥48 GB网络端口6650 / 8000 / 8080 / 9090 / 3000业务与监控端口详见 Checklist部署路径怎么选方式适用规模复杂度运维成本推荐度源码解压裸机个人验证、压测机低低但环境漂移全靠人肉★★Docker 单容器standalone单节点演示、集成测试低低★★★docker-compose 多服务单机模拟完整集群≤10 节点规模中中★★★★本文路线Kubernetes / Helm多团队、多集群、需弹性扩缩高高按需单机起步就选 docker-compose它用 1 台机器模拟出 zk×3 bookie×3 broker×3 proxy 的分布式拓扑升级和回滚只需要换镜像 tag仓库里现成的 kitchen-sink 编排文件 可以直接当脚手架。K8s 留给多集群、需要滚动升级和自动伸缩的阶段本文不展开。把 Pulsar 塞进容器镜像怎么建这段解决只装我需要的 NAR不让官方大镜像膨胀到 3 GB的问题基于官方镜像做多阶段构建只挑连接器。# 以官方 release tag 锁定版本禁止在生产使用 latest FROM apachepulsar/pulsar-all:2.10.6 AS builder # 基础镜像只有 broker/bookie/zk 二进制约 1.6 GB FROM apachepulsar/pulsar:2.10.6 # 只把用到的 NAR 连接器拷进镜像 COPY --frombuilder /pulsar/connectors/pulsar-io-cassandra-*.nar /pulsar/connectors # 分层缓存只有 NAR 变更才重建 COPY ./pulsar-custom/ /pulsar/connectors # 官方镜像默认以非 root 用户 10000 运行安全基线别改 USER 10000官方镜像本身是多阶段构建busybox 阶段解包二进制Ubuntu 阶段装 JDK 11 和 Python 依赖最后切到非 root 用户细节见 Docker 构建说明。生产上建议直接用 release tag而不是自己mvn打包后塞进去。服务怎么编排这段解决单机上把 Pulsar 的分布式角色拆成独立容器、并能一键重建的问题# 片段取自仓库 kitchen-sink生产按需裁剪 services: zk1: # ZooKeeper元数据三副本 image: apachepulsar/pulsar:2.10.6 command: exec bin/pulsar zookeeper environment: { ZOOKEEPER_SERVERS: zk1,zk2,zk3 } bk1: # Bookie消息落盘 image: apachepulsar/pulsar:2.10.6 command: exec bin/pulsar bookie environment: { zkServers: zk1:2181,zk2:2181,zk3:2181 } broker1: # Broker消息进出 image: apachepulsar/pulsar:2.10.6 command: exec bin/pulsar broker environment: zookeeperServers: zk1:2181,zk2:2181,zk3:2181 configurationStoreServers: zk1:2181,zk2:2181,zk3:2181 ports: - 6650:6650 # 客户端二进制协议 - 8080:8080 # HTTP 服务 /metrics prometheus: # 独立容器只负责抓取与存储 image: prom/prometheus:2.47.0 ports: [9090:9090] volumes: [ ./prometheus.yml:/etc/prometheus/prometheus.yml ] grafana: # 独立容器负责展示与抓取解耦 image: grafana/grafana:10.2.3 ports: [3000:3000]Prometheus 和 Grafana 必须单独拆容器它们与 Pulsar 生命周期完全无关Pulsar 滚动升级时监控不能断单独容器也让抓取目标broker1:8080和展示层各自独立扩缩互不拖累。消息与状态放哪Pulsar 是数据系统而非模型服务这里的数据分三类挂载策略不同Ledger 数据核心数据bookie 的消息落盘目录挂到宿主机 SSD 独立目录并持久化docker compose重建容器不能丢数据。ZooKeeper 状态三节点各挂独立卷初始化状态/initialized-cluster存在这里误删等于集群清零。NAR / 分层存储 offloader随镜像分层走不走卷升级即换 tag天然可回滚。官方镜像把配置注入做成了运行时环境变量 →bin/apply-config-from-env.py渲染到conf/*.conf的机制所以你不需要为每套环境重新打镜像compose 里的environment就是配置入口PULSAR_MEM也是这条路。让服务从黑盒到白盒Pulsar Prometheus 指标采集Pulsar 各组件原生暴露 Prometheus 格式端点Broker 在:8080/metricsbookie 在:8000/metricsconf/bookkeeper.conf已默认启用PrometheusMetricsProviderZooKeeper 在:8000/:8001/metrics。抓取配置见 监控文档。暴露哪些指标指标类型为什么关心pulsar_topics_in/pulsar_topics_outCounter分区级收发速率容量规划和限流的第一手数据pulsar_backlog_sizeGauge积压字节数消费延迟和存储容量的领先指标pulsar_num_consumersGauge消费组规模突变能最早暴露消费者掉线jvm_memory_bytesGauge堆 堆外用量OOM 前兆告警必接jvm_gc_collection_secondsHistogramGC 停顿直接决定投递 P99pulsar_replication_rateGauge跨集群同步速率geo 容灾链路是否追得上的唯一口径topic / consumer / producer / cursor 级别指标默认关闭按需要在 conf/broker.conf 打开exposeConsumerLevelMetricsInPrometheus、exposeProducerLevelMetricsInPrometheus等。topic 数上万时把metricsServletTimeoutMs调大避免 /metrics 被掐断。最小可用监控栈# prometheus.yml只列核心目标端口与 compose 保持一致 scrape_configs: - job_name: pulsar static_configs: - targets: [broker1:8080, bk1:8000, zk1:8000]Grafana 导入零配置仓库 grafana/dashboards/ 内置 broker、bookkeeper、zookeeper、namespace、topic、jvm 六份 JSON 面板在 Dashboards → Import 里逐个导入数据源指向http://prometheus:9090即可。日志别乱打级别生产默认INFO官方镜像已设PULSAR_ROOT_LOGGERINFO,CONSOLEDEBUG 只用于临时排障窗口用完必须关回。结构化字段每条日志带componentbroker/bookie/zk、cluster、namespace没有这三个字段多集群排障只能靠猜。统一走 log4j2禁止用print或echo替代 logger自定义 Functions 和 IO connector 的日志接入 conf/log4j2.yaml 同一套输出链路。Pulsar 容器化上线 Checklist镜像 tag 固定到具体版本2.10.6全环境禁用latestcompose 文件TLS 证书、token 密钥放 secret 管理器运行时注入不落镜像broker.conf的 TLS 段每容器 JVM 限额留 30% 余量-Xms2g -Xmx2g -XX:MaxDirectMemorySize4g是默认按实际容量改conf/pulsar_env.sh 的PULSAR_MEMdocker compose ps全部 Up 后浏览器逐个验证zk1:8000/metrics、bk1:8000/metrics、broker1:8080/metrics可访问回滚路径演练过一次旧 tag 镜像仍保留在本地 registrydocker pull可秒级恢复ZooKeeper snapshot 与 bookie ledgers 每日备份并落异地存储运维手册包含端口表6650/8000/8080/9090/3000与pulsar-admin常用命令告警分级写死backlog 持续增长 10 min → P1pulsar_num_consumers归零 → P1GC P99 2s 持续 5 min → P2客户端到 proxy 的 6650 走内网公网只暴露 proxy 且开 TLSexposeTopicLevelMetricsInPrometheus等指标开关与实际 topic 规模匹配防止 /metrics 超时broker.conf大概率会踩的 3 个坑1. OOM容器反复被 kill现象docker inspect bk1 | grep -i oom出现OOMKilled: true压测流量一上就复现。原因Pulsar 同时吃堆内存和堆外 direct memory默认 2g 堆 4g 堆外宿主机分给容器的内存不够。解法# compose environment 中按实际容量设置 PULSAR_MEM-Xms1g -Xmx1g -XX:MaxDirectMemorySize2g2. 端口冲突单机全角色同机跑不起来现象bookie 或 broker 启动即失败日志出现Address already in use。原因bookie 的 Prometheus 端口默认 8000与本地 ZooKeeper stats 端口8000/8001在同一宿主机混部时撞车。解法# conf/bookkeeper.conf prometheusStatsHttpPort8002 # 同步更新 prometheus.yml 的 targets3. Bookie 卡死不启动现象watch-znode.py一直等/initialized-clusterbookie/broker 全部挂起。原因集群元数据未初始化或 ZooKeeper 数据卷被清掉了。解法docker compose up -d pulsar-init # 重跑 [init-cluster.sh](https://link.gitcode.com/i/7bdec2d9e6a969ab0e9da85eaa5c03c3)接下来可以看什么到这里你已经有一套能收发消息、指标可抓、面板可见的生产形态 Pulsar。上面是最短闭环离真实生产还差 TLS 认证、分层存储和跨集群复制这些层。继续深入可以从这三处入手镜像构建与裁剪逻辑看 Docker 构建说明完整集群编排参考 kitchen-sink compose指标开关和端点细节看 监控文档 与 Grafana 面板。本文覆盖的是最小可行路径生产规模请按团队情况扩展。【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址: https://gitcode.com/gh_mirrors/pulsar28/pulsar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/3 19:14:34 · 阅读 1.2k Apache Pulsar 生产部署：Docker 单机集群与 Prometheus 监控的最小可行路径
Apache Pulsar 生产部署Docker 单机集群与 Prometheus 监控的最小可行路径【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址: https://gitcode.com/gh_mirrors/pulsar28/pulsarApache Pulsar 是一套支持多租户的分布式发布订阅消息系统。这篇 Apache Pulsar 生产部署实战带你用 docker-compose 拉起 ZooKeeper、Bookie、Broker、Proxy 完整集群再接上 Prometheus 和 Grafana让 Pulsar Docker 服务从黑盒变成可观测的白盒。先想清楚你的场景在动手拉容器之前先确认你的负载形态它决定了集群规模高吞吐数据管道日志、埋点类 topic 每天写入几十亿条要求 bookie 层 HA 和磁盘隔离开发机上跑不出这种压力画像。低延迟在线消费风控、计费场景对投递 P99 有硬性预算broker 抖动直接打进你的 SLA需要独立部署和监控告警。多团队共享集群不同业务线共享 namespace靠资源配额和背压策略隔离配置项和权限模型必须按生产标准来。部署前先把下表过一遍缺一项都会在后面卡住项目本文基线说明Docker / Compose20.10 以上 / v2官方镜像 docker/pulsar/Dockerfile 基于 Ubuntu 20.04 OpenJDK 11 构建GPU / 显存不需要Pulsar 是 JVM 服务无 GPU 依赖资源以内存和磁盘为核心运行时语言环境Java 11镜像内置客户端语言不限Python 客户端由install-pulsar-client.sh预装主机规格16 vCPU / 64 GB / 400 GB SSDbookie 是磁盘密集型务必用 SSD单节点跑满 9 容器建议内存 ≥48 GB网络端口6650 / 8000 / 8080 / 9090 / 3000业务与监控端口详见 Checklist部署路径怎么选方式适用规模复杂度运维成本推荐度源码解压裸机个人验证、压测机低低但环境漂移全靠人肉★★Docker 单容器standalone单节点演示、集成测试低低★★★docker-compose 多服务单机模拟完整集群≤10 节点规模中中★★★★本文路线Kubernetes / Helm多团队、多集群、需弹性扩缩高高按需单机起步就选 docker-compose它用 1 台机器模拟出 zk×3 bookie×3 broker×3 proxy 的分布式拓扑升级和回滚只需要换镜像 tag仓库里现成的 kitchen-sink 编排文件 可以直接当脚手架。K8s 留给多集群、需要滚动升级和自动伸缩的阶段本文不展开。把 Pulsar 塞进容器镜像怎么建这段解决只装我需要的 NAR不让官方大镜像膨胀到 3 GB的问题基于官方镜像做多阶段构建只挑连接器。# 以官方 release tag 锁定版本禁止在生产使用 latest FROM apachepulsar/pulsar-all:2.10.6 AS builder # 基础镜像只有 broker/bookie/zk 二进制约 1.6 GB FROM apachepulsar/pulsar:2.10.6 # 只把用到的 NAR 连接器拷进镜像 COPY --frombuilder /pulsar/connectors/pulsar-io-cassandra-*.nar /pulsar/connectors # 分层缓存只有 NAR 变更才重建 COPY ./pulsar-custom/ /pulsar/connectors # 官方镜像默认以非 root 用户 10000 运行安全基线别改 USER 10000官方镜像本身是多阶段构建busybox 阶段解包二进制Ubuntu 阶段装 JDK 11 和 Python 依赖最后切到非 root 用户细节见 Docker 构建说明。生产上建议直接用 release tag而不是自己mvn打包后塞进去。服务怎么编排这段解决单机上把 Pulsar 的分布式角色拆成独立容器、并能一键重建的问题# 片段取自仓库 kitchen-sink生产按需裁剪 services: zk1: # ZooKeeper元数据三副本 image: apachepulsar/pulsar:2.10.6 command: exec bin/pulsar zookeeper environment: { ZOOKEEPER_SERVERS: zk1,zk2,zk3 } bk1: # Bookie消息落盘 image: apachepulsar/pulsar:2.10.6 command: exec bin/pulsar bookie environment: { zkServers: zk1:2181,zk2:2181,zk3:2181 } broker1: # Broker消息进出 image: apachepulsar/pulsar:2.10.6 command: exec bin/pulsar broker environment: zookeeperServers: zk1:2181,zk2:2181,zk3:2181 configurationStoreServers: zk1:2181,zk2:2181,zk3:2181 ports: - 6650:6650 # 客户端二进制协议 - 8080:8080 # HTTP 服务 /metrics prometheus: # 独立容器只负责抓取与存储 image: prom/prometheus:2.47.0 ports: [9090:9090] volumes: [ ./prometheus.yml:/etc/prometheus/prometheus.yml ] grafana: # 独立容器负责展示与抓取解耦 image: grafana/grafana:10.2.3 ports: [3000:3000]Prometheus 和 Grafana 必须单独拆容器它们与 Pulsar 生命周期完全无关Pulsar 滚动升级时监控不能断单独容器也让抓取目标broker1:8080和展示层各自独立扩缩互不拖累。消息与状态放哪Pulsar 是数据系统而非模型服务这里的数据分三类挂载策略不同Ledger 数据核心数据bookie 的消息落盘目录挂到宿主机 SSD 独立目录并持久化docker compose重建容器不能丢数据。ZooKeeper 状态三节点各挂独立卷初始化状态/initialized-cluster存在这里误删等于集群清零。NAR / 分层存储 offloader随镜像分层走不走卷升级即换 tag天然可回滚。官方镜像把配置注入做成了运行时环境变量 →bin/apply-config-from-env.py渲染到conf/*.conf的机制所以你不需要为每套环境重新打镜像compose 里的environment就是配置入口PULSAR_MEM也是这条路。让服务从黑盒到白盒Pulsar Prometheus 指标采集Pulsar 各组件原生暴露 Prometheus 格式端点Broker 在:8080/metricsbookie 在:8000/metricsconf/bookkeeper.conf已默认启用PrometheusMetricsProviderZooKeeper 在:8000/:8001/metrics。抓取配置见 监控文档。暴露哪些指标指标类型为什么关心pulsar_topics_in/pulsar_topics_outCounter分区级收发速率容量规划和限流的第一手数据pulsar_backlog_sizeGauge积压字节数消费延迟和存储容量的领先指标pulsar_num_consumersGauge消费组规模突变能最早暴露消费者掉线jvm_memory_bytesGauge堆 堆外用量OOM 前兆告警必接jvm_gc_collection_secondsHistogramGC 停顿直接决定投递 P99pulsar_replication_rateGauge跨集群同步速率geo 容灾链路是否追得上的唯一口径topic / consumer / producer / cursor 级别指标默认关闭按需要在 conf/broker.conf 打开exposeConsumerLevelMetricsInPrometheus、exposeProducerLevelMetricsInPrometheus等。topic 数上万时把metricsServletTimeoutMs调大避免 /metrics 被掐断。最小可用监控栈# prometheus.yml只列核心目标端口与 compose 保持一致 scrape_configs: - job_name: pulsar static_configs: - targets: [broker1:8080, bk1:8000, zk1:8000]Grafana 导入零配置仓库 grafana/dashboards/ 内置 broker、bookkeeper、zookeeper、namespace、topic、jvm 六份 JSON 面板在 Dashboards → Import 里逐个导入数据源指向http://prometheus:9090即可。日志别乱打级别生产默认INFO官方镜像已设PULSAR_ROOT_LOGGERINFO,CONSOLEDEBUG 只用于临时排障窗口用完必须关回。结构化字段每条日志带componentbroker/bookie/zk、cluster、namespace没有这三个字段多集群排障只能靠猜。统一走 log4j2禁止用print或echo替代 logger自定义 Functions 和 IO connector 的日志接入 conf/log4j2.yaml 同一套输出链路。Pulsar 容器化上线 Checklist镜像 tag 固定到具体版本2.10.6全环境禁用latestcompose 文件TLS 证书、token 密钥放 secret 管理器运行时注入不落镜像broker.conf的 TLS 段每容器 JVM 限额留 30% 余量-Xms2g -Xmx2g -XX:MaxDirectMemorySize4g是默认按实际容量改conf/pulsar_env.sh 的PULSAR_MEMdocker compose ps全部 Up 后浏览器逐个验证zk1:8000/metrics、bk1:8000/metrics、broker1:8080/metrics可访问回滚路径演练过一次旧 tag 镜像仍保留在本地 registrydocker pull可秒级恢复ZooKeeper snapshot 与 bookie ledgers 每日备份并落异地存储运维手册包含端口表6650/8000/8080/9090/3000与pulsar-admin常用命令告警分级写死backlog 持续增长 10 min → P1pulsar_num_consumers归零 → P1GC P99 2s 持续 5 min → P2客户端到 proxy 的 6650 走内网公网只暴露 proxy 且开 TLSexposeTopicLevelMetricsInPrometheus等指标开关与实际 topic 规模匹配防止 /metrics 超时broker.conf大概率会踩的 3 个坑1. OOM容器反复被 kill现象docker inspect bk1 | grep -i oom出现OOMKilled: true压测流量一上就复现。原因Pulsar 同时吃堆内存和堆外 direct memory默认 2g 堆 4g 堆外宿主机分给容器的内存不够。解法# compose environment 中按实际容量设置 PULSAR_MEM-Xms1g -Xmx1g -XX:MaxDirectMemorySize2g2. 端口冲突单机全角色同机跑不起来现象bookie 或 broker 启动即失败日志出现Address already in use。原因bookie 的 Prometheus 端口默认 8000与本地 ZooKeeper stats 端口8000/8001在同一宿主机混部时撞车。解法# conf/bookkeeper.conf prometheusStatsHttpPort8002 # 同步更新 prometheus.yml 的 targets3. Bookie 卡死不启动现象watch-znode.py一直等/initialized-clusterbookie/broker 全部挂起。原因集群元数据未初始化或 ZooKeeper 数据卷被清掉了。解法docker compose up -d pulsar-init # 重跑 [init-cluster.sh](https://link.gitcode.com/i/7bdec2d9e6a969ab0e9da85eaa5c03c3)接下来可以看什么到这里你已经有一套能收发消息、指标可抓、面板可见的生产形态 Pulsar。上面是最短闭环离真实生产还差 TLS 认证、分层存储和跨集群复制这些层。继续深入可以从这三处入手镜像构建与裁剪逻辑看 Docker 构建说明完整集群编排参考 kitchen-sink compose指标开关和端点细节看 监控文档 与 Grafana 面板。本文覆盖的是最小可行路径生产规模请按团队情况扩展。【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址: https://gitcode.com/gh_mirrors/pulsar28/pulsar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考