crossoverJie

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

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

在上一篇 Pulsar3.0新功能介绍中提到，在升级到 3.0 的过程中碰到一个致命的问题，就是升级之后 topic 被删除了。 正好最近社区也补充了相关细节，本次也接着这个机会再次复盘一下，毕竟这是

在上一篇文章 Pulsar3.0 升级指北讲了关于升级 Pulsar 集群的关键步骤与灾难恢复，本次主要分享一些 Pulsar3.0 的新功能与可能带来的一些问题

Pulsar3.0 是 Pulsar 社区推出的第一个 LTS 长期支持版本。 如图所示，LTS 版本会最长支持到 36 个月，而 Feature 版本最多只有六个月；类似于

前段时间在使用 Pulsar 的 admin API 时，发现其中的一个接口响应非常慢： 使用 curl 拿到的响应结果非常大

之前写过一篇文章 VictoriaLogs：一款超低占用的 ElasticSearch 替代方案讲到了我们使用 Victorialogs 来存储 Pulsar 消息队列的消息 trace 信息。

当我们在生产环境发布应用时，必须要考虑到当前系统还有用户正在使用的情况，所以尽量需要做到不停机发版。 所以在发布过程中理论上之前的 v1 版本依然存在

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