OpenTelemetry在企业内部应用所需要的技术栈
可观测性概念当一个软件或系统出于运行状态时，如果我们不对他加以观测，那它的运行状态对我们来说就是一个黑盒。 如上图所示。 我们只能通过业务的表象来判断它是否正常运行，无法在故障发生前进行预判，从而只能被动解决问题。
日志与追踪的完美融合：OpenTelemetry MDC 实践指南
前言在前面两篇实战文章中： OpenTelemetry 实战：从零实现分布式链路追踪 OpenTelemetry 实战：从零实现应用指标监控 覆盖了可观测中的指标追踪和 metrics 监控，下面理应开始第三部分：日志。 但在开始日志之前还是要先将链路追踪和日志结合起来看看应用实际使用的实践。 通常我们排查问题的方式是先查询异常日志，判断是否是当前系统的问题。 如果不是，则在日志中捞出 tra
OpenTelemetry 实战：gRPC 监控的实现原理
前言 最近在给 opentelemetry-java-instrumentation 提交了一个 PR，是关于给 gRPC 新增四个 metrics： rpc.client.request.size: 客户端请求包大小 rpc.client.response.size：客户端收到的响应包大小 rpc.server.request.size：服务端收到的请求包大小 rpc.server.respo
OpenTelemetry 实战：从零实现应用指标监控
前言在上一篇文章：OpenTelemetry 实战：从零实现分布式链路追踪讲解了链路相关的实战，本次我们继续跟进如何使用 OpenTelemetry 集成 metrics 监控。 建议对指标监控不太熟的朋友可以先查看这篇前菜文章：从 Prometheus 到 OpenTelemetry：指标监控的演进与实践
OpenTelemetry 实战：从零实现分布式链路追踪
背景之前写过一篇 从 Dapper 到 OpenTelemetry：分布式追踪的演进之旅的文章，主要是从概念上讲解了 Trace 在 OpenTelemetry 的中的场景和使用。 也写过一篇 实操 OpenTelemetry：通过 Demo 掌握微服务监控的艺术：如何从一个 demo 开始集成 OpenTelemetry。 但还是有不少小伙伴反馈说无法快速上手（可能也是这个 demo 的项目比较
深入理解单元测试：技巧与最佳实践
之前分享过如何快速上手开源项目以及如何在开源项目里做集成测试，但还没有讲过具体的实操。 今天来详细讲讲如何写单元测试。 🤔什么情况下需要单元测试这个大家应该是有共识的，对于一些功能单一、核心逻辑、同时变化不频繁的公开函数才有必要做单元测试。 对于业务复杂、链路繁琐但也是核心流程的功能通常建议做 e2e 测试，这样可以保证最终测试结果的一致性。
Pulsar升级自动化：一键搞定集群升级与测试
背景由于我在公司内部负责维护 Pulsar，需要时不时的升级 Pulsar 版本从而和社区保持一致。 而每次升级过程都需要做相同的步骤： 安装一个新版本的集群 触发功能性测试 触发性能测试 查看监控是否正常 应用有无异常日志 流量是否正常 各个组件的内存占用是否正常 写入延迟是否正常