在 kubernetes 环境下如何采集日志
当我们没有使用云原生方案部署应用时采用的日志方案往往是 ELK 技术栈。
这套技术方案比较成熟,稳定性也很高,所以几乎成为了当时的标配。
可是随着我们使用 kubernetes 步入云原生的时代后, kubernetes 把以往的操作系统上的许多底层都屏蔽,再由他提供了一些标准接口。
同时在 kubernetes 中的日志来源也比传统虚拟机多,比如可能有容器、kubernetes 自身的事件、日志等。
实战:如何编写一个 OpenTelemetry Extensions
前言
前段时间我们从 SkyWalking
切换到了 OpenTelemetry
,与此同时之前使用 SkyWalking 编写的插件也得转移到 OpenTelemetry 体系下。
我也写了相关介绍文章:
实战:如何优雅的从 SkyWalking 切换到 OpenTelemetry
好在 OpenTelemetry 社区也提供了 Extensions 的扩展开发,我们可以不用去修改社区发行版:opentelemetry-javaagent.jar
的源码也可以扩展其中的能力。
比如可以:
- 修改一些 trace,某些 span 不想记录等。
- 新增 metrics
2024年的云原生架构需要哪些技术栈
背景
时间过得很快啊,一转眼已经到了 2024 年,还记得 15 年刚工作那会掌握个 SSM/H(Spring/Struts2/Mybatis/Hibernate)
框架就能应付大部分面试了。
现在 CS 专业的新同学估计都没听说过 SSM😢
恰好从我刚开始工作时的移动互联网热潮到电商->共享经济->toB 大热->如今我都经历了一遍,技术栈也有由最开始的单体应用+物理机发展到现在的 kubernetes 云原生架构。
当然中途也经历了几个大的阶段:
SOA服务化-> 微服务-> 云原生-> 服务网格-> 无服务等几个阶段。
最近一份工作又主要是在做基础架构,我认为了解的还算是比较全面的,所以本文我就以我的视角分享下我们在 2024 年应当使用哪些云原生技术栈,因为涉及到的技术组件比较多,就不过多讨论细节了。
但可以保证的是提到的技术栈都是我所用过的,优缺点都会提到,主打一个真实体验。
在 kubernetes 环境下如何优雅扩缩容 Pulsar
顶级开源社区都能吵起来?
起因
因为订阅了 Pulsar 的开发者邮件,前段时间看到一封标题为《(Apache committer criteria) [ANNOUNCE] New Committer: Asaf Mesika》的邮件。
乍一看以为是欢迎 Asaf Mesika
成为 Committer,但仔细一看不太对劲,这内容也太多了,以往的欢迎都是简单的 Congratulations!
作为回复,这篇内容明显有点多了,于是便仔细看了下。
技术阅读周刊第十四期:常用的 Git 配置
技术阅读周刊,每周更新。
【译】Apache Pulsar 3.2.0 发布
Pulsar3.2.0 于 2024-02-05 发布,提供了一些新特性和修复了一些 bug ,共有 57 位开发者提交了 88 次 commit。
以下是一些关键特性介绍.
我的 2023
今天是春节的最后一天,因为工作上临时有点事,很不情愿的打开电脑看着也就 10 天没看代码觉得非常陌生。