背景 Pulsar 有提供一个查询 Broker 负载的接口： /** * Get load for this broker. * * @return * @throws PulsarAdminException */ LoadManagerReport getLoadReport() throws
最近收到了 Apache Pulsar 和 Apache HertzBeat社区的邀请邮件，成为了这两个项目的 Committer。 一路走来我从最开始的打游击战的闲散人员到如今活跃在各个开源项目里的“老兵”，用现在流行的话来说 Apache 的这两个 Committer 就相当于是拿到了编制，进入
Helm 的作用 在开始前需要先对 kubernetes Operator 有个简单的认识。 以为我们在编写部署一些简单 Deployment 的时候只需要自己编写一个 yaml 文件然后 kubectl apply 即可。 apiVersion: apps/v1 kind: Deploymen
以前有写过两篇文章来简单聊过如何做开源的事情，最近我自己组了一个社区里面也有不少朋友对开源感兴趣，于是我便根据自己的经验系统的梳理了一些关于开源的事情。 新手如何快速参与开源项目 手把手教你为开源项目贡献代码 有兴趣的可以先看看之前这两篇。 如何找到自己感兴趣的开源项目 首先第一步先想清楚自己搞
背景 在上一篇《从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅》中在最后提到在做一些 Trace 的定制开发。 到现在差不多算是完成了，可以和大家分享一下。 我们的需求是这样的： 假设现在有三个服务：ServiceA、ServiceB、ServiceC ServiceA 对外
背景 之前陆续写过一些和 OpenTelemetry 相关的文章： 实战：如何优雅的从 Skywalking 切换到 OpenTelemetry 实战：如何编写一个 OpenTelemetry Extensions 从一个 JDK21+OpenTelemetry 不兼容的问题讲起 这些内容的前提是最
背景 前段时间公司领导让我排查一个关于在 JDK21 环境中使用 Spring Boot 配合一个 JDK18 新增的一个 SPI(java.net.spi.InetAddressResolverProvider) 不生效的问题。 但这个不生效的前置条件有点多： JDK 的版本得在 18+ Spri
背景 最近在给 opentelemetry-operator提交一个标签选择器的功能时，因为当时修改的函数是私有的，无法添加单测函数，所以社区建议我补充一个 e2e test. 因为在当前的版本下，只要给 deployment 打上了 instrumentation.opentelemetry.io
背景 前两天收到业务反馈有一个 topic 的分区消息堆积了： 根据之前的经验来看，要么是业务消费逻辑出现问题导致消费过慢，当然也有小概率是消息队列的 Bug（我们使用的是 pulsar）。 排查 通过排查，发现确实是在一点多的时候消息堆积了（后面是修复之后堆积开始下降）。 于是我在刚才堆积处查看了
👉️URL: https://crossplane.io/ 📝Description: 将云基础架构和服务组成自定义平台 API 简介 在 11 月的 KCD 上海现场，听了一场阿里云的工程师关于他们自己的多云基础架构管理工具的介绍，前边的引言部分有介绍到 Terraform，还有另一款竞品就是
前言 闭包对于一个长期写 Java 的开发者来说估计鲜有耳闻，我在写 Python 和 Go 之前也是没怎么了解，光这名字感觉就有点"神秘莫测"，这篇文章的主要目的就是从编译器的角度来分析闭包，彻底搞懂闭包的实现原理。 函数一等公民 一门语言在实现闭包之前首先要具有的特性就是：First class
前言 最近在设计一个对某个中间件的测试方案，这个测试方案需要包含不同的测试逻辑，但相同的是需要对各个环节进行记录；比如统计耗时、调用通知 API 等相同的逻辑。 如果每个测试都单独写这些逻辑那无疑是做了许多重复工作了。 基于以上的特征很容易能想到模板方法这个设计模式。 这是一种有上层定义框架，下层提
前言 这段时间在做 MQ（Pulsar）相关的治理工作，其中一个部分内容关于消息队列的升级，比如： 一键创建一个测试集群。 运行一批测试用例，覆盖我们线上使用到的功能，并输出测试报告。 模拟压测，输出测试结果。 本质目的就是想直到新版本升级过程中和升级后对现有业务是否存在影响。 一键创建集群和执行测
前言 前段时间我们在升级 Pulsar 版本的时候发现升级后最后一个节点始终没有流量。 虽然对业务使用没有任何影响，但负载不均会导致资源的浪费。 和同事沟通后得知之前的升级也会出现这样的情况，最终还是人工调用 Pulsar 的 admin API 完成的负载均衡。 这个问题我尝试在 Google 和
背景 前段时间我们将 istio 版本升级到 1.12 后导致现有的应用监控有部分数据丢失（页面上显示不出来）。 一个是应用基础信息丢失。 再一个是应用 JVM 数据丢失。 接口维度的监控数据丢失。 修复 基础信息 首先是第一个基础信息丢失的问题，页面上其实显示的是我们的一个聚合指标istio_re
背景 今天收到业务团队反馈线上有个应用往 Pulsar 中发送消息失败了，经过日志查看得知是发送消息时候抛出了 java.lang.InterruptedException 异常。 和业务沟通后得知是在一个 gRPC 接口中触发的消息发送，大约持续了半个小时的异常后便恢复正常了，这是整个问题的背景。
背景 最近真是和 Pulsar 杠上了，业务团队反馈说是线上有个应用消息重复消费。 而且在测试环境是可以稳定复现的，根据经验来看一般能稳定复现的都比较好解决。 定位问题 接着便是定位问题了，根据之前的经验让业务按照这几种情况先排查一下： 通过排查：1,2可以排除了。 没有相关日志 存在异常，但最外层
背景 最近接手维护了公司的指标监控系统，之后踩到坑就没站起来过。。 本次问题的起因是我们配置了一些指标的删除策略没有生效： - action: drop_metrics regex: "^envoy_.*|^url\_\_\_\_.*|istio_request_bytes_sum" 与这两个容易引
背景 前段时间业务研发反馈说是他的应用内存使用率很高，导致频繁的重启，让我排查下是怎么回事； 在这之前我也没怎么在意过这个问题，正好这次排查分析的过程做一个记录。 首先我查看了监控面板里的 Pod 监控： 发现确实是快满了，而此时去查看应用的 JVM 占用情况却只有30%左右；说明并不是应用内存满了
