消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载本文基于 Apache Pulsar 仓库中 deploy-monitoring.mdversion-2.2.0 文档整理并结合当前仓库的源码、配置文件与 Grafana 仪表盘模板加以印证。文章面向运维与开发人员系统讲解 Pulsar 集群中 Broker、ZooKeeper、BookKeeper、Functions/Connectors 四大类组件的指标采集方式以及如何接入 Prometheus 抓取、使用 Grafana 展示并配置告警规则帮助读者搭建一套可观测、可告警的生产级监控体系。监控体系总览能监控什么、用什么方式监控Pulsar 集群由多个组件构成因此监控也需要分层进行。官方文档明确指出一个 Pulsar 集群的监控既要覆盖主题topic维度的使用量指标也要覆盖集群各组件的整体健康状态。从指标来源上看监控数据分布在四类组件中组件指标内容采集方式Broker主题级统计destination dumps、命名空间级聚合指标pulsar-admin broker-stats命令 Prometheus HTTP 端点ZooKeeper本地 ZooKeeper、配置存储configuration store服务器与客户端的详细统计Prometheus HTTP 端点/metricsBookKeeperbookie 的统计指标conf/bookkeeper.conf中配置的 stats 框架默认 Prometheus 导出器Functions/Connectorsfunctions-worker 的 JVM 指标、函数与连接器指标pulsar-admin functions-worker命令 Prometheus HTTP 端点下面按组件逐一说明指标采集的具体方式与底层实现。采集 Broker 指标两类 Broker 统计destination dumps 与 monitoring metricsPulsar Broker 的指标以 JSON 格式对外暴露主要分为两类第一类Destination dumps主题级统计。包含每个独立主题topic的统计信息使用如下命令获取bin/pulsar-admin broker-stats destinations第二类Broker metrics命名空间级聚合指标。包含 Broker 自身信息以及按命名空间namespace聚合的主题统计使用如下命令获取bin/pulsar-admin broker-stats monitoring-metrics注意所有消息速率message rates指标每1 分钟更新一次。从源码可以看到这两类指标的实现细节。在 CmdBrokerStats.java 中broker-stats命令注册了monitoring-metrics、mbeans、topics别名destinations、allocator-stats、load-report等子命令public CmdBrokerStats(SupplierPulsarAdmin admin) { super(broker-stats, admin); jcommander.addCommand(monitoring-metrics, new CmdMonitoringMetrics()); jcommander.addCommand(mbeans, new CmdDumpMBeans()); jcommander.addCommand(topics, new CmdTopics(), destinations); jcommander.addCommand(allocator-stats, new CmdAllocatorStats()); jcommander.addCommand(load-report, new CmdLoadReport()); }也就是说destinations实际上是topics子命令的别名其实现调用getAdmin().brokerStats().getTopics()将每个主题的统计以 JSON 输出monitoring-metrics则调用getAdmin().brokerStats().getMetrics()支持-i/--indent参数对 JSON 输出进行缩进美化。在 REST 服务端BrokerStatsBase.java 将/metrics路径映射为监控采集端点其 API 注解明确说明该请求应由监控代理在每个 broker 上执行以抓取指标Requested should be executed by Monitoring agent on each broker to fetch the metrics并且仅允许超级用户super user访问GET Path(/metrics) public CollectionMetrics getMetrics() throws Exception { // Ensure super user access only validateSuperUserAccess(); CollectionMetrics metrics pulsar().getMetricsGenerator().generate(); return metrics; }Prometheus 格式的聚合指标除了 JSON 格式之外聚合后的 Broker 指标还会以 Prometheus 格式在如下地址暴露http://$BROKER_ADDRESS:8080/metrics/其中8080是 Broker 的默认 Web 服务端口$BROKER_ADDRESS替换为具体 broker 的主机地址。该端点供 Prometheus 直接抓取scrape无需额外开发导出器。采集 ZooKeeper 指标Pulsar 自带的本地 ZooKeeper、配置存储configuration store服务器及其客户端都可以通过 Prometheus 暴露详细的统计指标http://$LOCAL_ZK_SERVER:8000/metrics http://$GLOBAL_ZK_SERVER:8001/metrics其中本地 ZooKeeper 的默认端口为8000配置存储全局 ZooKeeper的默认端口为8001。如果要修改这两个默认端口可以通过指定系统属性system propertystats_server_port来完成。从架构上看Pulsar 的元数据服务pulsar-metadata模块负责 ZooKeeper 统计端口的启动与监听修改该属性后重启相关服务即可生效。采集 BookKeeper 指标BookKeeper 的统计框架通过修改 conf/bookkeeper.conf 中的statsProviderClass来配置。当前仓库默认配置如下conf/bookkeeper.confstatsProviderClassorg.apache.bookkeeper.stats.prometheus.PrometheusMetricsProvider prometheusStatsHttpPort8000也就是说默认的 BookKeeper 配置已经启用 Prometheus 导出器PrometheusMetricsProvider该配置随 Pulsar 发行包一起分发bookie 的 Prometheus 指标地址为http://$BOOKIE_ADDRESS:8000/metricsbookie 指标端口的默认值为8000可通过conf/bookkeeper.conf中的prometheusStatsHttpPort修改。跟踪 Managed Cursor 确认状态的指标在 Pulsar 中消费者确认acknowledgment状态会优先持久化到 ledger当写入 ledger 失败时才会回退持久化到 ZooKeeper。为了跟踪确认过程的统计信息可以为 Managed Cursor 配置如下 Prometheus 指标brk_ml_cursor_persistLedgerSucceed(namespace, ledger_name, cursor_name:) brk_ml_cursor_persistLedgerErrors(namespace, ledger_name, cursor_name:) brk_ml_cursor_persistZookeeperSucceed(namespace, ledger_name, cursor_name:) brk_ml_cursor_persistZookeeperErrors(namespace, ledger_name, cursor_name:) brk_ml_cursor_nonContiguousDeletedMessagesRange(namespace, ledger_name, cursor_name:)这些指标以namespace、ledger_name、cursor_name为标签维度含义如下指标含义brk_ml_cursor_persistLedgerSucceed确认状态成功持久化到 ledger 的次数brk_ml_cursor_persistLedgerErrors确认状态持久化到 ledger 时失败的次数brk_ml_cursor_persistZookeeperSucceed确认状态成功持久化到 ZooKeeper 的次数brk_ml_cursor_persistZookeeperErrors确认状态持久化到 ZooKeeper 时失败的次数brk_ml_cursor_nonContiguousDeletedMessagesRange非连续删除消息区间与消息删除/游标推进相关这些指标会添加到 Prometheus 接口中可在 Grafana 中监控和查看。源码层面ManagedCursorMXBeanImpl.java 维护了persistZookeeperSucceed等 LongAdder 计数器并通过 MBean 方式暴露给统计系统正是上述指标的底层数据来源。采集 Functions 与 Connectors 指标Pulsar Functions 与 Connectors 运行于 functions-worker 进程中其指标同样支持 JSON 与 Prometheus 两种格式。JSON 格式functions-worker JVM 指标包含 functions worker 的 JVM 指标使用命令pulsar-admin functions-worker monitoring-metrics函数与连接器指标使用命令pulsar-admin functions-worker function-stats从 CmdFunctionWorker.java 可以看到functions-worker命令下注册了function-stats与monitoring-metrics两个子命令与官方文档一一对应。底层实现中MetricsGenerator.java 将 JVM 指标等聚合为Metrics列表返回而 FunctionsStatsGenerator.java 负责从各个函数运行时实例收集 Prometheus 格式的指标文本。Prometheus 格式聚合后的函数与连接器指标以 Prometheus 格式暴露在如下地址http://$FUNCTIONS_WORKER_ADDRESS:$WORKER_PORT/metrics其中$FUNCTIONS_WORKER_ADDRESSfunctions worker 地址和$WORKER_PORTworker 端口都来自 conf/functions_worker.yml 配置文件。配置文件中对应字段为workerHostname或workerId中解析出的地址与workerPort部署时按实际环境替换即可。配置 Prometheus 抓取指标收集到各组件暴露的指标后下一步就是让 Prometheus 定期抓取。官方建议的工作方式是用 Prometheus 采集 Pulsar 各组件暴露的全部指标再用 Grafana 仪表盘展示并监控集群状态。裸机bare metal部署需要手动在 Prometheus 配置中提供要探测的节点列表即把上述各组件的指标端点加入scrape_configs例如scrape_configs: - job_name: pulsar-broker static_configs: - targets: [$BROKER_ADDRESS:8080] metrics_path: /metrics - job_name: pulsar-bookie static_configs: - targets: [$BOOKIE_ADDRESS:8000] metrics_path: /metrics - job_name: pulsar-zookeeper static_configs: - targets: - $LOCAL_ZK_SERVER:8000 - $GLOBAL_ZK_SERVER:8001 metrics_path: /metricsKubernetes 部署监控会自动配置无需手工维护抓取列表详见 deploy-kubernetes.md 中的 Kubernetes 部署说明。使用 Grafana 仪表盘维度控制的设计原则当开始采集时间序列数据时最大的挑战是防止数据附加的维度dimension数量爆炸。因此官方文档强调在时间序列采集层面只需要采集按命名空间聚合的指标即可满足大多数监控需求避免为每个主题生成过多的高基数时间序列导致存储与查询压力过大。Grafana 仪表盘部署方式Grafana 可以直接使用 Prometheus 中存储的数据创建仪表盘。在 Kubernetes 上部署 Pulsar 时默认会启用pulsar-grafanaDocker 镜像该镜像自带主要的仪表盘。如需手动启动该镜像使用如下命令docker run -p3000:3000 \ -e PROMETHEUS_URLhttp://$PROMETHEUS_HOST:9090/ \ apachepulsar/pulsar-grafana:latest参数说明-p3000:3000将容器内 Grafana 的 3000 端口映射到宿主机-e PROMETHEUS_URL...通过环境变量指定 Prometheus 服务地址$PROMETHEUS_HOST替换为实际 Prometheus 主机9090是 Prometheus 默认端口。仓库内置的 Grafana 仪表盘模板当前仓库的 grafana/dashboards 目录内置了多份可直接导入 Grafana 的仪表盘 JSON 模板覆盖集群各核心组件文件覆盖组件/视角broker.jsonBroker 运行指标bookkeeper.jsonBookKeeper 指标zookeeper.jsonZooKeeper 指标namespace.json命名空间级聚合指标topic.json主题级指标jvm.json各组件 JVM 指标prometheus.jsonPrometheus 自身指标这些模板与pulsar-grafana镜像配合使用可以直接在 Grafana 中 Import 加载。此外Pulsar Manager 也提供了逐主题per-topic仪表盘的说明可参考 administration-dashboard.md。配置告警规则监控的最终目的是及时发现问题。官方文档建议根据自身的 Pulsar 环境设置告警规则典型思路包括对brk_ml_cursor_persistLedgerErrors等错误类计数器设置阈值告警当持续增长时触发对 broker/bookie 端口如8080、8000的可达性设置探活告警对命名空间级消息速率、积压backlog等指标设置容量告警。Prometheus 的告警规则通过rules文件配置例如groups: - name: pulsar-alerts rules: - alert: CursorPersistLedgerErrors expr: increase(brk_ml_cursor_persistLedgerErrors[5m]) 0 for: 5m labels: severity: warning annotations: summary: Managed cursor ledger persist errors increasing具体规则语法以 Prometheus 告警规则文档为准Prometheus Alerting rules配置完成后由 Alertmanager 负责发送通知。小结一个完整的 Pulsar 监控体系可以归纳为三条链路指标暴露BrokerJSON :8080/metrics、ZooKeeper:8000/:8001、BookKeeper默认:8000、Functions/Connectorsfunctions_worker.yml指定的:WORKER_PORT各自暴露 Prometheus 格式指标指标采集与展示Prometheus 定期抓取各端点Grafana 通过内置模板见 grafana/dashboards或pulsar-grafana镜像可视化展示告警闭环依据环境特征配置 Prometheus 告警规则并结合 managed cursor 确认状态、命名空间级聚合指标等关键信号及时发现问题。部署方式上裸机环境需手工维护抓取节点列表Kubernetes 环境则由部署组件自动配置监控。读者可结合本文列出的源码路径如 CmdBrokerStats.java、BrokerStatsBase.java、conf/bookkeeper.conf进一步深入理解指标的产生与暴露机制从而按需定制自己的监控方案。赞分享消息队列后端流处理【免费下载链接】pulsarApache Pulsar - distributed pub-sub messaging system项目地址https://gitcode.com/gh_mirrors/pulsar28/pulsar点击查看免费下载相关推荐Apache Pulsar 集群监控部署指南指标采集、Prometheus 配置与 Grafana 可视化Apache Pulsar 集群监控部署指南指标采集、Prometheus 配置与 Grafana 可视化 Apache Pulsar 是一个分布式 pub消息队列后端流处理Apache Pulsar 集群监控部署指南指标采集、Prometheus 配置与 Grafana 面板实践Apache Pulsar 集群监控部署指南指标采集、Prometheus 配置与 Grafana 面板实践 本篇技术指南围绕 Apache Pulsar 集消息队列后端流处理Apache Pulsar 集群监控实践Metrics 采集、Prometheus 对接与 Grafana 仪表盘Apache Pulsar 集群监控实践Metrics 采集、Prometheus 对接与 Grafana 仪表盘 Apache Pulsar 提供了多层次的消息队列后端流处理上一篇favicon-cheat-sheet可持续发展绿色理念的图标方案下一篇Tars熔断策略调整记录跟踪策略变更与效果分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考