crossoverJie

因为订阅了 Pulsar 的开发者邮件，前段时间看到一封标题为《(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika

当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。 这套技术方案比较成熟，稳定性也很高，所以几乎成为了当时的标配。 可是随着我们使用 kubernetes 步入云原生的时代后，

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

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

最近公司将我们之前使用的链路工具切换为了 OpenTelemetry. 我们的技术栈是： 其中客户端使用 OpenTelemetry 提供的 Java Agent 进行埋点收集数据

在整个大环境的降本增效的熏陶下，我们也不得不做好应对方案。 根据对线上流量、存储以及系统资源的占用，发现我们的 Pulsar 集群有许多的冗余，所以考虑进行缩容从而减少资源浪费，最终也能省一些费

今天是春节的最后一天，因为工作上临时有点事，很不情愿的打开电脑看着也就 10 天没看代码觉得非常陌生。 之后便准备将迟迟未写的 2023 总结补完，这个传统从16年至今已经坚持将近 7 年时间了，今年

前段时间无意间看到一篇公众号 招贤令：一起来搞一个新开源项目，作者介绍他想要做一个开源项目：cprobe 用于整合目前市面上散落在各地的 Exporter，统一进行管理。 比如我们常用的 bla

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