前言在上一篇文章：OpenTelemetry 实战：从零实现分布式链路追踪讲解了链路相关的实战，本次我们继续跟进如何使用 OpenTelemetry 集成 metrics 监控。 建议对指标监控不太熟的朋友可以先查看这篇前菜文章：从 Prometheus 到 OpenTelemetry：指标监控的演进与实践

背景之前写过一篇 从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅的文章，主要是从概念上讲解了 Trace 在 OpenTelemetry 的中的场景和使用。 也写过一篇 实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术：如何从一个 demo 开始集成 OpenTelemetry。 但还是有不少小伙伴反馈说无法快速上手（可能也是这个 demo 的项目比较

之前分享过如何快速上手开源项目以及如何在开源项目里做集成测试，但还没有讲过具体的实操。 今天来详细讲讲如何写单元测试。 🤔什么情况下需要单元测试这个大家应该是有共识的，对于一些功能单一、核心逻辑、同时变化不频繁的公开函数才有必要做单元测试。 对于业务复杂、链路繁琐但也是核心流程的功能通常建议做 e2e 测试，这样可以保证最终测试结果的一致性。

背景由于我在公司内部负责维护 Pulsar，需要时不时的升级 Pulsar 版本从而和社区保持一致。 而每次升级过程都需要做相同的步骤： 安装一个新版本的集群 触发功能性测试 触发性能测试 查看监控是否正常 应用有无异常日志 流量是否正常 各个组件的内存占用是否正常 写入延迟是否正常

前段时间在 pulsar-client-go 社区里看到这么一个 issue：

前段时间接到一个需求，希望可以监控 Nginx 的运行状态。 我们都知道 Nginx 作为一个流行的 Web 服务器提供了多种能力，包括反向代理、负载均衡；也支持了许多协议，包括： gRPC http WebSocket 等作为一个流量入口的中间件，对其的监控就显得至关重要了。

背景Pulsar 有提供一个查询 Broker 负载的接口： 1234567891011121314151617181920 /** * Get load for this broker. * * @return * @throws PulsarAdminException */LoadManagerReport getLoadReport() thr

最近收到了 Apache Pulsar 和 Apache HertzBeat社区的邀请邮件，成为了这两个项目的 Committer。

之前有朋友问如何做集成测试，今天就重点讲讲这个集成测试在开源项目中是如何做的。 通常是需要对外提供服务的开源项目都需要集成测试： Pulsar Kafka Dubbo 等

🧰Helm 的作用在开始前需要先对 kubernetes Operator 有个简单的认识。 以前我们在编写部署一些简单 Deployment 的时候只需要自己编写一个 yaml 文件然后 kubectl apply 即可。