下面我来推荐一些我看过同时觉得不错的项目(几乎都是我参与过的），由易到难，其中也会包含 Java 和 Go 的项目，包含主流的中间件和云原生项目。

前段时间给 StarRocks 的物化视图新增了一个特性，那也是我第一次接触 StarRocks，因为完全不熟悉这个数据库，所以很多东西都是从头开始了解概念。

最近业余时间花了小三个月重构了 cim，也将版本和升级到了 v2.0.0，合并了十几个 PR 同时也新增了几位开发者。其中有两位也是咱们星球里的小伙伴🎉介绍上次发版还是在五年前了：因为确实已经很久没有更新了，在开始之前还是先介绍 cim 是什么。这里有一张简单的使用图片：同时以前也有录过相关的视频：通过 cim 这个名字...

前几天排查了一个业务接口执行高延迟的问题，也挺有参考意义的，分享一下排查过程。现象是业务反馈有一个接口业务逻辑其实很简单，但是调用一次耗时，如下图所示：排查应用运行状态首先第一步需要查看当时的应用运行状态，包含当时的日志、JVM 的各种监控等。因为我们接入了 OpenTelemetry，所以 trace 和日志是可以关联...

前言在前面两篇实战文章中：OpenTelemetry 实战：从零实现分布式链路追踪OpenTelemetry 实战：从零实现应用指标监控覆盖了可观测中的指标追踪和 metrics 监控，下面理应开始第三部分：日志。但在开始日志之前还是要先将链路追踪和日志结合起来看看应用实际使用的实践。通常我们排查问题的方式是先查询异常日志，判断是否...

最近在给 opentelemetry-java-instrumentation 提交了一个 PR，是关于给 gRPC 新增四个 metrics：

以上是加入 metrics 之后的流程图，在原有的基础上会新增一个 Prometheus 组件，collector 会将 metrics 指标数据通过远程的 remote write 的方式写入到 Prometheus 中。

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

他发现手动将 pulsar-client-go 客户端的 ReceiverQueueSize 设置为 0 的时候，客户端在初始化时会再将其调整为 1000.

背景Pulsar 有提供一个查询 Broker 负载的接口： {代码...} 可以返回一些 broker 的负载数据，比如 CPU、内存、流量之类的数据。<!--more-->我目前碰到的问题是目前会遇到部分节点的负债不平衡，导致资源占用不均衡，所以想要手动查询所有节点的负载数据，然后人工进行负载。理论上这些数据是在运行时实时计算的数...

<!--more-->一路走来我从最开始的打游击战的闲散人员到如今活跃在各个开源项目里的“老兵”，用现在流行的话来说 Apache 的这两个 Committer 就相当于是拿到了编制，进入了正规军。

前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。

在上一篇文章 OpenTelemetry 实践指南：历史、架构与基本概念中回顾了可观测性的历史以及介绍了一些 OpenTelemetry 的基础概念，同时也介绍了 OpenTelemetry 社区常用的开源项目。

背景之前陆续写过一些和 OpenTelemetry 相关的文章：实战：如何优雅的从 Skywalking 切换到 OpenTelemetry实战：如何编写一个 OpenTelemetry Extensions从一个 JDK21+OpenTelemetry 不兼容的问题讲起这些内容的前提是最好有一些 OpenTelemetry 的背景知识，看起来就不会那么枯燥，为此这篇文章就来做一个入门科普，方便...

因为在当前的版本下，只要给 deployment 打上了 instrumentation.opentelemetry.io/inject-java: "true" 这类注解就会给该 deployment 注入 agent。但没办法指定不同的 agent 版本（或者不同的环境变量），所以希望可以新增一个选择器，同时可以针对不同的 deployment 维护不同版本的 Instrumentation(是用于...

前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。

前两天收到业务反馈有一个 topic 的分区消息堆积了：根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。

可是随着我们使用 kubernetes 步入云原生的时代后， kubernetes 把以往的操作系统上的许多底层都屏蔽，再由他提供了一些标准接口。

前段时间我们从 SkyWalking 切换到了 OpenTelemetry ，与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。

时间过得很快啊，一转眼已经到了 2024 年，还记得 15 年刚工作那会掌握个 SSM/H(Spring/Struts2/Mybatis/Hibernate) 框架就能应付大部分面试了。

背景最近公司将我们之前使用的链路工具切换为了 OpenTelemetry.我们的技术栈是： {代码...} 其中客户端使用 OpenTelemetry 提供的 Java Agent 进行埋点收集数据，再由 Agent 通过 OTLP(OpenTelemetry Protocol) 协议将数据发往 Collector，在 Collector 中我们可以自行任意处理数据，并决定将这些数据如何存储（这点在以...

不过在缩容之前很有必要先聊聊扩容，Pulsar 一开始就是存算分离的架构（更多关于 Pulsar 架构的内容本文不做过多介绍，感兴趣的可以自行搜索），天然就非常适合 kubernetes 环境，也可以利用 kubernetes 的能力进行快速扩容。

最近我们的 Pulsar 存储有很长一段时间数据一直得不到回收，但消息确实已经是 ACK 了，理论上应该是会被回收的，随着时间流逝不但没回收还一直再涨，最后在没找到原因的情况下就只有一直不停的扩容。

在上一篇 Pulsar3.0新功能介绍中提到，在升级到 3.0 的过程中碰到一个致命的问题，就是升级之后 topic 被删除了。正好最近社区也补充了相关细节，本次也接着这个机会再次复盘一下，毕竟这是一个非常致命的 Bug。现象先来回顾下当时的情况：升级当晚没有出现啥问题，各个流量指标、生产者、消费者数量都是在正常范围内波...

在上一篇文章 Pulsar3.0 升级指北讲了关于升级 Pulsar 集群的关键步骤与灾难恢复，本次主要分享一些 Pulsar3.0 的新功能与可能带来的一些问题。升级后所遇到的问题先来个欲扬先抑，聊聊升级后所碰到的问题吧。其中有两个问题我们感知比较明显，特别是第一个。topic被删除我们在上个月某天凌晨从 2.11.2 升级到 3.0.1 之...

如图所示，LTS 版本会最长支持到 36 个月，而 Feature 版本最多只有六个月；类似于我们使用的 JDK11,17,21 都是可以长期使用的；所以也推荐大家都升级到 LTS 版本。

背景前段时间在使用 Pulsar 的 admin API 时，发现其中的一个接口响应非常慢： {代码...} 使用 curl 拿到的响应结果非常大，同时也非常耗时：具体的 issue 在这里：[链接]后面经过分析，是因为某些 topic 的生产者和消费者非常多，导致这个查询 topic 统计的接口数据量非常大。但在我这个场景其实是不需要这些生产者和消...

而其中的关键的埋点信息是通过 Pulsar 的 BrokerInterceptor 实现的，后面就有朋友咨询这块代码是否开源，目前是没有开源的，不过借此机会可以聊聊如何实现一个 BrokerInterceptor 插件，当前还没有相关的介绍文档。

今天进入 kubernetes 的运维部分（并不是运维 kubernetes，而是运维应用），其实日常我们大部分使用 kubernetes 的功能就是以往运维的工作，现在云原生将运维和研发关系变得更紧密了。

最近在测试将 Pulsar 2.11.2 升级到 3.0.1的过程中碰到一个鉴权问题，正好借着这个问题充分了解下 Pulsar 的鉴权机制是如何运转的。